CODEWITHSUNDEEP
microservicesmicro-frontend
moinster
moinster

Reputation: 141

Communication Microservices/Microfrontend Architecture

When reading literature about microfrontends, I always see that the frontend is composed of microfrontends that different teams develop. Each microfrontend has at least one backend. What I do not see is that the backends communicate with each other. Is that right? Are they that way separated that they can completely live with out any communication between the backends?

Upvotes: 1

Views: 873

Answers (1)

Adam Arthur
Adam Arthur

Reputation: 429

Benefits of microfrontends:

  • Ability to deploy UI code independently between teams/domains
  • Ability to use different technologies per team
  • Hard boundaries/encapsulation of UI code for that domain
  • Faster build, test, deploy times given smaller codebase

Optimal microfrontend architecture:

  • Assuming a single user facing webapp:
  • A "platform" microfrontend serves the "skeleton" page
  • From the user's perspective, it's a single site with one domain name (avoids CORS issues)
  • The "skeleton" page calls out to team specific frontends, based on namespaced routes, typically this path-based routing is handled via an ingress or reverse proxy (e.g. /namespace/accounting goes to the accounting frontend)
  • Frontend service (microfrontend) is strictly responsible for presentation issues, and often calls out to other backend services that have ownership over various data.
  • Frontend service contains logic for both serving static assets/components, and for handling ajax requests/composing UI specific data.

Summary:
Your frontend service will generally have to call out to backend services to compose data for presentational purposes. For example, if you need to display user data, you will likely need to call out to some UserService or AccountService to get additional details about that user. I don't recommend attempting to build a separate datastore with replicated data that's specific to the frontend service.

The frontend service typically shouldn't contain business logic; however, there's an argument to be made that for smaller apps/earlier on it can make sense to have a single service that handles both the UI and business logic for the same domain. It's generally the lesser evil to have services that are too broad rather than too narrow.

However, in a microservices architecture it's still important that you keep necessary dependencies between services to a minimum. A common problem is running into "dependency" hell, where you call Service A, which needs to call Service B and so on, which makes the architecture slow and brittle. A frontend service would typically make calls to services that are only "one layer deep", and then compose those responses into a single display data/payload.

Finally, it's very important that you choose the boundaries of your frontend service/domain wisely. It shouldn't be the case that you have many frontend services that all need to frequently call out to the same backend services. Better to start with a single broad frontend service and break it down further as you become more confident in the boundaries.

Upvotes: 2

Related Questions