Designing to easily switch to the Google App Engine

Question

In the near future I will start creating a web application, and although I have extensive experience working with it in the SQL world, I have no idea what I need to take into account for this in order to switch to GAE in the near future.

Alternatively, I could develop an application for GAE from the very beginning, and so in this case, what are the differences that I need to take into account? In other words, what DOS and DONT to write your GAE application coming from relational databases.

Answer 1

Just out of my head:

• This is really ONLY a key-> value store, don't be fooled by things like GQL (it's just a subset of SQL SELECT)
• No JOINs - often you have to denormalize or forget
• More or less frequent timeouts
• (Very) slow access compared to the local SQL database.
• COUNT is very expensive
• OFFSET (in SELECT) implemented on the client side - so you retrieve all records before the bias - as Nick Johnson pointed out in one of the comments, this is not the client side, so now, since LIMIT 1000 is gone, it looks like SQL databases.
• (recently deleted) LIMIT of 1000 rows fetched
• SELECT performance drops dramatically as the number of rows returned
• Migrations are hard to do because you have to do them using regular HTTP requests and every request is destroyed after 30 seconds. You must resort to task queues that process strings in packages
• There are pseudo-foreign keys - ReferenceProperties in the Python API - but they don't apply in any way - if someone / something deletes the target, then you have what is known as a dangling pointer in C ++
• The fields that you use for queries must be indexed, but when using a key (the type of primary key for each row / instance), your queries are faster
• Building indexes on a live instance can take a lot of time (and you cannot reduce it), and without them your application often cannot work. Beer and patience are recommended.
• A lot of artificial restrictions (for example, the maximum limit of 1000 already lifted). For example. The GQL 'IN' statement is just syntactic sugar for several ORs, and there is an upper limit of 30 values.

All this means that you probably can’t avoid affecting the user with an inconsistent state, and almost certainly you can’t avoid the inconsistent state of your data (for example, half of the lines migrated and half didn’t, during manual changes to JOIN data, etc. .)