-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Microservice Architecture with Kong #844
Comments
just add a new API with the |
If you do that and call any of those other APIs with example.com/path, this API @ahmadnassri suggested will "eat" all requests, since |
@ahmadnassri Using @thibaultcha I noticed this as well which is why I asked about Kong's proxy rules. Thanks for clarifying. |
Closing this since it is a question and tickets have been opened to track the decisions. |
I've been evaluating Kong for fronting a Microservice architecture which will serve a web application under a single domain.
It's clear to me the advantages for API development and the ability to centralize typical API requirements: rate limiting, authentication, authorization, etc. However, is Kong a good choice for Microservice architectures which must additionally support features of a typical web application, such as serving HTML/CSS/JavaScript?
As Kong is RESTful, I cannot foresee any obvious limitations for this architecture, but the more I dig into and attempt an implementation, I'm less certain.
I was informed yesterday on gitter it is not possible for Kong to proxy requests which are unmatched to a registered API. Therefore only Kong can return 404 errors in this scenario.
To further illustrate the problem, suppose I have the following API's registered and DNS for
example.com
is pointed at Kong:What are Kong's proxying rules in the case of
example.com/products
andexample.com/products/embed
? Also, if a request is made to simplyexample.com
, Kong will return a 404 response in JSON format, which in the case of a web application is likely not wanted.My concerns for this type of architecture could simply not be ideal for Kong, but since "Microservice" has already become an often-used nebulous term, it may help to clarify Kong's position on the matter.
The text was updated successfully, but these errors were encountered: