Hello Son 👶🏻,

I know that you are a genius creator of things using Legos.

Imagine your traditional front-end application as a non-composable Viking City castle toy. There you get what the toy company built for you and you cannot modify or change later as you wish.

But what if you build your castle with 5 other friends at the same time as you wish using Legos? These legos might have been designed by another toy company to be compatible with the original Legos you have and one of your friends is using that to build part of your castle.

So consider your Lego work above as our micro frontend. This shares the same concepts as the micro-services. People understood that by using this they could achieve below.

So, the advantages of using micro-frontends are:

Faster Changes: You can make updates or add new features more quickly because you're only working on one small part at a time.

Independent Development: Different teams can work on different parts of the frontend without stepping on each other's toes. They can develop and deploy their parts independently.

Easier Maintenance: If something goes wrong in one part, it's easier to find and fix the problem without affecting the rest of the frontend.

Scalability: As your project grows, it's easier to scale because you can add new features or modules without having to rebuild the entire frontend from scratch.

Let's explain this to your Dad 🧔🏻‍♂️!

...

Evolution 🚀:

GW = Gateway / FE = Frontend / BE = Backend

Monolithic: In the early days of web development, applications were built as monoliths. This means that both the frontend (the user interface) and the backend (the server-side logic and database) were tightly coupled together in a single codebase. Making changes or adding features required modifying the entire application, which could be time-consuming and risky.

Frontend + Backend Separation: As web applications grew in complexity, developers began separating the frontend and backend components. This separation allowed for more specialized teams to work on each part of the application independently. The frontend communicated with the backend through APIs (Application Programming Interfaces), enabling better scalability and flexibility. However, the frontend itself often remained monolithic, making it challenging to scale or modify without impacting the entire frontend.

Microservices + Frontend: With the rise of microservices architecture, developers started decomposing the backend into smaller, independently deployable services, each responsible for a specific business function. This approach improved scalability, fault isolation, and development agility. However, the frontend remained relatively monolithic, presenting challenges in coordinating frontend updates with changes in the microservices architecture.

Microfrontend + Microservices: The evolution culminates in the adoption of microfrontend architecture alongside microservices. Microfrontend architecture extends the principles of microservices to the frontend layer, allowing frontend components to be developed, deployed, and scaled independently. Each micro-frontend represents a distinct part of the user interface and can be owned and maintained by separate teams. This approach enables greater flexibility, faster iteration times, and improved autonomy for frontend development teams.

Most importantly we need to remember the decision to make your frontend a micro-frontend is based on a lot of facts including your requirements and the evolution of the application in the future or now with the priority in mind.

If you feel that you want to dig more into concepts read the article at Martin Fowler's website here.

🏋️‍♂️

Enough talking! Let's make learn by doing. We are going to build a real-life micro-frontend with Next.js, Nuxt.js, and the latest Angular Framework in my next article. Dad's will love it! Stay tuned!

Next.js is a React framework / Nuxt.js is a Vue Framework