Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom message routing for the proxy engine #14

Open
Relrin opened this issue Oct 30, 2018 · 0 comments
Open

Custom message routing for the proxy engine #14

Relrin opened this issue Oct 30, 2018 · 0 comments

Comments

@Relrin
Copy link
Member

Relrin commented Oct 30, 2018

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:

  1. The search endpoints that uses static routing and gives to proxy an information about which AMQP queue must be used for sending a request.
  2. The users endpoints that uses dynamic routing for balancing all incoming requests to AMQP queues / request exchanges of Auth/Auth microservice:
    • An action in 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 into auth.users.retrieve, because the action has the retrieve value and was used in /api/users/{action} template, where that value was used.
    • The same rules applies to routing_key, request_exchange and response_exchange, if were specified any substitutions.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant