We are trying to understand the primary differences between Apigee vs. Google API Gateway (API Gateway documentation | API Gateway Documentation | Google Cloud). Besides the pricing, are there any technical limitations that will make either product superior to the other?
Any detailed documentation with technical limitations is appreciated.
Thanks
From the product page for API Gateway,
With API Gateway, you can create, secure, and monitor APIs for Google Cloud serverless back ends, including Cloud Functions, Cloud Run, and App Engine.
So, think of it as a pretty thin API Gateway for things that are specifically hosted in Google cloud serverless things. (This excludes services running in GKE and GCE. )
Apigee, on the other hand, includes a gateway, but also includes a developer portal, monitoring, advanced API ops, and other extension possibilities. The gateway itself is more capable, with ~40 built-in policies. Apigee can connect to arbitrary backends, including but not limited to upstreams hosted in Google cloud.
Thank you for the info @Dino-at-Google , but is there any documentation that can highlight the differences between these two products (Ex: Apigee supports openapi 3.0 spec, but API Gateway probably is limited to swagger 2.0)
With Google’s wide offerings around API, there is no clear definition of which product can do what.
I’ve asked the product team to respond here.
Thanks @Dino-at-Google will look forward for an update from product team
@dchiesa1 Can we please get an update on this ?
Ack.
@dchiesa1 any luck with this, please ?
Any updates to this? 
Thanks!
Any updates?
We’re also super interested in an update here.
Does API gateway support Oauth2 scopes? From my experimentation it doesn’t seem to.
Any update here ?
And how it might compare to Cloud Endpoints? Three products with a fair amount of overlap from what I can determine. I’m a cloud architect, not a programmer, so I’m trying to figure out when to use each. Any help from the product team would be really helpful.
It’s really disappointing that it’s been a year since many people asked for a detailed comparison between these services and no one provided any answer yet.
Do you really care about your customers and their needs?
I’m not from the product team or from Google, but I’d like to give my two cents here
Cloud Endpoints are better for use cases within Google Cloud Platform (ex, APIs for Compute Engine, Cloud Functions, GKE, etc.) and are meant to be highly extensible and flexible for customers. It is not a fully managed solution, so the lifecycle management is up to the customer.
Google API Gateway is a fully managed API gateway, again to be used from within GCP, to connect with GCP services like the ones mentioned under Cloud Endpoints. It reduces the lifecycle management requirement here, which is done by Google.
Both of these are more aligned to be used with GCP services and need a service proxy to connect with external services.
APIGEE is more of a fully featured product that can be used for any type of systems, within or outside GCP and can also be integrated with legacy systems. It is fully managed and supported with developer portals, management systems and the likes.
An article was posted to Google’s blog on 11/18 that might help here.
Google - posting articles like the one referenced by steve174 above is a complete waste of time. It doesn’t answer anything. Clearly written by your marketing team intended for… who knows, but definitely not us engineers.
Some examples:
Oh there’s a lot more I can remark on but hopefully the message is clear. No, it’s not to respond to my 2 remarks above, it’s for you to go away and reflect. Next time, get your engineers to write the comparison article and put in actual pragmatic differences, and not a marketing dump - you’re not selling it and we’re not buying it.
Better yet, in the future, maybe go with a single service and add capabilities to it, leaving it to the consumer to pick and choose how simple or complex they wanna make it, as opposed to a bunch of completely separate services, each seemingly doing the same thing.
We’re in the process of shifting all our AWS infra to a new provider, and GCP is among the potential candidates. I won’t be holding this particular issue against you, but I can’t say the same for the next engineer.
Thanks for the feedback! I appreciate your perspective.
regarding “API use is exploding everywhere” … I’m with you… sometimes the blog posts get a little too much input from the marketing team.
And I get your point that you’d like to have a more concrete comparison of Apigee vs API Gateway.
The big difference is that Apigee is a full featured API Management platform - with Monitoring + Alerting, a developer portal, a gateway with a policy engine with 50+ policy types, Support for multiple deployment options (hybrid, X), Productization and Monetization, Advanced Security (AI-powered bot detection and mediation), support for multiple different security protocols, data mediation… All of that adds up to what we call “Platform”. API Gateway is a simple gateway. If you want that other stuff, you have to build it. Apigee supports OAuth, SAML, WS-Security, API Keys, … API Gateway supports API Keys or JWT-based auth, that’s it. Apigee supports XML to JSON conversions and other data conversions; API Gateway doesn’t. etc etc etc.
That’s the key distinction. Platform vs Gateway.
If you are looking for exact comparisons of performance, we haven’t done them. I don’t know the maximum throughput you can expect for API Gateway; we haven’t thoroughly benchmarked it as far as I know, and I believe you’re correct that Google doesn’t publish numbers (which we don’t have anyway).
In my experience, throughput of the gateway is not a differentiator between Apigee and Google API Gateway. It’s the platform stuff.
If you have a single endpoint, or a handful of endpoints, running in Cloud Run, or Cloud Functions, and you’d like to inject some standard Authentication and rate limiting in front of them, API Gateway is a great choice. It’s simple, easy, and it works well. If you have a very large number of endpoints, lots of disparate data sources, different teams publishing APIs, a mix of off-the-shelf APIs and custom APIs, APIs that run in other clouds, if you want to productize or monetize your APIs, … Then Apigee is the much better choice.
I hope this is helpful. Again thanks for the feedback.
@dchiesa1 Thank you for the comparison, it’s certainly much more useful, and provides better insight into the technical differences between the two services.
The only features we want from a gateway are:
We don’t need things like monitoring, monetisation, external APIs, multiple auth protocols, and other platform-specific stuff. The preference would definitely be a lightweight service like API Gateway, but it needs to offer all the features we require. That’s one reason why I had suggested a single service that lets the user start simple but can be scaled up to be as complex as needed depending on requirements. Apigee appears to be a service that already starts off complex with all its features needing configuration, even if they are unused.
Of course, I don’t know for sure as I have been unable to find GCP documentation to help with this decision.
Further to my previous reply…
Upon further investigation into requirement #1 (custom authoriser), it appears that API Gateway only supports authentication and not authorisation; bizarre, as that’s one of the main reasons to have a gateway (to separate concerns and not have your APIs worry about any auth).
Couple sites that appear to confirm this (neither one Google docos unfortunately):
https://stackoverflow.com/a/63766347
https://community.auth0.com/t/how-do-i-handle-scope-based-authorization-with-google-api-gateway/85985
As per RFC7662, our custom authoriser uses a standard OAuth 2 token introspection endpoint and returns a list of allowed scopes. Our existing AWS API Gateway setup consists of each endpoint defining a list of required scopes and an (integrated Lambda) authoriser which calls our introspection endpoint to compare the list of allowed scopes returned from it to that of the required scopes for the API endpoint being requested.
This is prettttty standard OAuth stuff, so really surprised that GCP API Gateway doesn’t provide a way to support this behaviour out of the box (or does it?). I’d be even more surprised if Apigee (with all its platform fluff) doesn’t support this either.