Complex Routing

[Vad1mo]

Summary

I wonder if I could do some more complex routing. My scenario works nginx but not with API Gateways known to me.

I have two services behind one Url (app.company.com). Lets call one service "Website" and the other "API Service"

The "API Service" should receiver traffic for

app.company.com/v2/*

The "Website" should receive traffic for

app.company.com/*
app.company.com/v2/token
app.company.com/v2/webhook

So the tricky part here is that /v2/token and /v2/webhook should go to "Website" instead to service.

In nginx I have to create 4 locations to make this work, it does not work with only 2 locations and regex magic.

Additional Details & Logs

• I would like to use the latest Kong version

If found the PR #1970 which explains the router but does not answer my question.

[Tieske]

yes, you can do that. Longer uris are matched before shorted ones.

The down side is that the website will consist of 3 apis in Kong terminology. You might also consider exposing a different path on the outside, and internally forward to the proper ones. eg. app.company.com/api/v2 to internal upstream internal_host/v2/. That would be doable with 2 apis

[coopr]

@Vad1mo in your desired configuration, will Kong be proxying requests for your website content (eg. images, HTML, CSS, JS, etc)?

[Vad1mo]

Thank you for the clarification.

@Vad1mo in your desired configuration, will Kong be proxying requests for your website content (eg. images, HTML, CSS, JS, etc)?

Yes. The situation is the following, there is a Admin Dashboard. In my simplified example I call it "Website". In reality that the Web application serves HTML,JS Content and also a REST API.
/v2/token /v2/webhook are the provided API services of the web application. The "Api Service" is consumed by the end user. The "Api Service" is using the token service.

I know that Kong, wasn't designed for this, but I guess it isn't a problem even if the gateway is also proxying to a website. Or Are there any other solutions without to many applications involved.

You might also consider exposing a different path on the outside, and internally forward to the proper ones. eg.

Unfortunately It isn't possible to expose a different path to the outside as @Tieske suggested. All clients out there expect a v1 or v2 path and there are many clients. What I could do is to change the web application and its api path.

[thibaultcha]

I know that Kong, wasn't designed for this, but I guess it isn't a problem even if the gateway is also proxying to a website. Or Are there any other solutions without to many applications involved.

Nginx on the other hand, is definitely built to handle such use-cases. I would suggest using a custom Nginx configuration with a location block for serving your website, and one for serving Kong. Your website location block can definitely use settings that are more appropriate for such reverse-proxying of assets files, thus giving you the best of both worlds: a Kong instance able to proxy your APIs and your website in an efficient manner.

[Vad1mo]

Before closing the the issue. One final question for clarificatigon
@thibaultcha

I would suggest using a custom Nginx configuration with a location block for serving your website

Am I right that you personally would recommend to create a cascading proxy hierarchy, where a second nginx instance is located in front of kong and is serving the static website and otherwise forwarding to kong. Doesn't it make the whole setup overly complex as you need to take care of load balancing on two instances and.

Or do you mean (if that it is possible/recommended?) to provide kong with an additional custom nginx.conf with location and tuning for the static website/content?

I am asking the reassurance question to better understand the best/common practice approaches when working with kong.

[thibaultcha]

Or do you mean (if that it is possible/recommended?) to provide kong with an additional custom nginx.conf with location and tuning for the static website/content?

This is what I mean. The goal is indeed not to have to maintain a second Nginx instance, and take full advantage of the fact that Kong is built on top of Nginx and is a drop-in replacement (or will be). We thus kill two birds with the same stone 😉

[Vad1mo]

🥇 Drop-in replacement for nginx

Thank you very much for clarification.

[gszr]

Related documentation added here.