Micro Applications and Microservices Together
This post discusses integration of micro-applications and microservices. This is a short post and a follow up of previous two posts on the subject of microservices and micro-applications. Please have a look at the following two posts before reading this. Even a quick glance through diagrams in these posts will help in reading this post.
This post discusses the integration between rich-UI and backend services. A rich-UI is decomposed as multiple logical pieces, each called a micro-application. The backend services are similarly broken into multiple pieces as microservices.
There is no magic about rich-UI talking to backend services using API calls as ajax-requests. It is a common pattern. Therefore you will be wondering what is so special about this integration. What does data driven integration mean?
Microservices and micro-applications change more often than large monolithic applications. The agility and ability to change often are main benefits and also reasons of microservices architecture. A microservice should be able to change without requiring any change in its peer UIs or microservices. Any change in one component should not break others. For example, when a newer version of API of a microservice is deployed, it should not require changes in URLs by its invokers. Microservices may provide each application a different level of authorization or require to use different id/secret pair to obtain access-token. These requirements make integration of microservices and micro-applications different from a monolithic application. In short, the integration should happen dynamically without having to restart components that did not change. It should not require code changes in other components.
In this post we propose a simple technique for integrating micro-applications with microservices which fulfills requirements discussed above. The integration is achieved through a per-micro-application configuration file which specifies endpoints’ mapping, permitted roles, id/ secret to be used for each URL. This file is called “routes.json” in the following diagram.
- When rich-UI makes a called, it knows the context of application due to address bar URL or templates it loaded. In each API call to the server, UI sends application name as a header, say X-APP-NAME.
- Based on it, API gateway loads application specific “routes.json”. To optimize the performance of call, API gateway may cache “routes.json” and “access-token” retrieved using id/secret.
- “routes.json” has mapping for all end-points used by its micro-application. Each entry is as shown below. This is for illustration. A specific implementation may use a different meta-model. In this file, “path” corresponds to the incoming URL pattern which is mapped to “location”.
Any change in the API mapping, for example from version 1 to 2, can be affected by changing entries in the file. Assuming that the API gateway is observing changes in the file or receives a trigger some other way, it refreshes its cache and so on.
Conclusion
Microservices and micro-applications make software agile and autonomous. A data driven approach through “routes.json” provides an equivalent integration mechanism and weds two together.
