Skip to content
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

Closed
pvormittag opened this issue Jan 7, 2016 · 5 comments
Closed

Microservice Architecture with Kong #844

pvormittag opened this issue Jan 7, 2016 · 5 comments

Comments

@pvormittag
Copy link

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:

{
  "data": [
    {
      "upstream_url": "http://admin.service.consul",
      "request_path": "/admin",
      "strip_request_path": true,
      "name": "admin.service"
    },
    {
      "upstream_url": "http://v1.api.service.consul",
      "request_path": "/api/v1",
      "strip_request_path": true,
      "name": "api.v1.service"
    },
    {
      "upstream_url": "http://product.service.consul",
      "request_path": "/products",
      "strip_request_path": true,
      "name": "products.service"
    },
    {
      "upstream_url": "http://embed.service.consul",
      "request_path": "/products/embed",
      "strip_request_path": true,
      "name": "embed.service"
    }
  ]
}

What are Kong's proxying rules in the case of example.com/products and example.com/products/embed? Also, if a request is made to simply example.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.

@ahmadnassri
Copy link
Contributor

just add a new API with the request_host set to example.com and it will proxy the requests unmatched by the paths back to whatever source you want ...

@thibaultcha
Copy link
Member

If you do that and call any of those other APIs with example.com/path, this API @ahmadnassri suggested will "eat" all requests, since request_host is looked up first and because host and path were never intended to be combined together.

@pvormittag
Copy link
Author

@ahmadnassri Using request_host makes sense if routing by domain, say api.example.com or product.example.com, but I am more interested in routing request paths of a single domain through to services which handle different concerns of the application: example.com/admin, example.com/store, etc.

@thibaultcha I noticed this as well which is why I asked about Kong's proxy rules. Thanks for clarifying.

@ahmadnassri
Copy link
Contributor

I've created a number of tickets to track the different aspects to this:
#847 #846 #845

@thibaultcha
Copy link
Member

Closing this since it is a question and tickets have been opened to track the decisions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants