Previously the Firebase Admin SDK would not run on App Engine with automatic scaling. Probably it will create some threads and the Thread class or something like that is not whitelisted.
Now that Google has given us support for Java 8 on App Engine (and removed the whitelist), would this problem be gone? Will the Firebase Admin SDK work on App Engine with automatic scaling?
Firebase Admin SDK still won't work in the AppEngine Java 8 runtime without manual scaling, for several reasons:
The threads support available in the Java 8 runtime comes with some limitations. For instance, any thread not created using the AppEngine's ThreadManager interface cannot call AppEngine APIs. This means these threads cannot make outgoing network calls.
The database client code in the SDK spawns long-running threads. The only way to do that in the AppEngine environment is via background thread support. The SDK specifically looks for this feature when deployed in AppEngine. I've tried to run the SDK with this requirement relaxed, but it doesn't work. It seems request-scoped threads cannot outlive the request even in the new Java 8 runtime.
However, you should be able to use the FirebaseAuth interface (used for custom token minting, ID token verification and user management) in the AppEngine, without manual scaling. This part of the SDK supports running on request-scoped threads.
Related
I can't find any documentation on how gcp scheduler works under the hood. An App Engine is needed in the project, so I assume that the Http calls or Pub/Sub messages are started from the App Engine.
Currently I can use a cloud scheduler even without an App Engine in the project. Apparently a compute engine that also contains a permanently running VM is also sufficient. Could someone confirm my assumptions please or does anyone have sources on this?
I can't tell you how work Cloud Scheduler under the hood. I can just tell you that works well!
I'm sure there is a VM, or a cluster of VM, on Google serverless environment, and your Cloud Scheduler job is set on it. It's serverless, the under the hood doesn't matter, it works, and it's what I want!
Now, the relation with App Engine can be confusing. In fact, there is no longer relation between the product now, but you need the App Engine API activated on your project to use Cloud Scheduler. This strange things is normal if you have been using Google Cloud for a while. At the beginning, only App Engine existed, and Datastore, Cloud Task, Cloud Scheduler was all "modules" of App Engine. Years, after years, google has refactored and extracted these modules to create independent products, as you can see them today. However, some relations are still present, like the API activation.
I'm trying to run a simple Ktor server on Google App Engine Standard. If I run their sample code on github it works well, but fails as soon as I call any App Engine API with the following message:
Can't make API call memcache.Set in a thread that is neither the original request thread nor a thread created by ThreadManager
All App Engine APIs trigger similar error messages. Is this related to how Ktor handles requests, and is there a way to make them work?
I think that the Google Cloud java library doesn't have this threading limitation, but unfortunately I can't use it. I need to access the App Engine Memcache service, which is only available through the App Engine APIs.
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.
Im creating a Node.js website that probably won't have loads of traffic, and was looking into cheap solutions to host the site. Came across Google cloud services offering free usage for their services with limits. A f1-mirco is more than enough for my needs, but I will happily pay for some usage if it goes over by any chance.
I wanted to setup a linux centOS 7 on GCE (which I already did), and run my application and REST API on it. Now here comes the problem.
I tried to use Google's datastore service, but it sprung an app engine instance and without it datastore won't work.
Is datastore entirely relying on app engine to function?? In the docs, it said if you use any of the client API, it requires app engine. What can I do to not use the client api and query data then? Don't want to use the app engine at the moment or datastore is just not for me then?
Thanks for any help!
Some of the underlying infrastructure of Cloud Datastore and App Engine are still tied together for creation, etc. So while creating an Cloud Datastore database also defines an App Engine instance for the project, it doesn't require you to use it. You don't get charged for App Engine either, unless you decide to deploy an App using it.
You should be totally fine use the Google Cloud Node client library on the f1 micro instance.
Usually we deploy BPEL business processes on Apache ODE or WSO2 BPS Server included in Tomcat server, can I deploy a business process on Google App Engine's Web Server? Actually I haven't any idea about that!
There is a lot more to running a BPEL process than it seems. You would not deploy the BPEL process, you would deploy Apache ODE to Google App Engine.
Unfortunately, last I checked App Engine has stringent restrictions on the number of threads a program can spawn, making Apache ODE unusable (see 0(their doc)):
The secured "sandbox" environment isolates your application for service and security. It ensures that apps can only perform actions that do not interfere with the performance and scalability of other apps. For instance, an app cannot spawn threads in some ways, write data to the local file system or make arbitrary network connections. An app also cannot use JNI or other native code. The JVM can execute any Java bytecode that operates within the sandbox restrictions.
you can't. See Google app engine's documentation.
[1] https://developers.google.com/appengine/docs/
[2] https://developers.google.com/search/results?q=BPEL&p=%2Fappengine