Microservices, Facades, and everything in between
What I call “purist” is the complete segregation between services’ responsibilities and upholding of strict service boundaries. For example: In a CMS (Content Management System), I’ll demonstrate that we can have one service responsible for content storage and another service responsible for content status and approval flow (e.g., draft, approved, published). This separation makes a lot of sense and demonstrates a good practice of microservices. These are the two of the fundamental building blocks of our imaginary system. We can all imagine the implementation of each service. The API’s can look like so:
Storage service
POST /item {title: string, content: string …}
Content State Service:
POST /item/new/[itemId]
It’s pretty straightforward — a new post is created by calling the first API; a new item ID is returned and used to call the second API to set the item in its initial “draft” state.
The question is: Whose responsibility is it to orchestrate this process?!
This is a pure business process that utilizes two different services that the system exposes. So let’s rephrase it as a more generic question — “Given a collection of basic (primitive) operations (services), where does the business logic get implemented?”
The correct answer is usually — in a new service! This is not trivial since many developers are wary of adding inter-service dependencies; however, it is not a bad practice. It’s true that services should be “loosely coupled” as a rule of thumb, but when orchestrating complex workflows that involve several services, we can’t avoid it.
What is a Facade?
From Wikipedia:
“a facade is an object that serves as a front-facing interface masking more complex underlying or structural code.”
In other words, a facade simplifies the utilization of complex flows by exposing simple APIs. So the know-how of the internal workings of the flow remains internal to the system. A classic facade does not contain logic but only wraps a complex interface. Still, in the case of microservices, it is common practice to encapsulate the flow within the facade service.
There are, of course, other architectures that can be applied to manage complex workflows; however, the facade is probably the easiest to implement and manage over time. As the system grows, we will have multiple “core” services and multiple “facade” services that compose different business flows and logic for different contexts and use cases.
A caveat in this approach is to create a “catch-all” service for housing all the system logic. This service (facade, API Gateway, or any other name you give it) will quickly become a monolithic service. This approach beats the purpose of microservices and will become a development bottleneck (not to say nightmare) before long.
The last dilemma I wish to address in this short post is this: I have a facade that composes a basic process. Now I need a new flow that extends this process. Is it a good practice to compose “facades” — i.e., a new facade that triggers an existing “facade” and adds to it, thus creating a new flow?
Well, not really. The idea of a facade is to expose an easy-to-use API. When we overload it, we are back to a hard-to-understand API. It also creates unwanted dependencies between logical flows and will lead to spaghetti relations. The correct solution is to re-compose the flow and expose it in a new facade that does not depend on the “old” one. This solution may seem redundant, but it will be much easier to maintain and refactor; plus, this may be more efficient as there are fewer service hops.
I hope this makes sense and helps you separate the “primitive” (CRUD-focused) services from the business-focused capabilities that the API exposes to achieve a more robust and maintainable system.
