You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working on a rather large e-commerce project and the pattern we chose for our micro-frontends is a bit different from the vertical pattern you describe.
Basically, we have:
a (growing) number of strictly back-end microservices handling everything from querying the user repository to synchronizing our data with the legacy system,
a (growing) number of strictly front-end microservices handling, well… the front-end aspects.
Part of our reasoning comes from the fact that we are transitioning from a monolithic legacy system to a microservices-based system and that transition implies different lifecycles for our back-end services and our front-end services. It's a lot easier for the latter to reach a stable "target" state, but the former will have to go through more evolution to reach that state. By decoupling the micro-frontends and the "micro-backends" (we don't call them like this, actually, but it seems to describe them quite well) we allow them to live separate lives and be deployed separately, in a more "atomic" manner.
Technically speaking, our micro-frontends are made of:
a Spring Boot/Cloud application whose job is limited to registering the micro-frontend into the whole system, serving assets, and reverse-proxying request from the front-end to various "micro-backends",
a React application that only knows how to query stuff within the micro-frontend itself.
The text was updated successfully, but these errors were encountered:
I've been working on a rather large e-commerce project and the pattern we chose for our micro-frontends is a bit different from the vertical pattern you describe.
Basically, we have:
Part of our reasoning comes from the fact that we are transitioning from a monolithic legacy system to a microservices-based system and that transition implies different lifecycles for our back-end services and our front-end services. It's a lot easier for the latter to reach a stable "target" state, but the former will have to go through more evolution to reach that state. By decoupling the micro-frontends and the "micro-backends" (we don't call them like this, actually, but it seems to describe them quite well) we allow them to live separate lives and be deployed separately, in a more "atomic" manner.
Technically speaking, our micro-frontends are made of:
The text was updated successfully, but these errors were encountered: