Checking out the new Google Cloud Endpoints
Almost two months ago the Google Cloud team released a new version of Cloud Endpoints, a set of tools that let you build and manage your RESTful API. As a self proclaimed “heavy user” of the first version and a believer in this approach I’d like to share some thoughts after trying out this new release.
Even though it is a great project and many of us saw the value and potential on it, there were some concerns from developers about its future. Those concerns were mainly driven by the lack of visible major updates and as with a few Google projects in the past, we feared it‘d eventually end up in the graveyard or becoming obsolete (just see the comments in the custom domains issue). Keep in mind that the first public release was on late 2013 and, in technology industry times, we all know it’s too long to leave a project basically running on its own especially in this highly dynamic field of API tooling.
But fortunately that was not the case, in fact, this new release brings many changes (including support for custom domains). The most notable one is that Cloud Endpoints was split into three pieces: the Extensible Service Proxy (ESP), the Service Management and Control and the Framework. If I’d have to select two words for this release I’d choose: openness and interoperability.
The first release ran only on Google App Engine (GAE) standard, that way we were forced to have all the great benefits of the platform, like automatic scalability, powerful high level APIs, easy and fast deployment among other nice things. However, not everyone is a fan of GAE or even being a fan, sometimes is not the right tool for the job. So this separation of proxy and framework decoupled Cloud Endpoints from GAE standard and made it available to other GCP compute offerings like GAE flexible, Google Compute Engine (GCE), Google Kontainer Engine (GKE).
Authentication was definitely one of the biggest pains points with the previous version, it basically left the developer abandoned if he had to support a different authentication provider aside from Google, or even a different mechanism like, the still pervasive, username and password. But now, you configure the authentication in the ESP and it validates the JWT token contained in the header for you. Not only the way it’s integrated with Firebase Auth is great but most notably the fact that it also supports Auth0 which means many more features and a large community around it. Now basically you can choose to delegate all the authentication stuff and expect the user already authenticated in your code, no more OAuth dances in your app. There is also now a the ability to manage API keys to control access at the app level and by using the console you can now determine which apps are using the API.
But in my opinion, the most important change that comes in this new version is the addition of support for the Open API spec (formerly known as Swagger). Even though the Google Discovery spec is technically robust enough, Google’s own APIs use it and will continue to do so, Swagger became the de facto and now official standard and has been widely adopted by the rest of the industry. That means there is now a huge ecosystem of tools and support by the community but at the same time by using Cloud Endpoints your own API works and feels the same as using any other Google API.
Not everything had changed, they kept one of the best pieces from the previous version: the Python and Java frameworks. They got some updates updates like reduced request latency but it mostly remains backwards compatible with the previous version, that means even the Proto Datastore library will work!
There are still some missing highly requested features, but some of them are apparently being addressed for a later release. This is my wish list, based on my own uses cases but also after having some conversations with other users of the project.
- gRPC support (that would be huge!) having the option of using a more lightweight, efficient and robust way to serialize and transport data hiding the complexity of the implementation by proving the same set tools for both will be a unique value add.
- Cloud Functions support (that would be huge, too!). Imagine not even having to deploy a full blown application but a single block of code with a function to implement your endpoint.
- An official Go (even PHP, maybe?) Framework. There are some unofficial GitHub projects but having documentation, code samples and, more importantly, the support will definitely help push the adoption.
- Improvements to the GAPI JS client and some popular framework integrations e.g Angular and ReactJS. I know that there are community projects like angular-google-gapi but it would be awesome to have a more native and flexible approach, say like AngularFire.
- The API Explorer was one of my favorite tools to debug and test my API as well as any other Google API, however it now feels kind of old and I’m pretty sure it could be more friendly and useful. Yes, I know there is the option for using Swagger UI but that’s not as compelling either.
- To have the ability to deploy and run all the Cloud Endpoints pieces outside of Google Cloud either on premises or on other clouds. In fact it would be super interesting to see Cloud Endpoints as a fully open source project. Following the GIFEE spirit like Kubernetes, gRPC and Beam.
We have to admit that AWS was here first and it provides some of these features with things API Gateway and Lambda but if Google makes the right moves it can provide an even more comprehensive and powerful solution in the end.
References
Here are some references to learn more
