When building apps, a common integration pattern is the use
of the microservice architecture. This architecture enables us to create lightweight
loosely-couple services, which the app can consume and process the information
for specific purposes or workflows.
Sometimes, we do not control these microservices, and they
can be designed in such a way that the information is fragmented in multiple steps.
This basically means that to get a specific domain model, we may need to
orchestrate a series of steps and aggregate the information, thus presenting a
bit of an architectural concern.
Unfortunately, orchestration of microservices on the app leads
to code complexity and request overhead, which in turns leads to more defects, maintenance
problems and slow user experience. Ideally, the domain model should be defined in
one single microservice request, so the app can consume it properly.
For these cases, a good approach is to use an orchestration
engine that can handle the multiple requests and document transformation. This
enables the app to only make one single request and expect a well-defined domain
model. This approach also abstracts the external microservices from the app,
and applies JSON document transformation, so the application never has to be
concerned with model changes.
To handle this architecture concern, we look at using an API Gateway to manage the API orchestration,
security and document transformation policy which handles the document aggregation
and domain model governance.
Client to Provider Direct Integration
See the image below for a comparison between an architecture
where the app calls microservices directly. This forces the application to send
multiple requests. It then needs to aggregate the data and transform it into
the format that it needs. There are a few problems with this approach. There is
traffic over head from the browser to the provider as multiple requests are
made. The app is also aware of the provider endpoint, and it needs to bind to
the JSON documents from the provider. By adding all these concerns to the app,
we effectively must build more complex code in the app.
Client to Gateway Proxy Integration
On the other approach. The app integrates directly to our
gateway. The app only makes one single request to the gateway, which in turns
orchestrate the multiple requests. In addition, the gateway handles the
document transformation process and the security concerns. This helps us remove code complexity from the
app. It eliminates all the extra traffic from the browser to the provider. The
overhead of the network traffic is moved to the gateway, which runs on much
better hardware.
We should clarify that this approach is recommended only when the microservices have fragmented related data. Usually a microservice handles a single responsibility, and the data is independent of other microservices.
Let me know what you have done when you have faced a similar integration and what is the result of your story.
.png "ozkary api orchestration")
.png)