As a coding exercise, I started writing a small application for the Google App Engine environment. It is a very simple web photo gallery, managing photos in albums. The main purpose of the application was to get my hands on some new frameworks, and also learn about deployment on the Google App Engine Environment.

You can look at the application here: http://photos.moritzpetersen.de and browse the source code here.

The application’s architecture is a simple 3-tier architecture:

• The repository tier is responsible for persistence. I chose JDO as ORM technology.
• The service tier is responsible for handling business logic. I tried to encapsulate as much logic as possible here. However, there are some exceptions, but I wouldn’t consider it business logic. For some features I implemented JSP EL functions (e.g. showing the right copyright date at the footer of each page).
• The web tier is manages the web requests and interaction with the forms. As web framework I have chosen Stripes, which was a good choice. From the Stripes framework, I used templating, validation and error handling and file upload.

All layers are stitched together using Spring 3.0. Here I used mostly annotation based configuration of the container. I also used the JdoTemplate to easily implement the JDO repositories. Using Spring was a lot of fun, as it allowed me to implement some parts of the application very generic first: the service tier was completely generic for the first CRUD use cases, and I could easily extend the generic services later. Spring simply stitched together the right classes (emmitting a lot of warnings as I use(d) autowiring by type).

For security I used the GAE specific application security configured in the deployment descriptor. That caused the first problem when deploying the application to the App Engine: I had to use my Gmail user, not my Google Apps user for administration of the application – and I’m still not sure what the actual problem was (but maybe I should just RTFM).

The next problem was also caused by my laziness: I didn’t create any index definitions – and promptly the application threw a lot of errors because of missing indexes. Again: I should better RTFM.

But after a while, GAE automatically generated indexes and the application ran without throwing exceptions. But I immediately noticed – confirmed by a quick look at the administration dashboard: the application is too slow. It consumes a lot of CPU time for scaling images (e.g. creating thumbnails). As a quick next step I implemented a cache layer. Architecturally, the cache layer itself is a service used by the PhotoService. I am not quite confident about this implementation, but it does its job well. My original idea was to implement the cache layer as a layer between repository tier and service tier, or implement it directly into the repository tier. But during development I figured out that the cache is quite closely related to the business logic (scaling of images) and not to the persistence.

Finally I am quite satisfied with web application development on the GAE platform. The development environment is very easy to use and deployment is almost trivial. It is very easy to bring an application in production. On the other hand, my initial impression of the performance is quite mixed; loading pages takes very long and measuring the performance indicates that the GAE platform itself is not very responsive.