4 ms·
I used App Engine for over a year on different projects and ended up leaving it. My first reaction to TyphoonAE was 'cool', because it's exactly the sort of thi
by mbenjaminsmith 16y ago
I used App Engine for over a year on different projects and ended up leaving it. My first reaction to TyphoonAE was 'cool', because it's exactly the sort of thing I wanted to see back in those days so I could get over the sense of lock-in. If I knew there was an easy way out I wouldn't have to think about it.
But if you consider what this project actually means... if it's about providing a way out while maintaining compatibility then all it really does is give people a reason to stay on App Engine. Are the developers cool with that? Or is this an intermediate system that allows you to migrate an active project away and then expand it beyond AE's limitations?
If you're ok with the limitations inherent in AE then it makes sense to stay there given the fairly high level of reliability and very low cost. If you need to move beyond AE's limitations then you should just port your app to another platform. Given the amount of Java/Python frameworks out there it's not really a big deal to find a better platform without having to start completely from scratch.
Another issue is that it's not just finding a compatible db but being able to get your data moved while maintaining the current key/id/parent/etc relationships. If you're like me, you probably used id/key lookups extensively because they're faster.
I'm curious how they'll address the actual migration issues beyond api/module compatibility.
- util 16y agoCould you talk about some of the limitations that led you away from AppEngine?
- mbenjaminsmith 16y agoI'm working on an app now that uses PIL to create some fairly complex composite graphics with serial numbers printed on them. Can't do that on App Engine. Their version of PIL is buggy. I had to use composite() to do crop() in order to get rid of black lines on the edges of images (seemingly random, couldn't get repeatable results). The datastore is slow and requires a lot of planning to do even basic stuff. You also have to manually memcache everything to speed things up. Hard 10 second limit on db queries and a 30 second limit on requests. There's a famous bug that kills db queries randomly. I'm not sure they ever fixed it but there's a monkey patch floating around that keeps trying until the time limit is reached. Deploys timeout constantly. A one click deploy isn't that attractive if it takes over a minute to complete. Mail handling is terrible and only got introduced (inbound) after I had been using it for a long time. When I say terrible I mean buggy and unpatched. You have to write your own attachment handling to work around it. If you don't have a heavily trafficked app, your app 'goes to sleep' often (gets unloaded from memory). There's a pretty long wait when it fires up again. When they (or you) do have a problem, there's really no connection to support. There's a group but you have to wait for a response. There are a lot more but I can't remember all of them at the moment. I've since just moved to a vanilla Django deploy. I would never go back.
- util 16y ago:-( Sorry to hear about all this. I'm still tempted to use it but will be more prepared to be disappointed.