Is GRPC supported? My gut feelign is no, but I hope I am wrong
Edit: Holy shit this is so bittersweet. I was relying heavily on the batteries included user management, logging, admin only handlers, and especially the super easy cron job definitions.
IDK what to think about this. It kinda takes away all the things that made App Engine worth it for me as a programmer who doesnt want to do dev ops.
AFAIK you can't run a gRPC server on App Engine, but you can access other gRPC services (like all the GCP APIs) as a client. I might be wrong about the server part.
All those things you mentioned in the edit should be supported in the new runtime.
Edit: I see what you mean. The deeply integrated services are removed in favor of more portable solutions, like Logging moving to Stackdriver Logging (though stdout is still logged automatically), Users moving to Firebase Auth, etc. Cron should still work fine though.
Thanks for the reply. Yeah I'm bummed about that because id rather use GRPC client libraries for my apps than the endpoints discovery doc generated ones.
That page mentions that it supports the google-cloud-python libraries, which are the primary GCP gRPC client libraries for Python. The Apiary service-discovery library you are referring to is called google-api. The new GAE version doesn't support the old GAE-only libraries, like memcache, datastore, etc. These older services only worked with GAE, and therefore weren't portable to other services, which they are in the process of replacing. If I recall, the old version didn't support the google-cloud-python libraries either, so it's good to see that they are moving in that direction. I could be wrong about that though.
In short, it looks like you have access to the main GCP gRPC libraries. You don't have access to the GAE-only service libraries.
The Google Cloud client libraries [1] are fully supported. You can use these to access services like Datastore, Spanner, Natural Language, and many other Cloud services. They work on this new runtime, on the flexible environment, on a VM, your local machine, etc. In my opinion, this is the most Pythonic way to integrate Cloud services in your app while maintaining portability.
[1] https://github.com/GoogleCloudPlatform/google-cloud-python -- small caveat, the repo currently states that they're not supported on App Engine standard environment. That will be updated soon to clarify that the Python 3.7 runtime on the standard environment is supported.
We're working on suitable replacements for these services. In some cases, e.g., Cloud Tasks, we're pretty close. Others will take a little longer. We'll share updates as we make more of these services available.
Also I did find that someone wrote a ndb-like wrapper around the cloud datastore API.
https://github.com/Bogdanp/anom-py
I haven't tried it out yet.
Although i think any reasonable path to upgrading to 3.7 might need atleast some wrapper like that around the datastore(even if it's not 100% compatible), otherwise forcing people relying on that to re-write the entire data layer. At this point i might just start re-writing the app, to move to something with less lock-in like Mongodb. But i'd love to hear what other people's plans are for this.
"The ndb ORM library is not available for Python 3. You can access Cloud Datastore through the Cloud Datastore API. You can use the Google Cloud client libraries to store and retrieve data from Cloud Datastore."
What is the access to your hosted postgres like? Do you still have to use that proxy thing? I'm wondering how much effort is require to move a sqlalchemy based app over to this.
If you're an existing AppEngine standard user/customer, it's pretty likely that that means you will not be able to take advantage of PostgreSQL, as the new runtime does NOT give you access to a ton of their existing services that you are probably already using (such as datastore.)
Hi optimusclimb -- just want to make clear that using Cloud SQL to connect to PostgreSQL should work using Python 3.7 on the App Engine standard environment. Your earlier comment accurately pointed out a gap in our docs. We're going to address that -- thank you.
If you try Cloud SQL and find that it doesn't work with PostgreSQL on this new runtime, that's a bug and we need to fix it.
I think what he's saying is you're currently using Python 2.7 on Standard and using existing built-in services like task queue, memcache, ndb, etc then switching to the new Python 3.7 runtime (to be able to connect to Postgres) runtime really isn't possible since there aren't non-rewrite solutions for those missing pieces.
The (datastore) client libraries take up the http request quota and the build-in mechanism of the Standard Environment is not. Google recommends going forward with client libraries everywhere in the documentation but what's the solution on the introduced request limitation which isn't mentioned anywhere? (Or is this finally fixed in the meanwhile?)
We hit that HTTP request limit as well, and (driven by a discussion with Google support) migrated our backend away from the REST-based Google Cloud Datastore API to the internal (ApiProxy-based) Appengine API. Reduced the latency as well. I can send you the internal support ticket nr if interested.
Nice launch! I have some Python code which I've been meaning to convert to App Engine standard to take advantage of the free tier, and I hadn't yet adapted it to the proprietary APIs. Now I don't have to. Thanks!
One Q: Does Google Cloud IAP work with this as an option for user auth? Would one follow the App Engine flexible environment pattern in their docs? The Cloud IAP docs still mention the Users API as the recommended approach for the App Engine standard environment without an exception for the Python 3.7 runtime.
> This new runtime allows you to take advantage of Python's vibrant ecosystem of open-source libraries and frameworks. While the Python 2 runtime only allowed the use of specific versions of whitelisted libraries, Python 3 supports arbitrary third-party libraries, including those that rely on C code and native extensions. Just add Django 2.0, NumPy, scikit-learn or your library of choice to a requirements.txt file. App Engine will install these libraries in the cloud when you deploy your app.
Yes, this runtime supports arbitrary dependencies specified via a `requirements.txt` file. If you find a library that doesn't work, please let us know. In general, anything that works using an open source Python 3.7 distribution should be supported.
Incidentally, the best way to "let us know" about bugs in GCP (App Engine or whatever else) is via the Issue Trackers, as per https://cloud.google.com/support/docs/issue-trackers (disclaimer: making this and similar processes work is my current job at Google).
Edit: Holy shit this is so bittersweet. I was relying heavily on the batteries included user management, logging, admin only handlers, and especially the super easy cron job definitions.
IDK what to think about this. It kinda takes away all the things that made App Engine worth it for me as a programmer who doesnt want to do dev ops.