We Accidentally Built a Plugin SDK for Micro Frontends

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

React portals + RxJs = micro frontends on steroids.

At bettermarks, we are migrating an AngularJS app to React using micro frontends. Picture a dashboard with widgets from different frontends depending on permissions and settings without coupling.

We implemented a reliable solution for our micro frontends - and yes, we can embed React components within AngularJs!

I'll showcase our solution and demonstrate how this can help you build more robust applications by trying to break our.

This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.

FAQ

The talk focuses on how Betamax accidentally built a plugin SDK for microfrontends while migrating from AngularJS to React.

Andre is a principal engineer at Betamax, a Berlin-based education tech company.

Betamax initially used a traditional multi-page application powered by PHP.

Betamax decided to migrate from AngularJS to React after Google discontinued long-term support for AngularJS.

Betamax used a micro frontend approach to iteratively migrate from AngularJS to React.

Betamax currently runs 58 microfrontends.

Betamax aims for no or close to no coupling between applications, adaptability based on roles and permissions, and separation of concerns on the micro frontend level.

Betamax employs a testing pyramid strategy, using React testing library for low-level testing, snapshot testing, integration tests for interactions, and end-to-end testing for smoke tests.

No, Betamax uses a single shared version of React for all micro frontends.

Cross-application communication is handled via services using RxJS under the hood, allowing for communication without direct coupling between apps.

André Bauer
André Bauer
27 min
25 Oct, 2024

Comments

Sign in or register to post your comment.
  • André Bauer
    André Bauer
    bettermarks
    In case you tried to get to the gist - the QR code is faulty. Here is the link: https://gist.github.com/AnBauer/52b85aa1efa52d842d0ce1ac26e2e61d
  • André Bauer
    André Bauer
    In case you tried to get to the gist - the QR code is faulty. Here is the link: https://gist.github.com/AnBauer/52b85aa1efa52d842d0ce1ac26e2e61d
Video Summary and Transcription
Welcome to the talk on Microfrontends and Betamax. The speaker shares their experience of accidentally building a plugin SDK for microfrontends. They discuss the goals and bootstrapping process, emphasizing the importance of adaptability and separation of concerns. The use of behavior subjects and portal rendering is explained, along with the composition and resilience of microfrontends. The speaker demonstrates rendering REC.js within AngularJS and highlights the challenges of handling communication and deployment. They also discuss managing breaking changes, local development, testing, and shared dependencies. The talk concludes with a humorous anecdote and contact information for further engagement.

1. Introduction to Microfrontends and Betamax

Short description:

Welcome everyone to the, as mentioned, last talk of at least this track. I will be sharing how we accidentally built a plugin SDK for microfrontends, referred to as microfrontends on steroids. Quick intro about me, my name is Andre, a principal engineer at Betamax. In 2008, we built a traditional multi-page application powered by PHP. Later, we decided to build a single-page application using AngularJS. After nine years, we had to migrate from AngularJS to React using a micro frontend approach. We now run a full-blown micro frontend setup with 58 micro frontends and counting.

Welcome everyone to the, as mentioned, last talk of at least this track. I'm first and foremost super excited to be here. One of the reasons is that this is actually the first time I'm talking at a conference, and the other reason is that I will be sharing how we accidentally built a plugin SDK for microfrontends, which I refer to as microfrontends on steroids, but the responsibility in me put in the disclaimer, so really bad.

Quick intro for me or about me, it's, my name is Andre, I'm a principal engineer at Betamax, which is a Berlin based education tech company and happens to build, have built the world's most advanced adaptive learning and teaching systems for school. So besides, as mentioned, building digital products, I love to build actual things also, so in case you get already tired about talking about code, then hit me up and we can talk about woodworking or water sports for that matter, but back to the topic, how did we get there?

In order to answer the question, I want to give you a little context of the problem we are trying to solve and how we ended up in the position of having to solve it in the first place. So I'm old, which is not the root cause of the problem of course, but it means that back in 2008 when Betamax started development, I was amongst the first developers who, who kicked us off and we built a traditional multi-page application powered by PHP, which got us quite far.

In fact, so far that four and a half years later, we were able to announce that Uruguay has chosen Betamax to provide all math material for all the schools, which was a huge win back in the days, but it also meant that we will have a problem pretty soon because from the data we got in Germany, we know this setup would not scale on the level of a whole country. So, we thought it would be a nice idea to build a single page application, hot shit back in the day. By chance, any one of you know, when React was open sourced? One month later. So I think it's time to address the elephant in the room. We are at the React conference, but at this point in time, we went with the only reasonable choice being AngularJS.

So we, we in fact built the app, we shipped it and we built upon this base ever since actually. So, but fast forward, nine years later, the inevitable happened and Google discontinued the long-term support for AngularJS. I mean, quite some time to be fair. Um, at this time I was, I already rejoined Betamax, uh, with a mission to come up with a plan of how to iteratively migrate from AngularJS to React. So I rooted for a micro frontend approach and we executed it with a single span, which is basically a JavaScript router for micro services in the frontend. And it differentiates amongst other things, different types of micro frontends, which I will quickly explain because I will use the terminology moving forward.

So we have apps, of course, which are just like any other single page app, but without an actual HTML page. We have a root config which provides this root HTML page, it handles app registration, mounting, unmounting. So it is responsible for the whole composition of the micro frontend setup. Then we have utilities to share common logic and like services or component lib and we have parsers to share UI between frameworks. This will be important later. Um, our proof of concept was fairly easy done. So we implemented the navigation and react and kept the content area as a stripped down AngularJS version with bespoke bootstrapping process for the app, which worked pretty nicely.

So we put a whole team on it and started developing fast forward to this point. We now run a full blown micro frontend setup where apps can render parts within other apps where we are currently at 58 micro frontends and still counting. We have services, utility micro frontends that provide shared APIs, including global state management and behind the scenes, we do this with RxJS quite heavily. And yes, we still have some use cases in AngularJS, unfortunately, but we are getting there. Um, yeah, I did promise you that. I know.

2. Goals and Bootstrapping Process

Short description:

We aim for no or close to no coupling between applications. The root config controls the app composition. We want to be adaptable based on roles, permissions, licenses, feature toggles, and settings. Our goal is to achieve separation of concerns, encapsulation, and bounded context on the micro frontend level. In a live demo, I'll show you Better Marks from a student perspective. We have a hated view, the homework section, and a digital replacement for student school books called Teaching a School Book. We use a feature toggle to activate content. The bootstrapping process involves registering apps, such as the assignments app and the learning units app. The portal service handles rendering content into the correct DOM node.

Um, but first what are we trying to achieve actually from a goals perspective? So, um, we want to have no or close to no coupling between applications. The root config is the one and only place that controls the composition of apps. We want to be adaptable. That means, um, the composition of these apps is based on roles, permissions, licenses, feature toggles and settings so that different users can put, could potentially have different user experiences. And from an architectural standpoint, we want to, we aim for separation of concerns, encapsulation and bounded context on micro frontend level.

Yeah. So without further ado, I thought it would be a good idea for your very first talk to go with a live demo because why not? Um, so this is better marks from a student perspectives. We are looking at one of the most hated views from a student for students because when stuff shows up there, it means homework, usually. And the content there is just one of the most hated views for students. And the content there is from our practicing product. We also have a different one that is called teaching a school book, which is a digital replacement for physical student school books.

Um, the red line at the top marks an extension point that we call portal slots. Nothing shows up here. And I will show you why, because the feature toggle is not active. So if I, if I activate this feature toggle and reload. So now content shows up. Yeah, fair enough. So this is stuff that teachers distributed to the students to look at. And in order to understand our approach, I will walk you through the bootstrapping process of this page. Now you already saw the feature toggle. So root configuration takes care of registering apps, as I mentioned. So it has, uh, it knows about the user. Therefore it knows about potential licenses and if the license match or is sufficient, we also register the assignments app, what we just saw, the homework stuff. Then for activated feature toggle school book, we also, um, register the learning register, the learning units app that provides the distributed, um, content from the school book product, whether or not an registered app is active, is determined by signals bar for it by executing the is active function for every registered application. And this case, um, the route for the assignments and the allocated learning units match. So both are, both are mounted at this view. If now one view wants to offer one of these port slots, they just have to use our portal store with the desired slot, which will get them a callback ref. A component that wants to render into one of those extension points, a.k.a. portal slots, use our portal renderer to get a custom create portal function that will take care of rendering your content into the correct DOM node once it's mounted. And the really interesting part happens in our portal service.

3. Behavior Subjects and Portal Rendering

Short description:

In RxJS behavior subjects, every subscriber always gets a value, ensuring timing is considered. The use portal store hook manages the life cycle of the component and updates the map of mounted portal slots. The portal renderer subscribes to a desired portal slot and renders content to the target node.

Therefore you need to know what a behavior subject is because this is what it's based upon. In RxJS behavior subjects that we use to publish our set of mounted extension points, um, on, takes care that every subscriber will always get a value. So once you subscribe, you either get the initial one being an empty map, or if you come late to the party and stuff has already been published, you will still get the most recent value, which is important to keep in mind when we talk about timing.

Our use portal store hook that is responsible for getting you the callback ref on the other hand, takes care of the life cycle of this component. So if it's mounted, we are looking at this line here. Then it will trigger a dispatch or it will trigger a publishing of, of the current updated map of mounted portal slots on that storage. And if it, and if the target node unmounts, it will delete itself from the map of available portal slots and also publish it on, on this portal store.

On the consuming end of things, the portal renderer on the other hand, this one will subscribe with a desired portal slot on that storage. And if there is a DOM node mounted where it could render into, then it returns the react-create portal function so that can be used in the component, um, to render to the desired target node. And actually that's about it. Like 80 lines of code that took pretty long to come up with. And if you're not as excited as I was when we pulled this off, I don't blame you, but, uh, hear me out.

4. Micro Frontend Composition and Resilience

Short description:

The app responsible for the main view offers slots based on portals and portal service hooks. Rendering depends on registered and mounted micro front-ends. Publishing mounted slots on an RxJS behavior subject eliminates timing issues and isolates runtime errors. The composition of the application is determined in the root config, making it easy to predict the state and test. Multiple apps for bounded contexts can be used in different compositions.

So quick recap, the app responsible for the main view offers one or more slots by using our previous portals, which we talked about. The app responsible for the main view offers one or more slots by using our portal service hooks. What will be rendered into those slots depends on registered micro front-ends and mounted micro front-ends. The secret sauce is that by publishing mounted slots on an RxJS behavior subject, we eliminate timing issues with lazy loaded bundles and order of rendering, because if you imagine you have a huge setup with different micro front-ends being lazy loaded, you have to take care that you have on the one hand, the target node has to be mounted, but also the app that will be lazy loaded and so comes late to the party, as I said, um, also has at some point knows when, where to render into. And by having these, um, bounded context or isolated, um, bundles on, um, isolated bundles, we also isolate runtime errors. And what that means, um, is that in case a developer messes up and I know this barely happens, but, um, in case it happens, the only thing visible for the user is that some content is missing in case for homework, students will be happy. Usually the teachers won't be, but the whole app is still functioning because it's isolated in just one app that is using an extension point. So if you think of this approach at scale, it means your application or our application for at least is pretty resilient towards a human error or infrastructural problems like endpoints not available or bundles that could not have been loaded. Um, and furthermore, it is super easy to determine or to predict the state of your application because we have exactly one place where the composition is determined, which is the root config. And therefore it's, and there it is based on licenses and feature toggles as I mentioned. So it can be easily tested. And from a product perspective, on the other hand, if you have quite a lot of these, uh, apps responsible for bounded context, that means you can use them in different compositions to build up different use cases. So I would dare to say we actually built a plugin SDK for micro frontends, which is not yet ready to be like shared in the world, but for our users, this is our use cases for our needs. It suits very well.

5. Rendering REC.js within AngularJS

Short description:

I claim that we can render REC.js within AngularJS. By creating a parcel that provides a portal slot and importing it in AngularJS, we can share UI between different frameworks. Single-spa offers this functionality for various frameworks. The QR code leads to a GitHub gist with a basic example of the portal service. Feel free to reach out on LinkedIn for questions or join the Q&A corner. Thank you for a great talk!

And I think we have time for one more thing because I don't know if anyone read the whole pitch. I also claim that we can render REC.js within AngularJS. And yeah, so here we are. This, the nice little widgets on top are widgets from our teaching application rendered within the old school AngularJS app. And now I hope you paid attention. Um, how we actually do this is super straightforward. Um, we have the concept of passes. I told you where we can share UI between different frameworks. So I created a parcel that does nothing more, but providing a portal slot. This portal, portal parcel, naming is really hard, um, can be imported in AngularJS by using system.js. Therefore we, and with this approach, we get the life cycle functions. We configure the parcel properties that are needed and in the AngularJS template.

Yeah, this is how an AngularJS template looks like. We can use a parcel element directive. And this is how it's called an AngularJS that will take care of rendering your parcel. Luckily, single-span offers this for very, for quite a lot of frameworks, actually. So switch, view, you name it. But from there on, it's back to what you already saw. So we will have a react component being a report the slot in AngularJS and everything else is what you just saw. So pretty easy, pretty straightforward, but was a great effect. And actually three minutes early, but this is all I have for today.

The QR code leads you to a gist I created on GitHub where you find the portal service, this a very basic example. So you can play around if you like. Hit me up on LinkedIn, if you have questions or later, I mean, better in the speaker, the Q and A corner, but yeah, that's about it. Thank you so much. That was such a good talk. And what was hilarious as well is during the talk I was listening and you were describing what you're going through. It was like, yeah, it's a micro frontend. Oh yeah. That's the point of this talk.

QnA

Handling Communication and Deployment

Short description:

You mistakenly built a plugin SDK for micro frontends. Communication between micro frontends can be achieved using services, where React services using RxJS can enable cross-application communication. Deployment of micro frontends and the main shell application is currently done together, but the goal is to deploy only the affected micro frontends. Breaking changes between micro frontends and the main shell application require communication and coordination between teams.

You mistakenly built a plugin SDK for micro frontends. That was really interesting when you started talking about Angular, I was like, where are we going with this? And you were like, oh, yeah, that's a good point. We actually do have a bunch of questions coming in. Remember also that you can rate the talks as well. So a five out of five as well would be great. And let's just dive straight in to our content.

The first question was about sort of the different microservices that you have and how do, can they communicate between them, are there ways that they can let another sort of micro frontend or piece know that something's happening? Yes. So I mentioned the services, utility micro frontend. This one, there are quite a lot of React services that use RxJS under the hood. So whenever you want to have cross application communication, you will do this via the service because this one will always be mounted so it is in, it has a cross application communication. So it is in, it is, has a state that is persisted and with RxJS you can really build really nice pipelines via transformation filtering, and you can notify basically without coupling to another app, you can just push it out there and interested parties could subscribe to these events and act accordingly.

Another question that's come in, this one's from Ross. Oftentimes when you work with micro frontends, deployment gets a little bit tricky and can grow into a big problem. How do you handle deployment of each of these micro frontends and a show application and are they deployed together or deployed separately? So we would love to be in a state where we can deploy only a set of affected micro frontends. We are not there yet, unfortunately, because this is just two and a half years old or so, so currently we deploy all frontends together. We aim for the deployment I just mentioned where, you know, you have updated one micro frontend and other depend on them so we know, okay, we have to deploy these four.

Another question from Ross again, which was about breaking changes. So how do you handle breaking changes between micro frontends and the main shell application? And to main what? Main shell application. Well, if a team wants to introduce a breaking change in their, in the microfrontend they are responsible for, you have to start talking to other teams and then make sure you, as we deploy in one go that you also provide that you also address these breaking changes and mitigate them. No, absolutely. I think this is interesting because, and I kind of want to add to this question where there is the technical parts and then there is also the team management, getting the team to work together part of this question. Yes. So imagine, so I said we have 58 micro frontends. That means we are obviously not just one team working on these.

Managing Breaking Changes and Local Development

Short description:

When introducing a breaking change, coordination and communication between teams is essential. Teams working on micro frontends require constant talking and coordination, leading to a nice exchange between them. Local development environments can vary depending on the focus of the work, with options for a micro stack or a full-blown application. Module federation is avoided due to added complexities, with the goal of eliminating AngularJS.

Well, if a team wants to introduce a breaking change in their, in the microfrontend they are responsible for, you have to start talking to other teams and then make sure you, as we deploy in one go that you also provide that you also address these breaking changes and mitigate them.

No, absolutely. I think this is interesting because, and I kind of want to add to this question where there is the technical parts and then there is also the team management, getting the team to work together part of this question. Yes.

So imagine, so I said we have 58 micro frontends. That means we are obviously not just one team working on these. So we have, I think four or five teams now working on this monorepo. And so there is a lot of talking going on, on a weekly basis and on demand. So yes, it needs some coordination for sure, but it's also leads, um, leads to a nice exchange between those teams. Absolutely. Teamwork and collaboration is always the key. Always the key.

The next one is about sort of local development environments, uh, especially because you've got, uh, quite a lot of different things going on. So how, uh, are you handling or how are the different members of the teams handling, uh, local developer environments between these different micro frontends?

Well, it depends. Um, I wish I had the door for every time. I know that answer. Yeah. So when you're focused on front and work mostly, um, what you just saw were my, um, we call it micro stack up and running, which is, which is a whole mock backend, uh, based on just Node. Really simple. Um, there are other, uh, when you, when you want to, want to work full stack, we have, um, we have a Kubernetes desk stack that is supposed to run on your machine entirely with all the effect, uh, backend that you need, because also on the backend side of things, we have microservices. Um, so yeah, these two options run it completely locally with mocked backend stuff or, um, the full blown application.

And I'm guessing that's probably something that is going to start to include the preference of particular users or what they need at what point into developer cycle as well, development. Yeah, fair to say. No, for sure. For sure.

And another question is about module federation. Have you considered using module federation concept to share code between parcels? Well, I think what I might, should have mentioned regarding parcels is that we try, not we try, we stayed away from, from this as long as possible. And this very specific example you just saw was solely made by me for showing off purposes to be really transparent here because it adds a whole another layer of complexities that we try to avoid. So, because it is always an in-between solution. Our goal is to get rid of AngularJS really soon.

Managing Microfrontend Testing and Parcel Usage

Short description:

We don't use parcels in our production app due to the complexities it adds and our focus on migration. Our testing strategy includes low level testing, snapshot testing, and integration testing. Interaction between micro front ends is tested through integration testing. Different versions of React cannot be used for each micro front end.

So we don't want to make it tempting for product people to come up with new feature ideas where you can just put a parcel in there and here we go. So we haven't considered it. We don't use, we don't use parcels in our production app. And that's actually just made me remember that the whole reason they started is because of migration. That's the driving force and balancing migration with kind of moving forward must be something interesting that your team has to kind of. Yeah, it's interesting, demanding on every single level. So once we have to communicate to product people that we won't touch this code base unless we have severe bugs. So we don't feature development and the legacy code base and we go from one use, one use case after the other in terms of migration. So there's no like little improvements by just adding some React stuff to our existing code base.

And this is a kind of a different question that's about what you're building and more about how you're testing it. And you showed us the config and how you can switch between different config permutations. And this person has asked, how do you handle end to end testing between all of these different config permutations? So we go through the whole testing pyramid. So we have, we use react testing library on for low level testing, for doing and use snapshot testing for testing what would we expect for mounted micro front ends for every route and one level higher. We say, okay, we do integration tests for every setup where at least two micro front ends are involved besides the navigation one that will always be mounted. And then at the last stage, we do the really expensive end to end testing only for smoke tests. So we have quite extensive integration test suite. Yeah.

And I love how you kind of use the right level of resolution with your testing for whatever you need. And this kind of relates to another question that came in, which was about testing the interaction between micro front ends. So you talked about being able to select the test when these two micro front ends are involved. Can you also test the interactions between them? Well, if you want to test interactions between them, you have to rely on integration test because this is on unit test level. You just can't. You have to mock.

Now, great question. I was waiting for this one. No.

Managing Shared Dependencies and T-shirt Anecdote

Short description:

Micro front ends share a single version of React and AngularJS. Updating can be challenging for multiple micro front ends. Speaker shares a funny anecdote about an elephant in the room t-shirt design and provides contact information for online presence.

We're nearly out of time, so this will be the last one before we get to the most important question under this. Can you have different versions of React for each micro front end or do the micro services, micro front ends, I guess, share a version of React?

Now, great question. I was waiting for this one. No. So this is one of the basic limitations or one of the most important limitations that you have to keep in mind. We have one React and one version of React only, which is a so-called shared dependency, meaning it's of course not bundled with each and every micro front end. So we have one version of React, one version of AngularJS, nothing more. So yes, updating this can get pretty hard when you think of 58 micro front ends, but that's how it is.

Awesome. And honestly, when I saw it on the slide, I didn't realize the elephant in the room joke, but then after seeing your shirt, it really, really drilled home. For those of you who maybe are in the back, you can't see, his t-shirt is the schematics or the floor plan of a room, but if you look closely or you squint, you can actually see an elephant in that room and it's a really great t-shirt. Where did you get it from? Yeah, it's a t-shirt designer from, I think New Zealand originally, it's called Glenz, G L E double N Z. So, and once a year I order a bunch of t-shirts and ship them over from the US. So, Nice. I love, I love that t-shirt. And if you maybe want to find out where you can get that t-shirt, you can find him in the speaker Q and A room later, but also where can people find you online if they want to follow the work that you do? But, so I mean, mostly on LinkedIn, my work, I won't, I have not really, not really much to publish because my main focus is better marks and this is not in the, in the open. You can try to DM me on, on Twitter, it's defthisdog, but I'm not really active there. Well. Okay, LinkedIn and also catch him in person. And if you are online, you can also join the speakers Q and A virtually as well. Can we give it up for him one more time? A big round of applause. Thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Understanding React’s Fiber Architecture
React Advanced 2022React Advanced 2022
29 min
Understanding React’s Fiber Architecture
Top Content
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Thinking Like an Architect
Node Congress 2025Node Congress 2025
31 min
Thinking Like an Architect
Top Content
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
Monolith to Micro-Frontends
React Advanced 2022React Advanced 2022
22 min
Monolith to Micro-Frontends
Top Content
Microfrontends are considered as a solution to the problems of exponential growth, code duplication, and unclear ownership in older applications. Transitioning from a monolith to microfrontends involves decoupling the system and exploring options like a modular monolith. Microfrontends enable independent deployments and runtime composition, but there is a discussion about the alternative of keeping an integrated application composed at runtime. Choosing a composition model and a router are crucial decisions in the technical plan. The Strangler pattern and the reverse Strangler pattern are used to gradually replace parts of the monolith with the new application.
The Eternal Sunshine of the Zero Build Pipeline
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!

Workshops on related topic

AI on Demand: Serverless AI
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
Micro Frontends with Module Federation and React
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Top Content
Workshop
Alex Lobera
Alex Lobera
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
High-performance Next.js
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Michele Riva
Michele Riva
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
Micro-Frontends with Module Federation and Angular
JSNation Live 2021JSNation Live 2021
113 min
Micro-Frontends with Module Federation and Angular
Workshop
Manfred Steyer
Manfred Steyer
Ever more companies are choosing Micro-Frontends. However, they are anything but easy to implement. Fortunately, Module Federation introduced with webpack 5 has initiated a crucial change of direction.
In this interactive workshop, you will learn from Manfred Steyer -- Angular GDE and Trusted Collaborator in the Angular team -- how to plan and implement Micro-Frontend architectures with Angular and the brand new webpack Module Federation. We talk about sharing libraries and advanced concepts like dealing with version mismatches, dynamic Module Federation, and integration into monorepos.
After the individual exercises, you will have a case study you can use as a template for your projects. This workshop helps you evaluate the individual options for your projects.
Prerequisites:You should have some experience with Angular.