Our public API is deployed in AWS. They are developed with different tech stacks.
We want to introduce rate limiting (based on IP, access key, etc.) for the API across many services in a generic way.
Less or No ops effort to run
Introducing new services and paths to existing services should not require effort on configuring API gateway
We are considering the following.
AWS API Gateway Looks easy. Not sure adding routes require effort to keep it sync with services.
traefik Looks good. But, we need to run and maintain.
What would be the suggested approach for this? Any better tools/suggestions?
API Gateway with Usage Plans enabled, to enable rate limiting via API key, is going to be the recommendation for a solution on AWS. You can also look into doing something like this in order to support rate-limiting by IP (although if I had to do all that for IP rate-limiting I'd probably look hard at third-party products like traefik).
As mentioned in the comments, you can configure catch-all routes in API Gateway so that you don't have to modify the configuration every time you add a new route.
Related
We are trying to transition from one microservice to another implementation. In order to properly test it in production, we are looking into shadowing the request in production to new service, and then comparing the result and logging any discrepancy. I am looking for the best tool than can do it out of the box. Previously we managed to do it with nginx, but I prefer an out of the box solution like Google cloud endpoints, or Apigee.
I'm build a apache cordova mobile app that consumes a specific google api.
What i'm planning to do is consume google apis directly from the app.
Is there any benefit to create a proxy service that consumes google apis and have my app consuming the proxy api ?
I ask because it seems a common practice, but i don't see any benefit.
Is it a best practice or a bad practice ?
If yes maybe a legacy system, maybe yes to do transforms, but now in days, so many "more modern" RESTful API providers have pretty nice client libs. Seems like one more link in the system to fail if I was proxy, and extra load to deal with... (I wouldn't proxy requests to youtube or some storage account for large static assets).
I do find it nice to proxy my own APIs if it's not public. It usually helps to remove the whole CORS mess and eliminate any performance penalties from extra preflight requests, but most public APIs don't have heavy CORS issues since they are, well public and don't have limited allowed origin.
Even simple JS libs hosted on CDNs like JQuery, I usually leverage 3rd party CDNs if available rather than bundle and host on my own CDN through Azure or Google that I have to pay for.
We're building:
A bunch of services exposed through a web API.
A mobile app and a browser app.
Is it common practice for the apps to respond to their own conduit servers that end up talking to the API services? We're going to be setting up a reverse proxy - is it enough to directly hit our APIs (instead of setting up a conduit)? This is definitely a general architecture question.
I'm not sure what you mean by a "conduit", but a lot depends on how complete and hardened your APIs are. Do they already handle things like authentication, abuse detection/control, SSL, versioning, etc...
There are companies that specialize in providing this "middleware" of APIs (Apigee, Amazon API Gateway, Azure API Management, and many others). Your reverse proxy is a start, and is probably good enough to get going with (at least you do things like terminate your SSL, and lock down your API servers behind a firewall). If you make your API services stateless, you will probably be able to add new layers at a later date without too much pain and complexity.
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)
Our team currently operates 4-5 applications, and all of those applications use various 3rd party services (SimpleGeo, FB graph API, Yelp API, StrikeIron, etc). There is large overlap between applications, and frequently we call the same APIs for the same input parameters multiple times. Obviously that is not ideal: it is slow and it is expensive (some of the APIs are not free).
What are the best practices for caching these API calls across multiple applications? I see several options:
Write a custom app that creates facade for all of those APIs, and change all of my apps to use it.
Configure some sort of HTTP proxy in a very aggressive caching mode, and perform connections to APIs via that proxy.
Are there any other options I am missing?
Is there anything wrong with option 2? What HTTP proxy would you recommend for it (Squid, Varnish, Nginx, etc)?
You can use any of the three, but I would go with squid. Squid was created (and is heavily used) for this purpose (as a caching proxy). Varnish is designed as a Reverse Proxy (a cache in front of your own back-end), and nginx more like a load balancer and web processor (serving files and dynamic pages).