GAE Problems: Slim3 To The Rescue?

Table of contents
Reading Time: 3 minutes

For the past few months we have been working on porting a time-sheet application on Google App Engine. The application we were trying to port had Spring for Dependency Injection, Hibernate for persistence and Wicket as the web framework. Looking at the will it play in app engine Hibernate was an easy call, it is not compatible on Google App Engine, wicket works with some workaround and Spring is fully supported. We decided to go with JPA as it is easier to convert a hibernate application to JPA than to other ORM framework. We decided to continue with Spring and Wicket.

We encountered several problems during porting the application. Most of the effort went in increasing the performance. We used Key-Only-Query, memcache to increase performance. We also had issues with handling consistency of datastore operations across entity groups.

When we select framework for application development, we think in terms of the application performance and the ease of application development. When we are not porting an application but doing a new development we can choose frameworks more freely. For new application development on Google App Engine Slim3 framework seems like a good option.

Google App Engine has a notion of entity groups. It is a very important concept and decides how the Entities will be mapped in JPA for the application.

There is a limitation that an Entity cannot have more than one parent. This can be a major issue while re-defining Entity associations for Google App Engine for the application. The Entity Groups also decide the transaction strategy for an application. Simply put you can only apply transaction on a single Entity Group. Is there a platform which allow us to provide transactions across Entity groups. Slim3 does allow us to work across entity groups.

Slim3 example for transferring amount across two accounts:

[sourcecode language=”java”]
public class Account {

@Attribute(primaryKey = true)
private Key key;

private Integer balance;


[sourcecode language=”java”]
public void transferAmount(Key srcAccKey, Key destAcctKey, Integer amount) {
GlobalTransaction gtx = Datastore.beginGlobalTransaction();
Acount src = gtx.get(Acount.class, srcAccKey);
Acount dest = gtx.get(Acount.class, destAcctKey);

gtx.put(src, dest);

To top it up Slim3 claims that using global transactions are not too slow compared local transactions.

Datastore API is the fastest for datastore operations but finds limited use across developers. JPA is a standard and since Google App Engine is more restrictive, JPA will allow you to shift to a different platform if you choose to move away from Google App Engine.

On the negative side JPA is considerably slower than Datastore Low Level API. Slim3 Datastore is not only faster than JPA but is also easy to use than Datastore API. Slim3 Datastore is performant, the reason being that it does not use runtime reflection for mapping between an entity and a model.

Another problem which we are traditionally not aware is cold start. Google App engine spins down the application when it is idle. Whenever a new request comes up it spins up a new instance of the application. There are workarounds for this problem and we may resort to keeping application hot by rendering it a request after a certain interval. Things can be better for the application if spin up time itself for the application is lesser. Slim3 does not use PersistenceManagerFactory/EntityManagerFactory which is known as a slow starter and avoids extra initializations carefully, so Slim3 spins up fast. It takes around 1100 cpu_ms.

Slim3 supports type-safe query. Since the query is not based on String, java compiler will start to complain if Entity properties has been changed. One example of a type-safe query

[sourcecode language=”java”]
EmployeeMeta e = EmployeeMeta.get();
List<Employee> list = Datastore.query(e)
.filter(e.salary.greaterThan(5000), e.job.equal("ANALYST"))

Slim3 framework optimizes datastore operations. It provides global transactions. Has a faster spin up time, which I think is a better way of improving cold start of application rather than artificially pinging the application. The framework also provides Type safe queries and Hot Reloading resulting in ease of development of an application for Google App Engine. Going by the features Slim3 provides it definitely looks like a framework worth exploring for Google App Engine development.

1 thought on “GAE Problems: Slim3 To The Rescue?4 min read

  1. thanks for this post. I am now looking into Slim3 and it does seem very promising.
    any thoughts about their controller approach vs the GWT activity presenter model one?

Comments are closed.