Micro Service with API Gateway

Question

For my new project, I have to use Micro Services with Api Gateway. So I gathered detailed informations about Micro Service but the Api Gateway part is not clear.

My question is,

1. Is anyone know about how the request routing part is done in Api Gateway?
2. Is that can be done by simple if condition[pseudo code: if(keyword=="product") then route("product service")]?
3. Or Is that any better way to do it?

I am using C#.Net to develop Api.
I got some info about Api Gateway from https://www.nginx.com/blog/building-microservices-using-an-api-gateway/

Thermodynamics

API gateway acts like a secure proxy + logging. You can pass url to your product service that you want to access and gateway will proxy it. – Slaw

Answer 1

You pretty much asked three questions and they're all somewhat related so I'll try my best to address all three together.

For one, request routing in an API gateway is more than just a proxy and the implementation would not involve conditions to examine the request before shipping it off to a downstream service. API gateway would likely be the only entry point to your services in which authentication would also be taken care of on the layer to make ensure that a request has the permission to go to a downstream service. Authentication is likely to be another service itself. The high level implementation of the API gateway is likely to consolidate most if not all of the endpoints on all the downstream services.

Lets take a small example such as an e-commerce application that includes a service for listing products, searching products, and shopping carts. The API gateway would then also have these same endpoints and will delegate the request further to a service responsible for the request. The API in this example may have /products to list all products, /products?query=... to search products, and finally /carts/:id/products to list the products in a shopping cart. Hope this answers your question.

Aside from that, I know that you've mentioned that its for a new project and just wanted to give you 2 cents that this may not be the best architecture to use for your new project if your team is really small because there is a large operational overhead. Overhead that requires standardization, automating deployments, integration, etc. Its probably best to start off with a traditional MVC architecture and slowly evolve it to microservices when the project has taken off.

Cholecystectomy

It gives some idea. Thanks! – Thermodynamics

Answer 2

Depending on your architecture, you can use some really cool software like Weave with CoreOS (https://github.com/weaveworks/weave). We are using Docker to distribute our applications onto the CoreOS nodes, and then the internal DNS is handled by Weave.

This is really great because we can just forward the request through to the application name with a port, and then we are off and away.

For example, a user requests application.com/api/apiName/request/path

Our gateway was implemented with Node.js, and it takes the apiName after /api to route it to that api, and then the following path of the URL to append to the call itself.

So the request from the gateway would be proxied internally as apiName:8080/request/path. In that regard, the API requires no changes when new services come up, as the path is created dynamically from your request.

This is great because we don't have to worry about tracking paths from the different API's and storing them somewhere.

If not that, you would have to maintain some (probably external) list of endpoints to make it easier for you. This could be done programmatically from the API's themselves.

I'm not sure what your requirements are, however, and as Will has answered, it does incur a pretty big infrastructure cost. However, our releases are fast and painless because we don't have to worry about making code changes in multiple layers, and the new API's get our gateway proxying, logging, and authentication for free.

Self