What are some best practices when implementing an API gateway for lagom microservices? I am sure there must be some opinions by the framework?
Should we use something like Kong? or implement one of our own in Lagom or Play? Which one would be better?
Could you please point out some example project that implement API gateway in play framework or lagom, had a hard time finding one?
Please suggest. TIA.
I certainly wouldn’t try to write an API gateway from scratch. It’s really a separate piece of your architecture that is completely separate from your actual microservices. The fact that you are using Lagom should be completely transparent to the API gateway (and vice versa).
Choose a solution that fits your needs and budget. Kong is certainly one reasonable choice, but there are lots out there.
To add to @davidogren answer.
You can also use Play for your itnernet-facing gateway. There’s a (archived) example where we build a Play-based web app which acts as gateway (though it it not an API Gateway as it doesn’t expose the Lagom API’s to the world).
PS: “API Gateway” is a rather overloaded term so we may be using it with different ideas in mind.
My objective is to authenticate and authorize all my microservices APIs and probably handle logging related to the same and have microservices talk to each other without having to authenticate /authorize each other.
Evidently, this means, I will have to expose an authenticated/authorized version of each API from every service on the gateway and every time new API come up in any service. Correct me if I am wrong. I believe this is what @davidogren meant when he suggested to not try and write an API gateway from scratch!
As per my requirements, would it make sense to built something like that in play or lagom? Or Use an already existing solution, like Kong? Could you suggest alternative open source solutions?
I am asking this question again by elaborating on my use case just for clarity of my mind. Please suggest. Thanks.
This is already a kind of an abstract “opinion” question so I sort of want to let it drop. But, my personal opinion is that, yes, you might want to look into an API gateway. But it does depend the complexity of your requirements for auth/auth. Because, yes, one of the advantages of an API gateway is to centralize auth/auth and abstract it from the services. And if later you think you might need to take advantage of other API gateway features (reporting, logging, abstraction, versioning/migrating, rate limiting, billing, etc.) then you have it in place.
Ingasi is right (of course) that if your needs are simple enough than you could write one. Ignasi showed his example, I think there is another example in Kevin Webber’s “Full Stack Reactive” example: https://www.lightbend.com/blog/full-stack-reactive-in-practice-webinar . But it already seems like you would benefit from off the shelf auth/auth behavior and auth/auth behavior is something that I always try avoid writing from scratch.
I don’t claim to be an expert on the API gateway space. But the two I know off the top of my head that are primarily open source are Kong and Tyk. (I think both Mulesoft and Smartbear have some parts that are open source, but I don’t think their API gateway parts are.) But if you are saying “open source” just because you don’t have a lot of money to spend you might want to look at the cloud vendors too. Because Kong and Tyk both have commercial components to them as well.
One more thing I’d add though, is that you mention microservices “talk to each other”. Avoid having microservices call each other via sync methods like REST/gRPC. That leads to lots of complexity and performance problems. Follow the Lagom pattern of having microservices communicate to each other asynchronously via events (e.g. Kafka).
David