HN Explorer

Ask HN: What do you use to build micro-front ends?

13 points by pscanf ↗ HN
Micro-frontends have been recently listed in Thoughtworks Technology Radar as "a technique to assess"[0]. They describe it as an approach parallel to the microservices pattern seen on the backend: a monolith front-end web app is broken into many sub-applications, each with a certain level of independence from the others so that it can be developed, tested and deployed in isolation. These sub-applications share a set of primitives to allow for a cohesive user experience.

Spotify desktop client is reported[1][2] to be built with such an approach, isolating micro-apps into iframes using libraries and postMessage APIs to coordinate. I've personally run into an application built in a similar way, where many iframes shared APIs exposed by their parent window.

I was wondering if someone in the HN crowd had experiences / tools / frameworks to share to help someone looking into this topic.

Thanks :)

[0] https://www.thoughtworks.com/radar/techniques/micro-frontends

[1] https://www.quora.com/What-is-the-technology-stack-behind-the-Spotify-web-client/answer/Andreas-Blixt

[2] https://www.quora.com/How-is-Javascript-used-within-the-Spotify-desktop-application/answer/Mattias-Petter-Johansson

4 comments

[ 2.1 ms ] story [ 25.6 ms ] thread
bgrohman
Multiple Angular SPAs that live at different URLs (e.g. one at /admin, one at /foo, etc). The apps use shared Bower components as needed for common functionality such as the navigation components. Clicking on a nav link from /admin to /foo is actually a full page refresh that loads a different Angular app.
nevon
We're doing something like that for Klarna Checkout (https://www.klarna.com/us/business/sell-online-with-klarna). At first, we built applications as completely standalone applications that were loaded into iframes and communicated over postmessage. We're still doing that for some things, but it has some big drawbacks, especially when it comes to bundle size and browser support. Bundle size is pretty obvious, since you end up sending the same libraries multiple times, and since the applications are separated, you can't extract common dependencies at build time. As for browser support, you basically cannot nest more than two levels of iframes (parent -> iframe -> iframe), or all hell breaks loose. If any nested frame needs to be able to scroll or has form fields, prepare for pain.

What we're testing out now is distributing the "applications" as blackbox React components which are built into the consuming applications. The state of the applications is contained completely within the component, and the API is just exposed through props. It increases the coupling between applications, since it forces everyone to use React and even be on more or less the same version of React, but that was already the case for us, so it seems like an okay tradeoff. One downside is obviously that the consuming application grows larger and larger as we add applications to it, but that can probably be solved by asynchronously loading chunks on demand.

mintlysocial
Microservices and Front-End

Microservices are becoming more and more popular and many are choosing to transition away from monolithic architecture. However, this approach was mostly limited to back-end services. While it made a lot of sense to split them into smaller independent pieces that can be accessed only through their APIs, same did not apply to front-end. Why is that? I think that the answer lies in technologies we’re using. The way we are developing front-end is not designed to be split into smaller pieces.

Server-side rendering is becoming history. While enterprise might not agree with that statement and continues pushing for server-side frameworks that “magically” transform, for example, Java objects to HTML and JavaScript, client frameworks will continue to increase in popularity slowly sending server-side page rendering into oblivion. That leaves us with client-side frameworks. Single-Page Applications are what we tend to use today. AngularJS, React, ExtJS, ember.js and others proved to be a next step in evolution of front-end development. However, Single-Page Applications or not, most of them are promoting monolithic approach to front-end architecture.

With back-end being split into microservices and front-end being monolithic, services we are building do not truly adhere to the idea that each should provide a full functionality. We are supposed to apply vertical decomposition and build small loosely coupled applications. However, in most cases we’re missing visual aspect inside those services. All front-end functionalities (authentication, inventory, shopping cart, etc) are part of a single application and communicate with back-end (most of the time through HTTP) that is split into microservices. This approach is a big advancement when compared with a single monolithic application. By keeping back-end services small, loosely coupled, designed for single purpose and easy to scale, some of the problems we had with monoliths become mitigated. While nothing is ideal and microservices have their own set of problems, finding production bugs, testing, understanding the code, changing framework or even language, isolation, responsibility and other things became easier to handle. The price we had to pay was deployment but that as well was greatly improved with containers (Docker and Rocket) and the concept of immutable servers.

If we see the benefits microservices are providing with back-end, wouldn’t it be a step forward if we could apply those benefits to front-end as well and design microservices to be complete with not only back-end logic but also visual parts of our applications? Wouldn’t it be beneficial if a developer or a team could fully develop a feature and let someone else just import it to the application? If we could do business in that way, front-end (SPA or not) would be reduced to a scaffold that is in charge only of routing and deciding which services to import.

I’m not trying to say that no one is developing microservices in such a way that both front-end and back-end are part of it. I know that there are projects that do just that. However, I was not convinced that benefits of splitting front-end into parts and packing them together with back-end outweights downsides of such an approach. That is, until I discovered web components.

Web Components

Web components are a group of standards proposed as a W3C specification. They allow creation of reusable components that can be imported into Web applications. They are like widgets that can be imported into any Web page.

They are currently supported in browsers based on WebKit; Chrome, Opera and FireFox (with manual configuration change). As usual, Microsoft Internet Explorer is falling behind and does not have them implemented. In cases where browser does not support web components nativelly, compatibility is accomplished using JavaScript Polyfills.

web components consist of 4 main elements which can be used separately or all together:

Custom Elements Shadow DOM HTML Imports HTML Templates Custom Elements

With Cus...