0

This is the continuation of Adding Data from UI to different microservices. That question was about splitting BE into microservices. Now, I'm looking for a way to decompose the UI into microfrontends as well.

Imagine you have a user registration form, where you fill in the form: First Name, Last Name, Age, Address, Prefered way of communication: Sms, Email (radiobuttons). You have 2 microservices:

UserManagement service Communication service When user is registered we should create 2 aggregates in 2 services: User in UserManagementContext and UserCommunicationSettings in Communication. So I feel like I should have 2 different UI components from 2 microservices, but how to place them in 1 form on UI? What happens when user clicks Submit button, how these components will send data to their services?

DmitriBodiu
  • 1,120
  • 1
  • 11
  • 22

1 Answers1

-1

So I feel like I should have 2 different UI components from 2 microservices, but how to place them in 1 form on UI? What happens when user clicks Submit button, how these components will send data to their services?

Microservices are applications and UIs are applications.

If your front-end requires all of the microservices to work, its one application and you should treat it as such, with one single UI, which is perfectly fine.

If some of the functionality is completely optional (and i.e. sold separately), you split the UI into modules and ship the modules separately.

Or in other words. If an (front-end) application requires multiple services to work and bring her functionality, its treated as one application and one UI. You pay split it in different views, but that still doesn't make it a different "microfrontend".

Having 15 isolated applications as front-end isn't going to solve much.

Tseng
  • 61,549
  • 15
  • 193
  • 205
  • Questions were: 1) how to place 2 different components in one
    . 2) What happens when user clicks Submit button, how these components will send data to their services?
     – DmitriBodiu Apr 04 '19 at 08:03
  • 1
    You need to think about how your UI application is used (and what the busines requirements are). If both of your features are distinct and always to be used as one, its one UI, so you just need one View. If its two distinct functions (which can be used independently of each other) you make two views. There is no rule or guideline that 1 microservice = 1 UI element/component. Microservices are about separating of concerns and for scalability (one microservice may require to run 40 instances other just 2, because it does get more request or does more computation work) – Tseng Apr 04 '19 at 08:09
  • Different UI Frameworks let you deal differently with components and compsable UIs. In Angular you may have two components for each of the functionalities, which you embed in your own component and have the button there, which then reads the value (or calls an action) of the sub components). Every application implementer decides how he treats this functionality. – Tseng Apr 04 '19 at 08:12
  • If you want to enforce that these two operations are always done as a single one, do an gateway api endpoint, which accepts input data of both and performs the operation on the backend and delivery an result to the UI but we know nothing about your requirements. Obviously from your question above both user registration and preferred communication rather seem to belong to 1 bounded context (which would also of course imply just one microservice) since you probably can't use the `UserCommunicationSettings` on its own. – Tseng Apr 04 '19 at 08:16
  • The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end, from database to user interface. Its not always about being able to sell a part of the applcation or whether application can't work without a piece of it. The main power is ubiquitous language inside the team and modular separation which brings speedy development. – DmitriBodiu Apr 04 '19 at 13:05
  • You can only do that if they don't depend on each other, the UI per se is completed unrelated to the microservices. If the requirement of the application is, that these to operations are to be performed together, then you put then in the same context/transaction, there are a lot of patterns to allow you do that (sagas/process manager pattern, call 1 service, call other, observe the results, roll back/do compensating actions to it).If you require **ALWAYS** do these to operation together you have to do that on the server (not on the UI), with i.e. an API gateway in front of your microservices – Tseng Apr 04 '19 at 13:12
  • Again, there is no rule or recommendation in either Microservices or DDD which enforces 1 BC = 1 UI/Component. The UI application is either need aware of what it needs to call (then you got logic front and backend) or you enforce it server-sided by offering a single endpoint it. Also not all microservices need to be public. you can hide your two microservices (by not exposing them) and have user go through a gateway api, which allows you to enforce such things, such as in https://user-images.githubusercontent.com/1712635/38758862-d4b42498-3f27-11e8-8dad-db60b0fa05d3.png – Tseng Apr 04 '19 at 13:16