Quantcast

Grails on google app engine : generic qn

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Grails on google app engine : generic qn

bsreekanth
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails on google app engine : generic qn

aeischeid
I would love to hear people's thoughts on this.

I'll try to chime in with some of what I have been learning.

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.

2. unsure

3. 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.

4. 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


On Mon, Jun 28, 2010 at 12:22 PM, bsreekanth <[hidden email]> wrote:

Hello,
I asked this qn in
http://stackoverflow.com/questions/3119531/grails-on-google-app-engine
stackoverflow , and many people found it useful and favorited.. but didn't
get any answer.. Hope there would me more people experienced with GAE here..


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? I read Shiro (not plugin) already compatible with GAE. Anyone used
it?
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.
--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-on-google-app-engine-generic-qn-tp2271225p2271225.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails on google app engine : generic qn

tomas lin
In reply to this post by bsreekanth
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.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails on google app engine : generic qn

Mark Fortner-3
I've been hearing about some recent efforts to support NoSQL databases.  Although nothing has been said about direct support for BigTable within Grails.  It would be nice if these efforts could get to the point where we could simply change out the driver and the app would work on either a local server or on GAE.  AFAIK, the only solution for cloud-deployment at the moment is Amazon.  Spring has some tooling (CloudFoundry) that makes deployment easier, but that's about it.

Mark


On Mon, Jun 28, 2010 at 12:45 PM, Tomas Lin <[hidden email]> wrote:
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.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails on google app engine : generic qn

tomas lin
I think Stax.net offers a freemium cloud offering as well. Not had a
chance to try them out yet - http://wiki.stax.net/w/index.php/Grails

On Tue, Jun 29, 2010 at 4:56 PM, Mark Fortner <[hidden email]> wrote:

> I've been hearing about some recent efforts to support NoSQL databases.
>  Although nothing has been said about direct support for BigTable within
> Grails.  It would be nice if these efforts could get to the point where we
> could simply change out the driver and the app would work on either a local
> server or on GAE.  AFAIK, the only solution for cloud-deployment at the
> moment is Amazon.  Spring has some tooling (CloudFoundry) that makes
> deployment easier, but that's about it.
> Mark
>
>
> On Mon, Jun 28, 2010 at 12:45 PM, Tomas Lin <[hidden email]> wrote:
>>
>> 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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails on google app engine : generic qn

Mark Fortner-3
Hmm.  Looks like they're using Grails 1.1.1.  Which brings up another point.  Any cloud-based hosting service which doesn't allow you to control the version of Grails you deploy to, could create problems for you.  You may have a perfectly stable 1.2.2 app that crashes in 1.3.2.  

Mark


On Tue, Jun 29, 2010 at 9:04 AM, Tomas Lin <[hidden email]> wrote:
I think Stax.net offers a freemium cloud offering as well. Not had a
chance to try them out yet - http://wiki.stax.net/w/index.php/Grails

On Tue, Jun 29, 2010 at 4:56 PM, Mark Fortner <[hidden email]> wrote:
> I've been hearing about some recent efforts to support NoSQL databases.
>  Although nothing has been said about direct support for BigTable within
> Grails.  It would be nice if these efforts could get to the point where we
> could simply change out the driver and the app would work on either a local
> server or on GAE.  AFAIK, the only solution for cloud-deployment at the
> moment is Amazon.  Spring has some tooling (CloudFoundry) that makes
> deployment easier, but that's about it.
> Mark
>
>
> On Mon, Jun 28, 2010 at 12:45 PM, Tomas Lin <[hidden email]> wrote:
>>
>> 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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails on google app engine : generic qn

Les Hazlewood
In reply to this post by aeischeid
On Mon, Jun 28, 2010 at 11:50 AM, Aaron Eischeid <[hidden email]> wrote:
> I would love to hear people's thoughts on this.
> I'll try to chime in with some of what I have been learning.

> 3. 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.

Shiro (and I'm sure Acegi as well) provides much more than just a
wrapper on top of your DB layer for accessing security data.  You can
use Shiro's slick ad-hoc filter chain capabilities as well as a much
simpler and easier to understand security API, and it can all run on
top of GAE.  The benefit is that 1) you program your app to a portable
security API that doesn't require GAE lock-in and 2) you have much
more power and ease-of-use than what the GAE security API alone
provides.

The Grails Shiro plugin only provides Gorm classes as part of a
quickstart to give you an example and help you get started quickly -
but they're definitely not required.  The key for Shiro is to create a
 GAE-specific Realm implementation to use Google's datasource.  Gorm
is not required.

Cheers,

Les

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails on google app engine : generic qn

bsreekanth
In reply to this post by tomas lin
CONTENTS DELETED
The author has deleted this message.
Loading...