I could be on the wrong track here, but employing a microservices-based architecture without a proper API gateway is considered a bad practice. The idea is similar to a reverse proxy of course (Nginx, HAProxy etc): a single interface (facade) sitting in front of all the individual services that makes life easier for clients since then they would just have to talk to one server.
Clients should not have to talk to the microservices directly, for a number of reasons:
The client has to make several separate requests.
Makes it extremely difficult to refactor the microservices e.g. merging or splitting existing services.
Imagine your services being relocated, IPs changing, ports changing, that the clients will have to adjust to e.g. by updating the allowed origins.
It is absolutely crucial that your clients and the microservices remain independently deployable, maintainable, scalable etc.
Of course, for different kinds of clients you could have different gateways like, famously, Netflix does.
The API gateway itself can and should handle limited business logic like combining responses from multiple services and returning them to the user or even authorization.
Although I didn't classify what @djviolin
wrote as a microservice but I might be wrong :-) I don't know if now "API server" as become a synonym for microservice.
Thanks for the link, I'll check it out!
Gateway wise I always wanted to check out Kong but I still haven't found a project to use it for.
Traefik seems a nice little project, but doesn't feature any authorization service and the biggest minus is cannot be extended with plugins (to have some kind of auth), but there is a PR request regarding this, based on Go's newest Plugin library: github.com/containous/traefik/issu...
Kong, Tyk, and KrakenD seems nice projects, they are also extensible with plugins.
Looks like these projects also managing load balancing and rate limiting, so using HAProxy is obsolute?
Largely subjective. You might even try developing your own gateway, nothing wrong with that.
I'd prefer using load-balancing, rate-limiting features if they ship with the gateway. Though consider caching as well.
Else, an Nginx/HAProxy instance could be placed in front of multiple instances of the gateway. Best of luck!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I could be on the wrong track here, but employing a microservices-based architecture without a proper API gateway is considered a bad practice. The idea is similar to a reverse proxy of course (Nginx, HAProxy etc): a single interface (facade) sitting in front of all the individual services that makes life easier for clients since then they would just have to talk to one server.
Clients should not have to talk to the microservices directly, for a number of reasons:
It is absolutely crucial that your clients and the microservices remain independently deployable, maintainable, scalable etc.
Of course, for different kinds of clients you could have different gateways like, famously, Netflix does.
The API gateway itself can and should handle limited business logic like combining responses from multiple services and returning them to the user or even authorization.
This might be a good place to start.
Very interesting!
Although I didn't classify what @djviolin wrote as a microservice but I might be wrong :-) I don't know if now "API server" as become a synonym for microservice.
Thanks for the link, I'll check it out!
Gateway wise I always wanted to check out Kong but I still haven't found a project to use it for.
In the last few days I checked some API gateways and dumped it down to these solutions:
getkong.org
tyk.io
krakend.io
traefik.io
Traefik seems a nice little project, but doesn't feature any authorization service and the biggest minus is cannot be extended with plugins (to have some kind of auth), but there is a PR request regarding this, based on Go's newest Plugin library: github.com/containous/traefik/issu...
Kong, Tyk, and KrakenD seems nice projects, they are also extensible with plugins.
Looks like these projects also managing load balancing and rate limiting, so using HAProxy is obsolute?
Largely subjective. You might even try developing your own gateway, nothing wrong with that.
I'd prefer using load-balancing, rate-limiting features if they ship with the gateway. Though consider caching as well.
Else, an Nginx/HAProxy instance could be placed in front of multiple instances of the gateway. Best of luck!