Host based route matching

[restyler]

Hello,

I am considering switching to fast-gateway from my own custom quick&dirty gateway implementation based on http-proxy.
My use case is based on domains for APIs, instead of /prefixes, so basically I want api gateway to map current request to specific API service on the base of Host header.

Here is how I implement it in my own code:
https://github.com/restyler/api-gateway/blob/master/gateway/src/server.js#L113
https://github.com/restyler/api-gateway/blob/master/gateway/api.http#L7

Stub API servers are launched using vhost package ( https://github.com/restyler/api-gateway/blob/master/gateway/src/server.js#L141 ).

I am probably missing something, but I don't see obvious way to do the same trick in fast-gateway . Can you please point me to the right direction how this can be solved?
Thanks!

[jkyberneees]

Hi @restyler thanks for your interest in this project.

Below I want to show you how this would look like using fast-gateway, I will release the new hostnames-hook implementation and the example ASAP.
My recommendation would be to basically map hostnames to prefixes. In this way we can hold the performance of the path based router.

Looking forward to your considerations:

[restyler]

Hi @jkyberneees thank you for your prompt reply and the proposed solution!
It should do the job, but in terms of code readability I think there is a room for improvement - reading the routes definition now does not give the full picture on the gateway schema, since jumping back and forth between hostnames2prefix and routes() is now required.
I'm not sure I can grasp all technical limitations here, but In terms of external gateway API I would prefer to get rid of unnecessary 'prefix' and have something like:

gateway({
  server: app,
  matchByHost: true, // or matchBy: 'host' / 'url_prefix' ?
  middlewares: [
  ],

  routes: [{
    match: 'node.com:443',
    target: 'http://localhost:3000'
  }]
})

May be it does not make sense, just my 2 cents.
Thank you!

[jkyberneees]

Hi @restyler , excuse my delay on this thread.

Totally valid question and remark from your side. I basically agree on the fact that my proposal looks like not integrated with the current configuration approach.
As you also mention, the reason is because of technical limitations. Let me explain:

The current library was initially designed for API Gateway implementations. Meaning, we enable developers to decouple big APIs and monoliths into REST based microservices while still providing a single entry point to their applications. (read more)
The core implementation was based on url prefix routing, this would allow us to benefit from existing frameworks like restana or express.js in regards of their routing capabilities as well as middlewares support. Basically this is the reason why this gateway framework is so fast and so easy to extend, since we could reuse basically the hundreds of existing middlewares available at NPM.

This is why my proposal for supporting hostnames goes on the same direction to keep performance, a critical requirement for this kind of application component.

I hope I could give you some data points.

Regards

[restyler]

This totally makes sense @jkyberneees , thank you for the details. I'd suggest we consider this issue as solved :)