Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Microservice Approach for Web Development: Micro Frontends

DZone's Guide to

Microservice Approach for Web Development: Micro Frontends

You've heard of microservices, but what's a micro frontend? You'll learn this and how to get started with a micro frontend for web developers in this post.

Free Resource

Learn why microservices are breaking traditional APM tools that were built for monoliths.

This post is based on my Oracle Code 2018 Warsaw talk. View the presentation on SlideShare from andrejusb.

Wondering what "micro frontends" means? Check the micro frontends description here. Simply speaking, a micro frontend must implement business logic from top to bottom (database, middleware, and UI) in an isolated environment, it should be reusable and pluggable into the main application's UI shell. There must be no shared variables between micro frontends. The advantage is that distributed teams can work on separate micro frontends; this improves large and modular system development. There is a runtime advantage, too: if one of the frontends stops working, the main application should continue to work.

I have implemented micro frontend architecture with Oracle JET. The source code is available in this GitHub repository. There are three applications, two with micro frontends, and one being the master UI shell. Both micro frontends are implemented as JET Composite Components. The first is hosted on WebLogic; it calls the ADF BC REST service in the backend. The second is hosted on Node.JS and returns static data. The first micro frontend implements a listener, which allows handling of actions from the outside.

When a JET application is accessed through your browser, a bunch of HTML, JS, and CSS files are downloaded from the server. The core idea with micro frontends is that instead of loading HTML, JS, and CSS for the micro frontend from the same host as the master app, we load it from a different host. The JET Composite Component rendered inside master application will be downloaded from a different host. Not only is it downloaded, all backend calls should go to that host, too, not to the master host. Here is the integration of a JET Composite Component into the master application architecture:

This is how it works in practice. Each of these charts is a separate JET Composite Component, loaded as a micro frontend from a different host into the master application. We can see that in the network monitor. Loader.js scripts for both micro frontends are downloaded from different hosts:

Image title

The runtime advantage is that if one or multiple micro frontends are down, the application continues to run:

Image title

The JET Composite Component runs on the client, even if it is hosted in its own micro frontend. This gives the possibility to subscribe to the events happening in the component in the master app and route that event to another micro frontend. In this example, once an item is selected in the job chart, the employees chart (another micro frontend) is filtered:

Image title


Technical Implementation

The main application must be configured to support remote module loading for JET Composite Components. Read more about it in Duncan Mills's blog post, JET Custom Components XII - Revisiting the Loader Script. In short, you should add Xhr config in the JET application's main.js:

Image title

The server where the micro frontend is hosted must set an Access-Control-Allow-Origin header.

The main module where both micro frontends are integrated is using JET module components. Each micro frontend in the master UI shell is wrapped into the JET module. This allows the main application to function, even when a micro frontend in the module stops:

Image title

The JET module is initialized from the variable, which returns a module name:

Image title

The Jobs module contains the Jobs micro frontend, a JET Composite Component. It is hosted in WebLogic and calls ADF BC REST in the backend. The component is assigned with a listener:

Image title

The most important part is in the JS script. Here, instead of referencing the JET Composite Component locally, we load it from a remote host. This allows us to develop and host the micro frontend JET Composite Component on its own:

Image title

The listener refers to the c2 element and calls the method. The element c2 in the main app relates to the second micro frontend:

Image title

This component is loaded from another host, from Node.JS:

Image title

Important hint: for the JET Composite Component to load from the remote host, make sure to add .js for the JET Composite Component script, as highlighted (refer to the source code):

Image title

Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.

Topics:
microservices ,front end development ,web dev

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}