mu-semtech / mu-dispatcher Goto Github PK

Support dispatching based on hostname

[suggested by @cecemel]

Problem description

Some mu-projects offer answers for multiple hosts. The current dispatcher can not relay traffic to multiple hosts.

Current use-cases are:

• Run multiple frontends on one backend
• Run different services for different hostnames

Ideal solution

It should be possible to dispatch differently based on the host in the dispatcher.ex.

A realistic solution is to allow addition of constraints on a destructed hostname for easy matching.

A perfect solution would allow for aliases to be defined in the docker-compose.yml such that they could be picked up by the dispatcher.ex. No idea how such a thing would work technically (if it could work).

Add an environmental variable that adds optional logging.

If active this service should log a line containing the name of the service and the route reached when the dispatcher calls a backend service

Hello,

When I try to make a call using websockets from an Ember.js application to a python web server through the dispatcher, I consistently get this error:

VM12332:161 WebSocket connection to 'ws://localhost:88/push-service' failed: One or more reserved bits are on: reserved1 = 0, reserved2 = 1, reserved3 = 1

When plugging directly the frontend and the backend it works. Does the dispatcher properly proxies websockets calls?

Currently you can only add a layer to a call manually and one by one like

match "/assets/*path", %{ layer: :static } do
  forward conn, path, "http://frontend/assets/"
end

get "/index.html", %{ layer: :static } do
  forward conn, [], "http://frontend/index.html"
end

We are aiming to allow the following syntax

in_layer :static do

  match "/assets/*path" do
    forward conn, path, "http://frontend/assets/"
  end

  get "/index.html" do
    forward conn, [], "http://frontend/index.html"
  end

end

Resulting in less repetition and a much cleaner code

(opened this issue as a reminder not to forget to add this feature to the readme)

reverse_host is similar to host. https://github.com/mu-semtech/mu-dispatcher#matching-on-host
but is different as it will match the start of the url instead of the end. So very useful for matching subdomains for example

Example:
%{ reverse_host: ["harvesting" | _rest ], layer: :static }
will match any url starting with "harvesting"

Success:
"harvesting.redpencil.io"

fails:
"redpencil.harvesting.io"

I assume it's either before all other layers, or after all other layers :)
Would be handy to have in the readme which one it is.

E.g.:

defmodule Dispatcher do
  use Matcher



   define_layers [ :api_services, :api, :frontend, :not_found ]

  match "/path" do
    forward conn, path, "http://foo/"
  end

  match "/path", %{ layer: :api } do
    forward conn, path, "http://bar/"
  end
end

will a request to /path be forwarded to foo, or to bar?