Emerging Technologies Microservices and Micro-frontends


By now most people have heard about this micro-frontends thing. After microservices this seems to be the next target for decoupling large systems. As with microservices this will not be for everyone. Personally, I think before starting with micro-frontends you should be aware of why you want to do them in the first place. Obviously, multiple solutions to microfrontends exist. While I'm personally advocating React as a basis for microfrontends the whole approach works with any technology and any implementation pattern.

1. Independent Teams Independent Thinking

If you develop in multiple teams then the organizational overhead becomes striking. Communication needs to happen at least on a daily basis. The alignment required to control development and deployment is becoming infeasible. With micro-frontends the scalability in terms of development resources becomes much easier to manage. Generally, each feature can be developed by an independent team. Each team can autonomously publish its features without any required alignment. Some approaches for micro-frontends require at least a shared build system or a common layer to be touched (e.g., a reverse proxy). While such things could still be tackled upfront they make the whole solution more complex to be set up correctly initially. My recommendation is therefore to look for solutions that already work after initial set up.

2. Faster Time to Market Faster

The independent nature of micro-frontends has an impact also on the time to market for individual features. While a monolith will become slower and slower in its feature development, a microfrontend will keep the pace. Naturally, refactoring and improvement of the underlying technology will need to happen here, too, however, the pace that is possible by a cycle consisting of

  • start new project
  • Develop the MVP
  • Ship the MVP
  • Iterate over the MVP (develop and ship)
  • Go into maintenance mode

for each new feature is mighty. The initial feature may be developed and brought online within minutes to days instead of weeks to months. The faster time to market is also possible by sharing already some of the used resources and functionality. Instead of developing a new application from the ground up (incl. things such as authentication, logging, ...) all these things should be given by a common layer. My recommendation is to go for an app shell approach to cover things that should be common already in a shared component.

3. Feature Flags Personalization

It's wonderful to have individual micro-frontends composed (or stitched) together as one app. But quite often product owners want to go one step beyond the technical composition: They want to use the modularization also for business purposes. Ever had the case that a certain frontend functionality should only be available to certain users? I guessed so. Sure, admin functionality should only be available to admins. While the frontend should not be used as a protection layer (this is still verified in the backend) we also don't want to show things that cannot (or should not) be used.
Consequently, we'll add things in our code like:

if (hasFeature('foo')) { // ... }

This is quite a bad style. Our code is now full of things that will most likely change. What if foo is just true for everyone? What if the feature is deactivated for everyone? What if tomorrow a new condition comes a long, changing some parts to also evaluate if bar is active? Since we already have proper modularization its quite simple to add feature flagging. All we need to do is to introduce conditional provisioning of a module via feature flags. That's it. No code change at the functional level of the module, just introduce feature flagging and its management on the provisioning layer. While things like this may also work in classic monoliths, they require more implementation effort. With micro-frontends the architecture is already fully prepared for it. My recommendation is to choose a micro-frontend framework that allows conditional provisioning per user.

4. Single Responsibility One Boss

Even though microservices are not the solution for everything, they are advocated as such. Yes, they are certainly a good solution in many (or even most) cases, but very often a monolith or other form of service-oriented architecture may be at least as good. Nevertheless, having a dedicated service (with a team responsible for it) in the backend is a good start. Replacing now the monolith with different micro-frontends is a great continuation as the additional dimension of cutting teams can be used in many ways. One possibility is to start with full stack teams. As such the team doing the backend module (microservice) is also responsible for the frontend module (micro-frontend). Great! While the service and its frontend are definitely two different things from a technical point of view, they are related or even the same from a business point of view. Having a single business capability or feature from a single responsible team is certainly an advantage. One of the problems is that a typical user journey is quite often touching multiple business capabilities. My recommendation is therefore to use a framework that also allows dynamically using components from some micro-frontend in another micro-frontend. The relation must be weak to still allow individual feature flagging.

5. Freedom of Technology Freedom

In the last two years the frontend technology has pretty much stabilized. Sure, with Svelte around the block technologies such as React might be challenged again, but honestly I must yet to be convinced of any advantage. Right now the development in a single codebase is just too appealing. Independent of my personal feelings regarding the future of any framework it's a truth that multiple approaches are out there and that no silver bullet exists. As such we will not only find people with a different background (yes, even some guys developing Angular!), but also existing applications using different (maybe even outdated) technologies. In a micro-frontend solution all these different apps can work together. A page written with Angular can use a component from a React micro-frontend and vice versa. The modal dialog for saving user data may be written in Vue, while the page underneath was done in Svelte. The problem of a consistent user experience becomes a difficult one. There are many questions arising.
Among the most important ones are:

  • Are we only sharing plain CSS here?
  • How about behavior?
  • Are web components really a solution for that?

As a result the freedom of technology should always be considered the least reason for doing micro-frontends. My recommendation is to have a clean approach in the beginning, but to choose a framework that at least supports multiple frameworks incl. a strategy for their communication.


  • Architect large, scalable apps using a collection of microservices
  • Deploy a multi-service app to the cloud with Docker and Kubernetes
  • Solve concurrency issues in a distributed systems environment
  • Leverage your Javascript skills to build a complex web app
  • Build a Server-Side Rendered React App to render data from your microservices
  • Understand how enterprise companies design their infrastructure
  • Share reusable code between multiple Express servers using custom NPM packages
  • Write comprehensive tests to ensure each service works as designed
  • Communicate data between services using a lightning-fast event bus
  • Write nothing but production-level code. No cutting corners!


  • Use micro-frontends to architect an app that dozens of teams can work on at the same time
  • Structure your apps to scale to millions of users
  • Understand how to divide a monolithic app into multiple sub-apps
  • Coordinate data exchanged between your microfrontends
  • Apply a production-style workflow with a full CI/CD pipeline
  • Deploy your microfrontends to Amazon Web Services with CloudFront
  • Isolate rules styling by applying CSS-scoping techniques
  • Judge whether microfrontends are an appropriate choice for your application

These above topics will be taught and each individuals have to convert monolithic projects into microsrvices and micro-frontends before entering into Module 4.

Curriculum is empty