Building a MicroService APIs using the GateWay Pattern


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 

  1. Build as much independent raw functioning services fulfilling the whole domain functionality.

  2. Making sure that every Service is running and maintained separately without any crack due to another service defect.

  3. Providing a separate deployment ready services, the thing that will aid on managing the load upon certain service separately with MAX. cost control.

  4. 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

  1. Every MicroService represents a different domain with standalone and self concerned business logic.

  2. Every MicroService doesn’t has aware enough with the other MicroServices end points of even functionality, so MicroServices direct communication is totally prohibited.

  3. Every MicroService is a REST API with unique EndPoint and could be hosted separately with unique security configurations.

  4. GateWay is a REST API with unique EndPoint.

  5. GateWay is the only EndPoint exposed to the FrontEnd Applications, so Microservices are only accessible by the GateWay.

  6. GateWay is the the place to build specific business workflow using the different MicroServices.

  7. 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:

  1. UserAPI (Host In http://ip:port/api)
    1. PostNewUser        http://ip:port/api/post
    2. PutExistUser         http://ip:port/api/put/id
    3. DeleteExistUser   http://ip:port/api/delete/id
    4. GetAllUsers           http://ip:port/api/get
    5. GetUserById          http://ip:port/api/get/id
  2. MessagingAPI (Host In http://ip:port/api)
    1. GetAllMessages
    2. PostMessage
    3. DeleteMessage
    4. PostReply
  3. VacationAPI
    1. PostNewVacation
    2. DeleteNewVacation
    3. GetAllVacations
    4. PutExistVacation
  4. TimesheetAPI
    1. PostNewTimeSheet
    2. PutExistTimeSheet
    3. GetAllTimeSheets
  5. ReportingAPI
    1. GetReportDataById
  6. ProjectAPI
    1. PostNewProject
    2. PutExistProject
    3. DeleteProject
    4. GetAllProjects
    5. GetProjectById
    6. 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 :

  1. Create Project by calling the ProjectAPI function PostNewProject

  2. Get All User by calling the  UserAPI function GetAllUsers

  3. Enumerate on the Users and Call The ProjectAPI function AddUserToProject.

  4. 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

Important Notes

  1. The Microservices changes cadence should be minimal as it provides a row fundamental CRUD operations over specifuc business model.

  2. Every business Application with different requirements require New GateWay and not new MicroServices.

  3. 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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s