-
Notifications
You must be signed in to change notification settings - Fork 2
Description
In actual moment of time a developer should define all desired endpoints in configuration file that have YAML format and will be passed as a parameter in CLI before the start. It's fine for a couple of endpoints, however in the case of multiple microservices the efforts for maintaining this table significally increases, when necessary to specfy all of those.
To minimize a maintenance efforts, we can optimize this process, so that it will use much more cleaner and easier way to handle those cases:
- Give an opportunity to specify "dynamic paths", so that the developer will define only a couple of generic resources on the base of some template
- For some corner cases let to developers to use the "static routing" (that currently using for all of it)
As for example I will use the following configuration, that must be supported and valid:
endpoints:
- search:
url: "/api/matchmaking/search"
routing_key: "matchmaking.users.{action}"
request_exchange: "open-matchmaking.matchmaking.search.direct"
- users:
url: "/api/users/{action}"
routing_key: "auth.users.{action}"
request_exchange: "open-matchmaking.auth.{action}.direct"In this example we have 2 endpoints:
- The
searchendpoints that uses static routing and gives to proxy an information about which AMQP queue must be used for sending a request. - The
usersendpoints that uses dynamic routing for balancing all incoming requests to AMQP queues / request exchanges of Auth/Auth microservice:- An
actionin curly braces is a parameter that stores a suffix and going to be used later in the templates for generating names of AMQP queues, request and response exchanges. For example the/auth/users/retrieve/URL will be transformed by proxy engine intoauth.users.retrieve, because theactionhas theretrievevalue and was used in/api/users/{action}template, where that value was used. - The same rules applies to
routing_key,request_exchangeandresponse_exchange, if were specified any substitutions.
- An
Any patterns or substitutions must not be defined only in the end of strings. They can be specified in the middle of the template, or in some cases may be even starts with it.
Besides of it the developer must replace "microservice" onto "routing_key", that must be used in configuration files instead, because shows that this field is required for passing messages.
For the cases, when the passed URL in the incoming request format is valid, but AMQP queues, request and response exchanges may not exist, we must return an error with a message like "Endpoint wasn't found" instead of waiting infinitely. It can be done with creating a "error queue" per each client that linked to the special exchange (or may be even "open-matchmaking.responses.direct") for tracking a messages that can't be delivered to the certain microservice.