I have gone through many Google App Engine tutorials, and I became quite familiar with how to do basic stuff like implementing a webapp2.RequestHandler, and using ndb.Models to manage your data.
Now, I kind of reached a wall with a few small concepts that were either missing from the resources I went over, or I simply missed them. So, here they are:
What happens to class variables?
As far as I understood, once I set my app to threadsafe, it can handle multiple requests concurrently, not to mention possibly on different machines. Does that mean I simply cannot use class variables (that can be changed at anytime)?
How to model an application wide logic?
It is very straight forward to write logic associated with requests. I don’t have to worry about locking or any of that stuff, since a new RequestHandler is instantiated for each request. What about application-wide logic? Like, if I had a python module called “Game”, and after importing it, I do somthing like:
Game.matchmaking_queue.append(player)
As far as I can tell, there is just one Game instance, and it has an instance variable accessed from within the RequestHandler logic. Will that be OK? Must I make the matchmaking_queue backed on memcache and/or datastore in order for all requests to see it? Do I have to do any thread-saftey magic on Game?
A few practices that proved useful for me.
- Limit yourself to local and instance variables. (BTW immutable objects have lots of upsides, so you may not even need instance variables.)
- Do not use global and class-level variables, except as constants.
- For global state use a proper database. Datastore and Cloud SQL work ok.
- Use memcache as much as possible. Cache everything you use often. Memcache is cheap and fast. Always checking the cached value first, then retrieving from DB if cache is stale is a bit daunting; factor it out.
- Datastore has good throughput, but significant write latency and throttling, and writes are relatively expensive. Be mindful of this, else you’ll run out of your free quota too fast.
- Datastore is NoSQL; write large chunks of data in one operation if possible.
- Datastore does not like very fast updates of the same value (e.g. having a fast-moving counter). Spread the writes if needed.
- Use queues for asynchronous processes. Generally using threads is not a great idea.
If you happen to know Erlang (or maybe Play framework for Java/Scala), try to think like you’re using these, in terms of messages and queues, not variables. Then GAE suddenly starts to look simple and logical 🙂
1
The GAE can use different processes to handle different requests. Those different processes don’t even need to be on the same machine, or in the same datacenter even. Then again, different requests can be routed to the same process.
This means that any ‘global’ state (module global, including attributes directly on classes) will be shared between requests within one process. See App Caching in the GAE Python documentation.
In other words, you cannot count on there being a shared global state between all your requests, but you should make use of there being a shared global state between some of your requests.
If you need anything shared between all requests, you need to use the datastore.