Transparent urlprefix?

[rogeralsing]

My understanding is that Fabio requires you to register URL prefixes that are actually present in the receiving services.
e.g.
if you have a service running on http://localhost:1234/foo then you can use urlprefix-/foo , correct?

Is there any chance that Fabio could support "transparent" prefixes?
A sort of prefix that is used to let Fabio resolve what service you want, but is not used when talking to the service.
lets say I make a request to Fabio on http://localhost:9999/OrderService/api/orders/123 that could be resolved to just http://localhost:1234/api/orders/123
That is the "OrderService" prefix is removed.

That way, I would not have to specify each and every path my service responds to, and it would avoid ambiguity between services, e.g. if two or more services both listen to /api but are different services.

I might have misunderstood something and this might not make any sense, but the current behavior seems to require me to register every path explicitly instead of registering capability/service name.

[magiconair]

Right now I don't have plans to support URL rewriting since I would also have to support rewriting URLs in responses and I'm not convinced that URL rewriting is necessary in general. Services should announce the routes they serve and have handlers to service them. Fabio is fast even with lots of routes per host to the number of routes don't matter.

You probably don't have two services responding to /api directly but to some sub path like /api/foo and /api/bar.

Having two different services announce the same route (or parts thereof) allows you to migrate from one implementatin to another. Traffic shaping allows you to do this gradually. This is how we migrate Java services to Go or split up services which have become too large into smaller ones.

[magiconair]

Can you explain how many paths you would have to register and for how many services? I'm also interested in why you have an /OrderService prefix that is not used by the services. What is the use case for that?

To give you an idea: we generally register one or two routes per service.

[magiconair]

I have decided not to support this since fabio favors convention over configuration. If a service handles traffic on /foo/bar then it should announce that route and have a handler for it. By expecting the router to strip part of the URL the service behaves differently when run with or without the router which makes the router an essential part of the configuration. That is against the idea of fabio which is supposed to be stateless and zero-conf.

[rokka-n]

This makes a lot of sense, app should understand the routes it announces.

Btw, where did the docker-compose go? I remember there was a demo with compose.