App Engine's Python 2.7 runtime had a very convenient way of asserting the identity of an application to another App Engine application.
As described in the above link, using the app_identity library of the google.appengine.api package I was able to obtain and insert the auth_token into the urlfetch headers. When receiving requests I could verify the X-Appengine-Inbound-Appid header info.
I understand urlfetch and the google.appengine.api package are not available in the Python 3.7 runtime.
My app consists of several GAE projects, so I used this method to verify the identity of api calls between my projects (i.e so I do not need it for external APIs / services). What would be the recommended approach of doing this in App Engine's Python 3.7 runtime?
Related
I am using Google Cloud Storage and I want to serve scaled images from it, Python 2 version of Google App Engine supported it via Images API but with Python3, they removed that API.
https://cloud.google.com/appengine/docs/standard/python3/python-differences
Cannot understand the intension behind removing such an import feature, upgrading to Python3 in Google Cloud environment sounds like a downgrade to me.
As you said, the proprietary App Engine APIs are not available in Python3.7. The main reason is because GCP is unbundling App Engine and now, you are no longer dependent on these APIs.
Currently, there are some third parties alternative solutions. In your specific case, and based on GCP documentation, I think that you can try to use Imgix or Rethumb.
Seems like Google is planning on adding it back to Python 3:
https://cloud.google.com/appengine/docs/standard/python3/services/access
To reduce runtime migration complexity, Google Cloud now supports a set of App Engine bundled services and their associated APIs on second-generation runtimes, which include Python 3, Java 11, and Go 1.12 or higher. Your app can call bundled services APIs for second-generation runtimes through language-idiomatic libraries.
When writing a Go App Engine Standard app, it used to be the case that you had to use the App Engine SDK to access the data store. However, these days (since Go 1.11?), it seems to work if you just use the Cloud Datastore Client Library.
Is there a downside of using the Cloud Datastore Client Library on App Engine Standard for accessing the datastore? (apart from a bit of extra configuration to make the dev appserver use the emulator). The advantage is that it enables code reuse for other environments.
App Engine Standard for Go1.11 runs on the new, second generation (beta) runtime which doesn't have the limitations of the 1st generation and is capable of running any framework, library, or binary. On the other hand, App Engine no longer modifies the Go toolchain to include the appengine package and it is strongly recommended to use the Google Cloud client library or third party libraries instead of the App Engine-specific APIs.
For more details about this, I recommend to have a look at the doc here about the differences between both generations and how to handle them.
Newbie to Datastore. I found two tutorials on the GCP site to use Datastore on App Engine. Which one should I use?
There are subtle differences in how the APIs work.
https://cloud.google.com/datastore/docs/datastore-api-tutorial
uses package (import com.google.appengine.api.datastore.Entity;)
vs.
https://cloud.google.com/appengine/docs/standard/java/building-app/cloud-datastore
uses package (import com.google.cloud.datastore.Entity)
Question: Is there a preferred package to use and call the datastore API while on App Engine - com.google.cloud.datastore.Entity vs. com.google.appengine.api.datastore.Entity?
The library with this package com.google.appengine.api.datastore (aka "Datastore API for Java") is intended for use by Java 7 and Java 8 applications which run on AppEngine.
The library with this package com.google.cloud.datastore (aka "Cloud Datastore client library") is intended for use by any Java 8 application regardless of where it is deployed (GKE, GCE, on-premises etc)
From the docs:
Datastore API for Java is a low-level Datastore API built into the App Engine SDK to provide direct access to all Datastore features and is described throughout the App Engine Datastore documentation for Java.
Cloud Datastore client library is a library that can be used by apps in the App Engine standard Java 8 runtime, by applications in the App Engine flexible environment, and by non App Engine applications as well.
So, according to Google, both are valid choices subject to these limitations ...
If you are running Java 7 then you cannot use Cloud Datastore client library
If your application is not deployed to AppEngine then you cannot use Datastore API for Java
These limitations describe the scenarios in which one or other of these libraries cannot be used. Google offers no advice on which one should be used. This is because the two libraries are functionally equivalent so, assuming that the limitations described above do not apply to your usage, the choice is probably moot.
Related questions:
How to do authentication check in Python library from Google Cloud Endpoints on GAE standard
How to check service-to-service authentication in Google Cloud Endpoints?
I have an App Engine Standard (Python) environment (using webapp2) that will be making calls to a Cloud Endpoint (no user authentication required, but the calls must be service-to-service secured) and I would like some clarification on how to do this using the Cloud Endpoint Framework for App Engine Standard.
If I go about the method described in (2) above, does this mean I would have to manual edit the openapi.json file that is generated from lib/endpoints/endpointscfg.py get_openapi_spect with the security definitions? The documentation seemed geared more towards GCE and App Engine Flex environments that are using the Cloud Endpoints for OpenApi so it was confusing whether I had to edit my #endpoints.api configurations.
Or, given that I am making a call from App Engine Standard environment, would I just be able to use urlfetch and AppIdentity: https://cloud.google.com/appengine/docs/standard/python/appidentity/ and assert identity to the endpoint? If so, what would the configurations look like?
ndb: (from google.appengine.ext import ndb)
datastore: (from gcloud import datastore)
What's the difference? I've seen both of them used, and hints they both save data to google datastore. Why are there two different implementations?
The Python NDB Client is specific to Python Applications running on Google App Engine. The datastore client removes that restriction and you can run your Python application anywhere, including Google App Engine, Google Compute Engine or anywhere else.
Exceprt form - https://cloud.google.com/appengine/docs/python/ndb/
The Google Datastore NDB Client Library allows App Engine Python
apps to connect to Cloud Datastore.
In addition, the NDB client has certain features (e.g. caching) while the other does not appeat to support.
The reason for the two implementations is that originally, the Datastore (called App Engine Datastore) was only available from inside App Engine (through a private RPC API). On Python, the only way to access this API was through an ORM-like library (NDB). As you can see on the import, it is part of the App Engine API.
Now Google has made the Datastore available outside of App Engine through a restful API called Cloud Datastore API. gcloud library is a client library that allows access to different rest APIs from Google Cloud, including the Cloud Datastore API.