Microservices are great — single-responsibility, domain-specific APIs that are independently iterable. A major web application can be composed of tens to hundreds to even thousands of these little guys.

They can scale independently, give app teams the ability to code in the most appropriate language to get the job done, and leave you with a small blast radius if something fails (meaning the entire app stays up if a single microservice fails).

All the big guns are doing it too. Uber has ~2,200 microservices, Netflix has around 700, and Amazon… well, Amazon has a lot.

But did you know you can apply the same basic principles to the front end? Micro doesn’t have to apply only to the back-end APIs.

---

What Is a Micro Frontend?

Micro frontends follow the same concepts and offer the same benefits as microservices. They take your big UI monolith and slice it up into small, isolated, independently iterable chunks.

Simple micro frontend architecture

After the initial build, chances are high that your UI is going to iterate more often than your back end. Be it big or small, you’ll go through more cycles, making the user experience the best you possibly can.

As you should!

So doesn’t it make sense to divide your front end into bite-sized chunks? Yes!

Now, I don’t want you thinking that building your application with micro frontends will make the user experience feel disjointed. That is not the goal. That’s an anti-goal. You want your app to continue to feel cohesive while quickly iterating on small features.

If you’re thinking about getting into continuous delivery, I would highly recommend considering also getting into micro frontends. Delivering small, incremental updates is exactly what this architecture is about, and with micro frontends, you’re enabling yourself to do so.

#startup #programming #software-engineering #devops #software-development