GAE’s inherent logging facilities are pretty good and easily brought a couple of bugs in my prototype to my attention. That’s the goodness.
The badness is that GAE’s datastore doesn’t appear to have any sort of inherint journaling or rollback features, so if something gets funky in the data there aren’t any breadcrumbs to follow to get a clue as to how it got that way, nor is there a way to rollback to the last known good state. Even bulk downloading and uploading of data isn’t inherently supported to try to do just a straight off-site backup of a good state and then a restore of that state from the off-site backup. Using a standard hosting a site, at a minimum you could occasionally backup your SQLite file right on the server and just replace it if things got wonky. Obviously SQLite doesn’t scale very far. Other SQL DBs have their scalability limites as well. So it looks likes its either write your data distribution code or write your own journaling and rollback code. GAE’s datastore and API also don’t appear to allow modifications of the existing schema either. If you add a field to an entity in the code when you try to load an existing entity it will fail, so you can really only make additions.
I’ll think I’ll still forge ahead with GAE for my first web browser based strategy game just for the experience, but I’m definitely feeling more motivated to go back and work on the distributed app platform I’ve been wanting to work on.
Josh Heitzman on Codecrafting 