TomPallister
commented
6 years ago Hi @darting are you aware of the docs here I think they pretty much sum up how to use Ocelot. Obviously they could be better but I only have so much spare time.
In terms of best practice it's more about should you be using an API gateway? Do you have the problem that an API gateway solves? Which for me is I have a bunch of services (not uniform in terms of how to call them, data structures you get back e.g. xml / json) you want to expose to the internet under one umbrella that handles cross cutting concerns such as authentication, rate limiting. Another use case might be back end for a front end which is a nice abstraction for clients.
If the answer to that question is yes then I would say go ahead and try an API gateway! I would then suggest looking at what is available e.g. Kong, Tyk, AWS, Azure API Management etc and see if any of these can work for you. If I wanted to use something written in .NET and own the project / deployment then I would look at Ocelot. I would then expose one of my APIs via Ocelot and see if it works OK in my application, measure performance, make sure Ocelot isn't adding much overhead (it's ~2ms at the moment, i think netcore2.1 will make this even less). If all is working well I would start exposing more more endpoints via Ocelot.
How you host Ocelot completely depends on your existing infrastructure. For me you want to get Ocelot as close to your clients as possible so latency is small and then hope that you have a really low latency connection to your downstream services.
I would suggest you at least want 2 Ocelot instances running in case one goes down. You could have them in an active / active configuration in front of a load balancer. You might even want to put something like nginx in front of Ocelot depending on if you think the kestrel web server is up to scratch (I think it's probably fine to expose).
If I was building a project from scratch I would probably have my services deployed in Kubernetes with Consul. I would then use Ocelot to lookup the service addresses in Consul (deployed as sidecar). Ocelot would be exposed to the internet and I think this works quite nicely.
The last thing I would say is do you want your Ocelot configuration to be a monolith, e.g it has a lot of ReRoute configuration in it. I would suggest you probably don't and might want to either merge the configurations into one (Ocelot can do this) or you could deploy multiple instances of Ocelot with different configurations (this is what Microsoft intend to do) and then have nginx or something in front of them to do basic routing to Ocelot. This way you can retain having an exposed domain such as api.example.com to your clients.
Anyway I hope that helps...but I'm not really sure what the best practices should be 😃
Hi @TomPallister, is it able to write some documents for the best practice for this project? To guide peoples when they want to use on production.
Thanks for your amazing works.