0
votes

I've started to port a web app backend to Google App Engine for scaling. But I'm completely new to GAE and just reading into the concepts. Steep learning curve.

I'm 95% certain that at some point many millions or at another point at least hundreds of thousands of users will start using the web app through a GUI app that I'm writing. And they will be globals users, so at some point in the future I'm expecting a relatively stable flow of connection requests.

The GAE Standard Environment comes to mind for scaling. But I also want the GUI app to react when user related data changes in the backend. Which suggests web sockets, which aren't supported in the Standard Environment, but in the Flexible Environment.

Here's my idea: The main backend happens in a Standard app, but the GUI listens to update notifications from a Flexible app through web sockets. The Standard app calls the Flexible app after noteworthy data changes have occurred, and the Flexible app notifies the GUI.

But is that even possible? Because sibling Flexible instances aren't aware of each other (or are they?), how can I trigger the persistent connections held by the Flexible instance with an incoming call from the Standard app to send out a notification?

(The same question goes for the case where I have only one Flexible app and no Standard app, because the situation is kind of the same.)

I'm assuming that the Flexible app can access the same datastore that the Standard app can. Didn't look this one up.

Please also comment on whether the Standard app is even a good idea at all in this case and I should just go with Flexible. These are really new concepts to me.

Also: Are there limits to number of persistent connections held by a Flexible app? Or will it simply start another instance if a limit is reached?

Which of the two environments end up cheaper in the long run?

Many thanks.

1

1 Answers

0
votes

You can only have one App engine instance per project however you can have multiple flex services or standard services inside of an instance.

Whether if standard is a good idea it depends up to your arquitecture, I'm pretty sure you've looked at the comparison chart, from experience is that if your app can work okay with all the restrictions (code runtimes, no availability to do background process, no SSH debugging, among others) I will definitely go for standard since it has a very good performance when working with spikes of traffic deploys new services in just seconds, keep in mind that automatic scaling is needed for the best performance result.


There are multiple ways to connect between flex or standard services one would be to just send an HTTP request from one service to another, but some other options with GCP services like Pub/Sub.

In the standard environment, you can also pass requests between services and from services to external endpoints using the URL Fetch API.

Additionally, services in the standard environment that reside within the same GCP project can also use one of the App Engine APIs for the following tasks:

  • Share a single memcache instance.

  • Collaborate by assigning work between services through Task Queues.


Regarding Data Store you can access the same datastore from different services here is a quickstart for flex and the quickstart for standard


Which of the two environments end up cheaper in the long run?

  • Standard pricing is based on instance hours
  • Flexible pricing is based on usage of vCPU, memory, and persistent disks

If your service run very hight performance process on short periods of time probably standard will be chepear, however if you run low performance process on long periods of time, flex will be chepear, but again it depends on each use case.