how to build microservices that also have GUIs

Question

In a microservices architecture where each component does one thing, how do you handle GUI logic? How do you avoid building a front end web application that has a lot of smarts built into it where it knows some of the internal workings of each microservice it calls?

Let's say we have a website for employees in Acme to use to get office supplies delivered to them. We would have a sign in component... an inventory component... and a delivery component. We build a web interface to wrap all 3 components together. Inevitably in order for us to show what's in stock, in addition to calling the inventory API (that provides basic CRUD functionality to maintain inventory), the web application would need some knowledge of inventory "stuff" to be able to display things properly. This means the web developer that is creating the GUI application would need to be in communication with the API devs... who may or may not be in the same time zone etc.

One way to handle this would be to have domain developers include GUI logic as a part of the REST API.... code on demand. So the main GUI guy who is building the main interface can call methods on the APIs that return HTML or javascript or whatever. But the downside of this method is that the code on demand methods would basically hide some implementation details.

Interested in hearing your opinion / thoughts. Thanks.

Answer 1

If this

This means the web developer that is creating the GUI application would need to be in communication with the API devs... who may or may not be in the same time zone etc.

is your core issue, your documentation is lacking. Microservices should be self-explanatory enough that barely any dev-to-dev communication is needed. Typically it's just an API spec that is easy enough to understand. I've built plenty of services on top of other services without ever talking directly to their developers / maintainers.

That being said, if architecture-wise you don't want to expose certain low level CRUD services or don't want to chase the application developer all across multiple services for a typical application case, you always can build higher level micro-services that aggregate lower-level functionality. This can either be process services that model a particular process or even backend-for-frontend^1 services that explicitly provide an API for a particular type of frontend. Like a public API that a team inside a company or a company as a whole makes publicly usable for external application/frontend development, while keeping the lower level services only internally exposed.

^1 Checkout the backend-for-frontend pattern. https://www.google.com/search?q=backend+for+frontend+pattern

Note that this is related to API gateways, but semantically different. An API gateway aggregates different backends into one API. You can realize the backend 4 frontend pattern with a 3rd party API gateway solution, but you could also, for instance, deploy a dedicated service that serves that particular frontend, aggregates and transforms queries for it in more complex and custom ways than you typically could or would like to do with an API gateway software. You can consider your backend for frontend service concrete version of an API gateway. On the other hand, an API gateway providing a single public API to a company's data for instance isn't necessarily a backend for frontend, as it does not aim at a particular frontend, but rather to service a broad range of external software. However this is not a strict line, a company could consider their public API the backend for all third party frontends and assume they all have certain properties. Thus their API gateway would possibly be their backend for 3rd party frontends.

Answer 2

One option is to have 'Journey' or 'ProcessFlow' microservices where there are back-end micro-services that manage the process flow (or journey) through a state-machine. The state-machine captures the current process state of the end-user and provides an API where the front-end can query the possible next state. This removes the need for the front-end to incude potentially complex process logic (the front end needs to understand how to display each process state - the choice of which state is suitable is derived from the back-end API. Using Hypermedia APIs also allows these ProcessFlow APIs to hyperlink to more entity focused microserice APIs.

A sub-option is to use a BPM engine (like Camunda) to provide this process-flow backend.

Answer 3

Depending on what precisely you need, there are a few common approaches.

1 - Microservice backend, unified frontend

To put it simply, don't separate the GUI across services, but rather build a separate frontend application which interacts with the distinct microservice backends.

The benefit here is that you get complete control over the GUI and are able to ensure a consistent styling, on top of choosing what to display to the user and what not.

For example, while a component may need a user reference, the frontend application could supply this information itself without needing to ask the end user to supply that info.
Comparatively, the designer of only that component isn't able to make that judgment call and is much more likely to simply add the use reference as an input field (which you might not want), but the frontend designer is capable of making that decision.

2 - Component packages

On a technical level, this is no different from how you can include premade UI components libraries in your frontend, e.g. jQuery UI or the Angular Material UI component library.

As the component dev, you can similarly create frontend components in your framework of choice (Angular, React, JS, ...).

The frontend dev can then include those packages and rely on the components. All the frontend dev still needs to do is decide to use the component by including it on one of the pages (where relevant), without needing to design the component (or its logic) itself.

the web application would need some knowledge of inventory "stuff" to be able to display things properly

To some degree, this is inescapable. If you only let separate teams design their own component, without any coordination, you're going to end up with a hodge podge of visually clashing UI components that leave much to be desired in terms of clean UI.

While this can be somewhat overcome by having the frontend dev supply the styling, it's going to be more difficult to significantly restructure the UI elements on any given component when needed.
For example, that warehouse inventory component might need to look very different depending on whether it takes up the full screen or only half of the screen (with the other half e.g. displaying a picture of the selected item), or if it's a modal window intended for quick item selection. This is not something that a component designer can account for without having intimate knowledge of the needs of the frontend application that will depend on that component.