Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Grails on google app engine

What is the current status of grails and google app engine deployment. I am new to app engine but wonder worth exploring it. Some specific qns are

  1. the latest plugin, which has high user rating, has any restrictions? or it work seamlessly with all gorm features
  2. is there any issue with high startup time for grails application. How is it in real world scenario? (with a typical small and large scale application)
  3. what about other grails plugins (like, shiro, joda time, nimble etc). I guess they wont play well. So using those libraries directly is the better option
  4. If decided to give up goole-app as a deployment option, how easy to switch to a normal environment. The JPA support ensures the compatibility with other traditional DBs?

Not sure what else are major issues.. probably, this is the foundation for a good discussion.
thanks.

like image 280
bsr Avatar asked Jun 25 '10 15:06

bsr


1 Answers

I got few good response from grails mailing list, and the conclusion shares the comment by David. see the thread here

Couple of relevant responses:

From Tomas Lin:

I would suggest looking into Gaelyk if you really want to build a project on the App Engine. It is built from the ground up with the App Engine as the target engine, so it can bypass problems like long loadtimes due to Spring and Hibernate. The newly introduced plugin mechanism guarantees that your Gaelyk applications can be extended in a way guaranteed to work on GAE.

Gaelyk has it's own native entity persistence DSL, which is a little cleaner that the JPA/JDO abstractions on top of the App Engine.

I currently see many HardDeadlineExceeded exceptions with the App Engine and Grails. It is just not designed to work well with Spring right now. Hopefully this will improve with the later releases of Groovy, Grails and the Spring / Google partnership for GAE for business, but I wouldn't consider Grails on GAE production ready.

Even with Gaelyk, there are reports of slow performance. So imagine the difficulties that arise with the much bigger Grails stack.

The app-engine comes with it's own implementation of a user / security management system based on GMail accounts. If you just want to provide an admin / non-admin implementation, this is supported in the appengine configuration. Cannot comment on Shiro.

Be aware that one of the major restrictions of the App Engine is the inability to write a file, so even basic file uploading in Spring becomes problematic since the default mechanism writes to a temporary file. I would imagine that most of the plugins would not work out of the box without digging into their code and changing it.

I think the biggest issue here is lack of support for native JDBC. JPA is not as well supported as plain JDBC GORM, things like named queries would probably not work out of the box without retrofitting. If you want to use the latest and greatest parts of Grails, it might be worthwhile to consider other hosting solutions.

From Aaron Eischeid

1.The GAE plugin and the JPA-GORM plugins combined do not get you all GORM features seamlessly. Though you should get basics like .save(), .delete(), and maybe .list() the dynamic finders etc. are going to be out (at least for now). I could be way off here, but I think most/all Hibernate dependent features are out or replaced by something else (since it relies on SQL under the hood and GAE doesn't currently have SQL based DB...) so for example any criteria builders are a no go. It is unclear to me how much of the dot drilling you can do on objects. For example, not sure if you could do something like:

def b = new Book() def stores = b.authors.publishers.bookstores

One place I could use some pointers is how to use JPA in the domain classes. I am sure there is good info out there, but I just haven't found it yet.

  1. unsure

  2. grails plugins that include domain classes or manipulate your current domain classes are bound to have issues since you have to construct your domain classes differently to play nice with JPA which is necessary because Googles Datastore isn't quite like a relational DB. On the flip side. you can use Google's built in security so you shouldn't necessarily need plugins like Acegi or Shiro.

  3. This probably boils down to the different levels of GORM that you can use in controllers and services and the different ways you define domain classes. Some refactoring seems inevitable unless JPA plays just as nice with SQL DB's as it does with Googles Datastore. If JPA can move like that then transferring should be easy, but by using JPA-GORM you give up some stuff you would probably want if you weren't benefiting from due to being on GAE.

Eager to hear what others have to say,

Aaron

like image 168
bsr Avatar answered Sep 21 '22 19:09

bsr