Will requests to Cloud Endpoints get cached?
The official docs are a little light on this matter. The docs read:
Cloud Endpoints uses the distributed Extensible Service Proxy to
provide low latency and high performance for serving even the most
demanding APIs. [...] and can be used with Google App Engine, Google
Container Engine, Google Compute Engine or Kubernetes.
A 'distributed extensible service proxy' makes me think the Endpoint is distributed to the edge nodes for faster responses, but the docs don't specifically state this.
We can use Cloud CDN to cache requests from GAE, Compute and Container Engine. Endpoints can be used with all those. This makes me wonder if there's some magic in the background with CDN+compute to cache the Endpoints responses. Again, the docs are a little light on this.
Has anyone figured this out? Thanks!
Great question! The Extensible Service Proxy (ESP) does not perform request caching. Its function is to intercept incoming requests, validate auth tokens, and then forward the request to Google Service Control where additional API Management rules are applied as defined in your Open API spec. Endpoints uses a distributed proxy model for better performance, to avoid the extra network hop that's typically incurred with a traditional multi-tenant API proxy. This is in fact the same model used internally within Google to power our own APIs.
Please let us know if you have anymore questions!
Related
We have set up a VPC Serverless access connector, and configured app engine to use this in app.yaml. We have egress_setting: all-traffic set, as we want to access a 3rd party API from a specific IP address. We used the documentation from https://cloud.google.com/appengine/docs/standard/python3/outbound-ip-addresses#static-ip.
Part of our testing is hitting a large set of URLs on app engine and checking the HTTP status. In this testing we noticed a dramatic reduction in the rate of serving requests when using the connector. Since all egress traffic is routed via the connector, my first inclination is to think our applications usage of Google APIs (datastore, cloud storage, Cloud SQL) is being impacted.
The connector is still has the minimum number of instances as active instances, indicating we have not reached the limit of it's performance, and that this is not the bottleneck. However, retesting with the vpc_access_connector removed from app.yaml returns performance to what we previously had.
I've tried enabling Private Google Access on the subnet the connector is linked to, but this has not improved the situation.
I think we may need to add some routing rules that allow us to send the traffic for Google APIs directly to Google's services, and not through the cloud NAT, but I'm unsure as to what rules would be applicable. I see no reason why this is not possible, but I haven't found the right documentation to guide me here.
Is this possible? Is this documented somewhere?
My Django app is working on GAE with Cloud SQL（MySQL）.
By using New Relic Monitoring, I tracked requests done by my app to www.googleapis.com.
I don't know those requests. Can somebody explain this behavior?
(app connecting with cloud proxy)
As merely described here, there are various processes running in the instance along side (with?) your application... scaling, billing, logging, etc. Communication with other Google Cloud Services (like the ones I previously mentioned) is mainly done through Google Cloud APIs. Since App Engine is a managed Platform as a Service, this management needs to be done somehow... a myriad of REST API requests and responses do this. Partly through the www.googleapis.com endpoint.
You don't have to worry, though... your application's performance is not affected by this, nor your billing account.
I have previously used
#app.route('/mypage/<int:myvariable>/')
to create rules for what should happen when users land on different urls on my website. I have done this on local machines that have been running on my own virtual servers.
Now I am learning to publish my first web app to Google App Engine. I have heard that I should be using Google Cloud Endpoints instead of the route decorator.
#endpoints...
I've read a few articles about endpoints and some of the benefits of endpoints that they list are:
Endpoints makes it easier to create a web backend for web clients and mobile clients
Endpoints free you from having to write wrappers to handle communication with App Engine
Even if I have read this I can't wrap my head around what this means. I don't understand it. Can you explain in non-technical terms with examples what the advantages of using #endpoints is compared to alternatives? The alternative that I am familiar with is #app.route.
Google Cloud Endpoints can be thought of as a subset of #app.route. They are intended to solve the API backend problem for mobile and javascript clients. They are not intended to serve web pages and other hypermedia. You can use the normal routing methods of your framework of choice to create a web service for your application but Google Cloud Endpoints takes care of a lot of boilerplate for you.
There are a lot of limitations with Google Cloud Endpointsso be sure to familiarize yourself with them before committing. For one, you cannot host Google Cloud Endpoints on a custom domain name. They are only accessible via <app_id>.appspot.com/_ah/api/*
Endpoints makes it easier to create a web backend for web clients and
mobile clients
What this means is that you can create one backend and then iOS, Android and Web-apps (via Javascript for example), can execute your API methods with specific client generated libraries.
This is convenient if you are building a backend that you want to be easily accessed via smartphones or through a web browser.
Endpoints free you from having to write wrappers to handle
communication with App Engine
With Endpoints you can generate client libraries (e.g. Android, iOS, Javascript) that you can then execute your API methods. You don't have to worry about writing a bunch of additional code to do that.
My Opinion:
I have never used Cloud Endpoints to make a web-app but it is very convenient if you are making a mobile app for iOS and Android because you can access your backend with both platforms.
One reason you might want to use Cloud Endpoints for a web-app instead of something else is because of Datastore. Datastore is the way Cloud Endpoints stores data. It is a NoSQL storage method which is kinda tricky to wrap your head around at first if you come from a relational database background, but once you get it, it makes a lot of sense.
We are currently hosted on Amazon's AWS platform, however our server makes extensive use of many of the Google services API's including:
Google Maps
Google Static Maps
Google Places
During normal usage, some of these API requests can take over 1-3 seconds and that's not exactly great for user experience. I wonder if there are any performance gains if we were to host our server on top of Google App Engine instead. An example would be getting better performance if you make use of as many AWS platforms for your system rather than spreading them out between multiple cloud services provider.
Yes the roundtrip to call the api will be faster but not the actual api. It can make a noticeable difference if you are calling many google apis on the same servlet call.
I've been investigating what I can do with Google's Secure Data Connector and App Engine.
Is it possible, from an App Engine application, to grab resources inside my corporate intranet without using HTTP(S)?
From what I read in the documentation, the only way to request resources through SDC is by using url_fetch, which is limited to HTTP, right?
You are right that app engine does not let you to other hosts or use sockets directly except through its URLFetch API which is limited to HTTP. However, you are not stuck to traditional ports - you can use it to access ports 80-90, 440-450, and 1024-65535 (as of GAE v1.3.2).
It doesn't seem like this restriction should matter much if you are planning on using SDC - the SDC FAQ seems to indicate that it uses HTTP/HTTPS to connect to resources on your intranet anyway.