The promise of the Google App Engine has been intriguing from the start. In essence, the app engine is a virtual environment for server-based applications hosted by Google. Any developer can write an application and deploy it on the app engine. The hosting is free up to a certain limit. When an application gets traction and traffic gets heavier, Google will ask a fee and scale the hardware for you. The app engine was originally a Python environment, but since a few years it’s available as a Java environment as well. In the past week, I had some spare time to take a closer look at the app engine and write a small sample application. This post documents my initial experiences with the app engine, with hurdles to overcome and thoughts on the technology.
The Java environment of the app engine is a very custom version of a J2EE servlet container. For example, core Java APIs, Java Servlets, and Java Server Pages are working mostly as expected, but a few other components, such as Enterprise Java Beans, JDBC, and RMI aren’t available. The limitations on Java have been documented on this site. Perhaps a more significant difference with other Java containers is the persistency model. App engine has a data store based on Google’s big table, which is very different from a standard relational database. Although the app engine supports standard APIs for persistence, such as Java Data Objects (JDO) and Java Persistence API (JPA), the semantics of these APIs are very different from when a relational database is used. The emphasis of the app engine data store is on read performance and all queries need to be pre-indexed. This puts certain limitations on the use of relationships. For example, the application can’t do inner joins. In order to scale the data store effectively, the transaction model is also different from a traditional database.
The development environment provided with the app engine is Eclipse-based and comes with an embedded servlet container. This allows for rapid local prototype development before publishing the application on the app engine. It was fairly easy to get started with the SDK, although there are a few caveats to cope with:
- JSP code completion doesn’t work out-of-the-box, because the app engine plug-in doesn’t add the JSTL libraries to the classpath of the project. The libraries are packaged with the app engine SDK and can easily be added to the project classpath to fix JSP code completion;
- Generated JSP code isn’t visible in Eclipse, but for the generated files can be found in the temp directory when running the development container. For a Linux setup with the latest app engine SDK, the path is: /tmp/Jetty_127_0_0_1_8888_war____.g0qk00/jsp/
- JUnit testing is supported, but the documentation is somewhat confusing. The trick is to have a normal Java project next to the app engine project in the same workspace. The normal Java project has a reference to the app engine project and the testing libraries as described in the documentation. JUnit tests can run directly from Eclipse.
The sample application I wrote consists of a simple data model, three JSP pages, and a background HTML Web page scraper. The code of the sample application I wrote is available here and the live version is available at visa-bulletin-tracker.appspot.com. The code is available under an Apache 2.0 license, so feel free to re-use and/or reference the code.