Search code examples
microservicesnetflix-zuulapi-gateway

How to define API gateway URLs when splitting a monolith into microservices


We are splitting a monolith application into microservices. This will be a gradual process, it means initially we will start with 2 microservices, later we will split them into more and so on.

The monoligh exposes a REST API which provides methods for managing tens of different entities (e.g. users, user_types, roles, role_types, etc.). There is only one consumer of the REST API exposed by the monolith - a Javascript frontend app.

We are currently investigating two possibilities how to configure the API gateway (Zuul):

  1. URLs will contain the microservice name, e.g. /api/dictionary will serve /api/dictionary/user_types and /api/dictionary/role_types, while /api/data will serve /api/data/users and /api/data/roles. It means the URLs will change over time as we create more microservices. Everytime we do it the consumer (frontend) will have to be changed.

  2. URLs will be based on the entity names, e.g. /api/users, /api/user_types, /api/roles and /api/role_types. The disadvantage is that the Zuul configuration will have to contain an explicit configuration for every single entity managed by the system.

Which of the above approaches is correct?


Solution

  • Manmay saying is correct. You should go with first approach for long term gain. If you still want alternative, then you can combine both of these approach by configuring your API gateway in such a way that, It will route your request

    • /api/users -> /api/data/users
    • /api/user_types -> /api/dictionary/user_types
    • /api/roles -> /api/data/roles
    • /api/role_types -> /api/dictionary/role_types

    By this approach, you will not have to compromise any of the concerns like maintenance or client side changes.