Why “versus” and not “with”
Some people may remark that Grails can run on top of GAE. That’s true. In theory you can grab the GAE Grails-Plugin and would be able to deploy your Grails application to the Google App Engine. But you shouldn’t do this. The top three reasons “why not to use Grails on Google App Engine”:
- The GAE Plugin of Grails is maintained badly. It breaks regularly with every new Grails-Version.
- Grails’ functionalities are restricted on GAE. (Because of the non-relational database and the Java API restrictions on Google App Engine)
- Startup Time of Grails Applications is unacceptable slow on GAE. This leads to many downtimes for your users.
Google App Engine Trade-Offs
GAE is a PaaS (Platform as a Service) that supports Java and has its strength in big data and scaling. It works well with Java applications that have a lean data-model and not a lot of dependencies inside application’s modules. For applications with a huge amount of data, demanding processing work and the requirement to scale up fast, Google App Engine is especially productive.
Please note the top three reasons “when Google App Engine should not be used”:
- You are going to implement traditional application with large (relation) data model, use of transactions and many functional modules.
(Examples would be enterprise-applications or complex user-communities. Implementing those on GAE would be a pain.)
- You would like to use your favorite frameworks like Spring or Hibernate and wouldn’t be locked into Google App Engine at any time.
(Traditional frameworks like Spring don’t work well with GAE. The main problem is much increased startup time that leads to downtimes.)
- You would like to have feedback and support from your cloud-provider if the platform has issues, payments did not succeed or other mystery stuff going on.
(Google sucks in customer support!)
Grails – the swiss army knife
Most of my current projects I’m doing with Grails. It’s a great framework for fast development of web based applications. It’s built on the foundation of the established Spring- and Hibernate-Frameworks, adds Groovy to allow dynamic programming and offers design patterns that leads to efficient and DRY source-code.
In general I recommend giving Grails a try. Nevertheless, here are the top three reasons “when not to use Grails”:
- You know for sure that your application will get traffic as hell and you need fast and cheap scaling.
(It’s possible and done with Grails, but it’s much more costly than using a scalable PaaS.)
- You, your colleagues and/or your boss don’t like dynamic programming languages like Groovy.
(You can try to convince them (Groovy 2.x can compile static!). But there is the chance that you have to stick with the good, old and boring Java language and frameworks.)
- You always have to use the latest and brand new framework versions.
(New Grails releases have often some major bugs. Hence, you should go with the “LatestVersionNumber - 0.1” version.)
Conclusion – What’s with Linkanu
Now, on which platform will www.linkanu.com be implemented? I chose Google App Engine for this. Linkanu is a searchengine-type application. High-level it works like this:
The user enters two personal input values. The result would be a couple of websites and web-offerings that the user always was looking for. It is based on a special “comparing-algorithm” and a huge index of data. Linkanu is one of the exceptions which proves my rule “in general go with Grails, unless your application has special requirements”. Check it out: