It’s now been about a month since I initially launched my project build on Vaadin, Spring and Google AppEngine. I’m currently trying to create monthly releases where I fix a few bugs and add on some functionality. I’ve also gotten a little more experience with what works and what doesn’t, so here’s a short overview of things to keep in mind when (considering) developing for Google AppEngine. It’s mostly about the Datastore.
The Datastore
Like me, you probably come from a background of relational databases. You’re probably using JPA, most likely with Hibernate. And you might have Spring configured to deal with the transaction handling.
No matter what you might think: Google’s Datastore is completely different.
At first glance, the Google AppEngine’s datastore documents make it look like this is just your normal database. It is not.
If you dive deeper into the documents, you’ll begin to notice the differences, but because you started of optimistic, it’s going to hurt. As soon as you run into a thing called “entity groups” and are creating your indexes, you’ll know what I mean. And trust me, you don’t want to run into entity groups when you think you’re almost done.
I’ve found that Spring’s transaction handling is of little use. If you’re updating multiple entities from different groups inside the same transaction, you’re toast. It might be possible to configure it correctly, but I doubt it and I’ve given up anyway.
I also decided to use JDO because that seems what Google likes. I’m not sure if this was a good decision, because it looks like, but is not quite JPA.
App Engine Versioning
I love the way Google AppEngine does versioning. I don’t think it’s documented anywhere, but it is as easy as it can get. It works very well though. You can deploy a new version and test it on the AppEngine servers and your users won’t know a thing.
If you’re happy, you just flip the switch and you’re done.
One thing to watch out for is (again) the datastore. It is shared between versions. So you need to make sure you can handle old dataformats in the new version. I haven’t really looked into this yet, but I don’t think it’s possible to execute an “upgrade” script. I also don’t know how that would work with older versions that are still running.
Developer Tools
I’ve decided to throw out Spring in the fairly short run and most likely Maven in the longer run. Maintaining their respective configurations is such a pain that I don’t want to bother with them anymore.
I can’t seem to configure Spring’s annotation driven configuration in Eclipse correctly. From time to time it just stops injecting the dependencies for no good reason. The only way out is a complete rebuild of the project, which takes time. And, as mentioned above, I no longer use Spring’s transaction handling.
The only thing I might keep using is Spring security. I haven’t really decided on that one yet.
As far as Maven is concerned, I’m really growing tired of Maven’s xml syntax. But most importantly, none of Google’s tools properly support Maven and it appears this isn’t going to change. I’ve started developing custom GWT widgets and the GWT Eclipse plugin has even more issues with Maven than the AppEngine plugin did.
So, right now it looks like it’s byebye Maven and I might try a “lighter” dependency management approach.
Conclusion
You might get the impression Google App Engine is a lot of work. And it is, but not more than most other application servers. There is one advantage to Google App Engine I haven’t mentioned and it’s a major one. The hosting is pain free. It just works. No need to watch uptimes or fear traffic spikes. No messing around with Apache config files, Linux config files, etc. And it’s free to get started.
I’d love to hear other Google App Engine experiences, that’s why I have comments enabled 🙂