Google AppEngine in Practice

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 :)

16 thoughts on “Google AppEngine in Practice”

  1. Congrats and good luck. I recently decided to move my project away from App Engine for the time being. I really want to use it because of the pricing structure but I ran into some of the same problems you did only worse. There just always seemed to be something at every step of the way that didn’t work with the mainstream Java tools and frameworks. If I ever have the time to get my head wrapped around all the quirks I’ll try it again.

  2. Thanks for the warnings espescially about the datastore shareing over versions.
    Im just in the step to setup my enviroment for my first “non Hello World” GAE Project.

    Did you use Maven with the maven-gwt / maven-gae plugins or only as dependency management? I decided to use the ant-run plugin instead of the other two.

    Instead of spring I would try guice.

  3. “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.” Amen to that! Spring needs to segregate their configuration-driven IoC container from their programatic one instead of being all things to all people and failing spectacularly!

  4. I think developers would be much better served if Google didn’t offer JPA as an option to access the datastore at all. I tried to make it work for a while because I have a lot of experience with JPA but in the end it just wasn’t worth dealing with all the limitations.

    I started looking into JDO but Objectify seemed to be a much better alternative.
    http://code.google.com/p/objectify-appengine/
    I’ve used it in one live project so far and was very pleased with the results.

  5. My team has had some experience with App Engine. We went through the same learning phase as most people who’ve used App Engine and started off using JDO. We’ve got high expectations for our application in terms of performance, which led us to explore the low level api to datastore.

    The bottom line is that the start up time for a ‘cold start’ request decreased by 2-3 seconds on average out of requests that normally took 5-6 seconds. The numbers varied a lot as we have no control over the start up phase of the App Engine infrastructure so give the low level api a go if you’re serious about performance and response times.

    http://ikaisays.com/2010/06/03/introduction-to-working-with-app-engine%E2%80%99s-low-level-datastore-api/ should get you started.

    Good luck and keep blogging!

  6. Hey Raymond. Thanks for the link. I hadn’t even gotten to the low-level API yet but this looks interesting. I have a few “low-hanging fruit” optimizations I’m going to do first, but shaving a few more seconds of that loading requests would be very good.

  7. Aaron, I think you might be right. Google probably offers JDO and JPA because it’s something many developers are familiar with. But in the end it’s probably better to take some extra time and immediately take your time to learn the ins and outs of the datastore.
    I had learned about Objectify just last week. I think an API specifically for the datastore could be a real winner.

  8. I did use Maven to build my project, but not any of the plugins. I couldn’t make the maven-gae-plugin work and still have the Google Eclipse plugins function correctly. The maven-gae-plugin seems to force you to do everything via Maven. Which is nice for an integration server, but a lot of work for debugging.
    I suppose I will give it another try, but for now I’ve reached my frustration threshold :)

    Guice is most likely a good option. In hindsight though, I only have a limited need for dependency injection so I’m going with a simple singleton pattern for now.

  9. Hi Jorge and all, I love your comments. Keep them coming! :)

    Jorge, have you tried the Java version of the AppEngine? I wonder how they compare. I’m in the process of learning Python so it’s always an option for me to switch languages (obviously a massive overhead, but it would be a great learning exercise).

  10. I must admit that my feelings toward Spring in general have changed during this project. Where it used to be a tool that could be used for almost any project, it seems to have become a really “enterprizy” framework with little attention to smaller, dare I say, more agile projects.

  11. HI all,

    I’m currently doing an app on Google App Engine, but I am using my own Butterfly DI Container instead of Spring / Guice. Last time I tested it, it beat both Spring and Guice on performance (not that the DI part of the exec time is that important).

    Also, I am using my minimal Butterfly Web UI as web framework so far. I still havent’ done anything advanced with it, but right now it works fine. Web UI works fine for both generating HTML, or XML or JSON in e.g. a RIA setup (Flex, GWT etc.), where the server side generates only data, not the UI.

    Does anyone have any comments on the performance of Google App Engine? I hear it’s too slow for real production use? The few tests I have seen, were not too impressive either!

  12. I can’t really comment on the production performance since my application is currently in an (open) beta with only a few users.
    From the little experience I have, I’m pretty confident that once you get past the loading request, performance is at least acceptable.
    There are a few things to keep in mind (for instance, never serve static files through a servlet) and it’s probably also a good idea to do some datastore caching in the memcache, but I haven’t experimented with this just yet.

Comments are closed.