Scribd
Upload
103 views

Micro Frontend Part One

This document discusses the evolution of the architecture of a large healthcare data platform from an initial single page AngularJS application to a microfrontends architecture using a custom UI Engine framework. As the initial application grew organically over time, it became difficult to maintain due to lack of structure. The company refactored the frontend into independent microfrontends within a shared application shell provided by the UI Engine framework. This improved maintainability, flexibility to use different frontend frameworks, and performance.

Uploaded by

Rahul Gaur
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
103 views

Micro Frontend Part One

This document discusses the evolution of the architecture of a large healthcare data platform from an initial single page AngularJS application to a microfrontends architecture using a custom UI Engine framework. As the initial application grew organically over time, it became difficult to maintain due to lack of structure. The company refactored the frontend into independent microfrontends within a shared application shell provided by the UI Engine framework. This improved maintainability, flexibility to use different frontend frameworks, and performance.

Uploaded by

Rahul Gaur
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

micro-frontend-part-one.

md 8/19/2019

Engineering resilient Micro Frontends


Over the last decade, AngularJS has been one of the "coolest kid on the block”, substituting several of the
weaknesses that came with jQuery-based net engineering solutions. Many enterprises were extraordinarily happy
building their fashionable net portals with AngularJS, and with the exponential growth of net businesses,
AngularJS created several developers’ lives easier.

Everyone was happy in the web development world, but this happiness didn’t last long.

A Big Ball of Mud and JavaScript


While much attention has been focused on high-level software architectural patterns, what is, in effect, the
de-facto standard software architecture is seldom discussed. This paper examines this most frequently
deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even
haphazardly, structured system. Its organisation, if one can call it that, is dictated more by expediency
than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for
architecture.- http://www.laputan.org/mud/

We started Developing Innovaccer's healthcare dataplatform, during November 2015, at that time our application
architecture consisted of a Single Page Application, written in Angular1.3 as during that time React was relaitively
new to build out a complex product for healthcare and everybody in the team was mostly well versed with
AngularJs, also it was relatively easier to find developers exepreinced with the technology at that time.

During the time of its creation, our application had a well-defined architecture. The relentless onslaught of
adjusting needs that any eminent system attracts will step by step undermine its structure. Systems that was
once tidy become overgrown as piecemeal growth gradually allows elements of the system to sprawl in an
uncontrolled fashion.

This system started showing unmistakable signs of unregulated growth, and repeated, expedient repair.
Information is shared promiscuously among distant components of the system, usually to the purpose wherever
nearly all the necessary info becomes world or duplicated. The overall structure of the system was well defined, it
was eroded beyond recognition.

Continuously refactoring toward deeper insight

As with our decaying system, a downward spiral ensues. Since the system has become harder and harder to
understand, maintenance has become more expensive, and more difficult. The way to arresting entropy in the
software package is to refactor it. A sustained commitment to refactoring can keep a system from subsiding into
a chaotic state.

If such sprawl continues intense, the structure of the system will become thus badly compromised that it should
be abandoned.

Rewriting the whole frontend in React or Vue was not an option for us, specially in the moder JavaScript
ecosytem , which is highly volatile and everchanging trends we wanted to create an architechture that can be
agnostic of frontend framework being used by a particular team to build their web interface, and provide a
scafolding to include any of the existing frontend frameworks or if something better comes down the line, without
shreding down the existing application completely.

1/2
micro-frontend-part-one.md 8/19/2019

In our endevour to refactor our existing single page monolith into a more elegant and performant architecure that
is nimble in nature, we ended up creating UI Engine, which solves the complexity of engineering large scale
javascript applications, that offers a felxible yet strict enforcement of certian esential rules, that are compulsory to
follow as a precursor to building resilient web applications, that critical bussiness like healthcare can rely on and
are easier to test, maintian and change and secure.

TLDR: In recent years, thanks to Node.js, JavaScript has become the “lingua franca” of the web for both
front and backend applications. This has given rise to awesome projects like Angular, React and Vue
which improve developer productivity and enable the construction of fast, testable, and extensible
frontend applications. However, while plenty of superb libraries, helpers, and tools exist for Node (and
server-side JavaScript), none of them effectively solve the main problem - architecture.[1]

Engine is an Inversion of Control Container that solves the problem of architecutre for Large Scale Complex
Javascript Applications.

Loose coupling allows you to make changes to one module without affecting the others.

Writing JavaScript is very easy, almost anyone can learn and start developing User Interface with JavaScript or
jQuery, AngularJS, React , Vue etc, however, the difficult part is writing maintainable JavaScript.

We deployed this our refactored frontend application, by migrating each angularjs applications as a small micro-
frontends, inside App Shell architechture provided by UI Engine, and all the network calls which were intially
being triggred as cross origin from the browser to our backend services, was now proxied through API gateway
registred in UI engine.

After some more tweaking, enabling HTTP/2 on nginx and compression middleware on node.js layer to
compress all the json and static resources, below are some screenshots of the first deployment on
staging.innovaccer.com that we did in April 2018 compared to our leagacy SinglePage AngularJS application on
qa.innovaccer.com.

2/2

You might also like