I will assume that you know the theory of MicroServices, and i will assume that you need a hands on reference aid on how to build a Complete MicroService Based REST APIs utilizing the benefits of the concept and also simple enough to build over.
Values we seek from MicroService
Build as much independent raw functioning services fulfilling the whole domain functionality.
Making sure that every Service is running and maintained separately without any crack due to another service defect.
Providing a separate deployment ready services, the thing that will aid on managing the load upon certain service separately with MAX. cost control.
Supporting any combination of workflows using the MicroServices without the need to change the Services implementations.
I use a GateWay for MicroServices communication
The alternative is “Point to Point” communication, where the services can communicate with each other for sake of certain workflow or dependencies, but the issue about this technique is that we are no fully satisfying the Services dependencies and highly coupling the services stability on each others, and further more the Point to Point configuration is a nightmare specially when we have many domains.
The Design Essentials
Every MicroService represents a different domain with standalone and self concerned business logic.
Every MicroService doesn’t has aware enough with the other MicroServices end points of even functionality, so MicroServices direct communication is totally prohibited.
Every MicroService is a REST API with unique EndPoint and could be hosted separately with unique security configurations.
GateWay is a REST API with unique EndPoint.
GateWay is the only EndPoint exposed to the FrontEnd Applications, so Microservices are only accessible by the GateWay.
GateWay is the the place to build specific business workflow using the different MicroServices.
Finally, and i haven’t seen any one apply this role 100%, is to make sure that every MicroService using its own DataBase and DataModels with any need to data from other Services DataBases, this is perfect to keep improving you Design to fulfill this concept and to save the separation down to all layers.
Sample Generic Business Practice
We need to build a Microservices to handle a TimeSheet System functionality.
we will need the following MicroService:
- UserAPI (Host In http://ip:port/api)
- MessagingAPI (Host In http://ip:port/api)
- GetAllMessages …
- PostMessage …
- DeleteMessage …
- PostReply …
- VacationAPI …
- PostNewVacation …
- DeleteNewVacation …
- GetAllVacations …
- PutExistVacation …
- TimesheetAPI …
- PostNewTimeSheet …
- PutExistTimeSheet …
- GetAllTimeSheets …
- ReportingAPI …
- GetReportDataById …
- ProjectAPI …
- PostNewProject …
- PutExistProject …
- DeleteProject …
- GetAllProjects …
- GetProjectById …
- AddUserToProject …
Now, we have 6 Separate and independent MicroServices hosted separately in different endpoints (ip/port).
Now we need to build another REST API represents the GateWay handelling the business Workflows to call from the FrontEnd Application (DeskTop APP., Web. APP. , Mobile, another Service , …etc).
e.g. Build GateWay REST function to Create Project and Add all users to it.
Steps In GateWay :
Create Project by calling the ProjectAPI function PostNewProject
Get All User by calling the UserAPI function GetAllUsers
Enumerate on the Users and Call The ProjectAPI function AddUserToProject.
Return Operation Status
This Function should be a Post function expects [From Request Body] an object of Project, and the GateWay function should respond with Status (200, 404, 400, 500, …etc) according to how you handle the API errors.
so at the end , the FrontEnd application communicates with an API like http://gatewayip:port/api/postprojecttoeveryone
The Microservices changes cadence should be minimal as it provides a row fundamental CRUD operations over specifuc business model.
Every business Application with different requirements require New GateWay and not new MicroServices.
Exception Handling and Error Pulling should be in a way to stop the technical inner exception on the layer of GateWay and Log It, and send Friendly helpful messages with Error Code as a GateWay responce.