Is there an open source, reference implementation of a simple, correctly designed, best practiced, GWT + GAE open source application? I would like to see the best practices on the following:
Recommended GWT Page navigation, session handling
GWT best practice UI (validation, controls etc)
Work with detached objects, conversations, wizards
Effective and "as intended" integration between GWT and GAE
MVC implementation with GWT and GAE, where is the controller? (Spring?)
Using domain POJOs in the UI without writing data transfer objects?
JDO (or JPA) and DAO layer - correct mapping, transaction and service layers
A permission layer, (e.g. like Spring security/ACEGI)
Integration with client side libraries (JQuery / Sancha)
JUnit layer for both server and client side
All the samples I found so far handled a very narrow aspect of the above, and I'm sure there has to be one good "starting point" such as the one's you can find for Spring / Hibernate or RoR projects
Have you looked at Roo?
This can be used to quickly build a GWT app based on one of a number of JPA providers and databases.
It doesn't offer all the items listed but has quite a variety of optional add-ons
Unfortunately I don't know of any such reference implementation, and I don't think you're likely to find such an all-encompassing example is because:
It's much easier to understand an example that focuses on one thing, like focusing on using JDO in a GWT app, or using Spring security in a GWT app, or how to do client-side validation in a GWT app. There's no reason one sample has to include such disparate features.
In the same vein, what if I wanted this exact list of features in a reference implementation, but using something else instead of JDO? Should I expect someone to write everything all over again, with that one part replaced? It's much better to write samples and documentation for each piece of the puzzle and leave it up to developers to glue that knowledge together.
Some of the things you listed aren't exactly common usages, e.g., integration with JQuery and Sencha. That's not to say it's not possible, and there are some (focused) examples out there if you look, but it's not the main use case for GWT developers, so I don't think it makes sense in a reference implementation.
The sort of app you're talking about is very complex, something that would take multiple engineers months to write and then would have to be maintained and updated. All for a sample? Some people aren't willing to invest that kind of energy even when there's money involved!
That being said, there are some great GWT sample apps (with source available) here. Even though they don't encompass everything you listed, they'll hopefully be helpful.
There is a "Google App Engine Java and GWT Application Development" A code of the application they build during the book comes "Licensed under the Apache License, Version 2.0" so (I guess this is qualify as open source but IANAL) it worth looking at. At least it does helps me as I am working through the same set of questions. It written Nov 2010 so it is still relevant as Google Platform evolves at astonishing speed.
Declaimer - I got no relation to this book except that I am reading it.
Related
I am trying to put together my first Google App Engine applicaton and having ploughed through the docs and some examples I decided that I quite like the Objectify approach. However, I also like GWT but passing an Objectify object to a GWT class causes issues.
So I tried Objectify-gwt but there just seems to be tumbleweed blowing thorugh that project. Any examples seem to date from 2010/2011 but the project seems to have been forked off the main Objectify branch recently (April 2014) so I was just wondering if it has a future.
If not, what is a good pattern for passing data between an Objectify back end and a GWT front-end? Do I really have to have two sets of objects, one in the persistence layer and one in the UI?
objectify-gwt is a very small bit of code which doesn't require much in the way of updates. That said, someone just submitted a pull request that fixes a problem with Gradle builds. It's overdue for a new release. But unless GAE adds some new data types, objectify-gwt is pretty much done. I wouldn't worry about the future of objectify-gwt any more than I would worry about the future of GWT in general.
That said, I think the value of passing raw entity types back and forth across the GWT-RPC boundry is overrated. It tends to produce an Anemic Domain Model. When I was actively using GWT, I tended to do this with simple embedded components and not with whole entities. But every project is different; maybe it is a good approach for you.
Such questions have been asked before - but all of the answers are outdated now.
I am looking forward to work on a Scala based webapp. I understand this question can be split into two, but I am posting them as one because they rely on same context, there being a dependency on the hosting platform and frameworks used.
I have read multiple (awesome) debates on Play! and Lift, but cannot find a good comparison between Play! 2.1 and Lift. How do I decide which one is better for my scenario (a social network website) ?
Similarly, this discussion has some very good arguments as to which platform to use for if I go with Lift, but it's from 2010 and seems outdated. The recommended provider (stax.net) is dead (or I guess it's merged with cloudbees.com). I am personally inclined towards GAE, as they are quick to start with, but unsure if the issues still prevail :
Support for actors (I am not sure if Akka helps us solve this problem)
Requests for a given session being served by different JVMs without notice to running app
Quoting David Pollak (lead author of Lift) :
GAE is slow and non-scalable, despite Google's claims (everyone I've
spoken with that have tried to scale GAE apps have failed and gone
elsewhere). GAE locks you into a tremendously suboptimal storage
mechanism. GAE is free, but so is Stax and there are many inexpensive
options including SliceHost. Next up, you've got Amazon EC2 and
RackSpace. So, I haven't found a good reason for anyone to use GAE.
And if there's no good reason to use GAE, devoting a pile of resources
to code around the GAE JVM incompatibilities (e.g., no new threads)
seems like a waste.
Another issue if I go with GAE is lack of Play! 2.1 support. I still don't see a module for that. Another issue is difficulty to migrate to other databases (although I hear migrating to MongoDB should be relatively easier) in the future. Worst case would be to move out of GAE and use AppScale.
Personally I use Lift, Cloudbees, and MongoLab as my first choice for most of my projects. I tried several cloud hosting services to no avail (Heroku and RedHat in particular. I don't think I tried GAE due to the post from David Pollak that you have already referenced). To use cloudbees, you just need an sbt plugin. Then it is as easy as running the cloudbees-deploy target. Within a minute, your code is up and running. I was floored by how easy it was. I went with Mongo primarily because of this excellent g8 template (note, there is now an SQL equivalent)
Another thing I really like about Cloudbees and MongoLab is they both have free services. It's great for me because I only work on these projects in my free time, so I don't want to spend any money while my ideas are half-baked.
As for Lift, I can't compare it much to Play. I downloaded/installed play and was immediately turned off by how MVC it is. I felt that the view-first approach, albeit foreign to me, seemed to be a much more intuitive and powerful way to build web applications. I love how Lift doesn't obscure from me the fact that I am indeed developing a web application. I often feel that MVC frameworks try to keep all of the HTML/CSS/JS etc at an arms-length.
The question is quite open so I will share my experience and opinion regarding Scala web app development as it might help you with your decision.
I built my first scala web application using Scalatra and Scalate using Jetty as the server. The app is hosted on an Amazon EC2 instance and I've had no problems with this... it's been running since the end of 2011 with only one small blip that took 10 mins to resolve. I found it a good experience for learning to use Scala in web applications.
http://www.scalatra.org/
Typesafe (http://typesafe.com) appear to have opted for the Play Framework and so for my next scala based web app I am likely to go for Play. A book I have been reading on the Play Framework is "Play for Scala". It has just been published this month (Oct 2013).
http://www.manning.com/hilton/
My impression is that Lift was the go-to framework in the past but that this has shifted to the Play Framework.
I am planning to develop open source java application to work on google app engine as well as normal rdbms system, so please help me in choosing
MVC Framework -
Struts / Spring MVC ?
ORM -
JDO / JPA ?
I am considering performance as a key factor.
For app engine you will want a lightweight framework, both for persistance and application stuff. Google is changing their pricing model so you might want to consider how this will impact your plans as well. There is an interesting discussion on the app engine group about this: https://groups.google.com/forum/#!topic/google-appengine/ob-kMuDAAqc/discussion
Aside from that I can only comment on the choice of persistance framework:
JDO on app engine is a pain. The version they (Google) support in app engine is 1.x, which is ancient, I believe. I have had more trouble with getting things to work than I care to remember. If you have previous experience with JDO this still might be a good choice. If I were to start over again I would choose a persistence framework that was specifically written for app engine, like objectify or twig. They require less overhead and are easier to use (from my point of view). One giant plus of objectify: gives you memcache support out of the box with no extra work. How great is that?
However, you also want to support an RDBMS. If you have the time, you could roll your own abstraction layer on top of objectify and the RDBMS persistance layer of your choice. That would give you the edge in performance that you are looking for. ;)
If that is not an option I would suggest JPA (not because I have used it myself, but because I had so much trouble with JDO).
Hope this helps!
What do you mean by performance? For instance, if you're not using the always on feature, you might consider the server cold start-up time as the single thing affecting the performance the most. All the frameworks will make it slower, there's even a blog post about optimizing the cold start-up time.
For the MVC, Spring 3 is quite good at it, but it's more personal preference and what you're comfortable with. If you want something designed for AppEngine, give Gaelyk a try, it's Groovy though. For the data storage, JPA is perhaps more widely used, but I think the JDO support on App Engine is better. Both of those provide some level of platform independence, if you need to get off from App Engine. There are also Objectify-Appengine and Twig that are more tied to the platform and thus might provide better interface for managing the datastore.
I would personally go with Java EE 6 framework.So
MVC: JSF -> very lightweight and easy to develop. JSF2.x fixed many shortcoming features from JSF1.2
ORM: JPA2.0 -> since it is standard and come with Java EE 6 bundle. You can replace with Hibernate, your choice. Each has its own unique advantage features. I would not say one is better than other.
Dont forget that Java EE 6 come with EJB3.1. EJB have had its bad reputation to be heavyweight, however since EJB 3.0, it is a much different story. EJB3.1 has become much more light weight and easy to develop. Glassfish web profile provides EJBLite (Hehehehe :D :D much lighter :D)
In term of development complexity, I have to say that Spring is a bit more complex than JEE6, but again, I only touch Spring very minimal, this discussion will leave to much more experienced developers to talk about.
I would go for JSF + JPA and I'd use Spring Framework for dependency injection.
My 5ยข. :P
After a long debate between many RIA/Ajax framework, we settled on GWT. When reading about it, this framework seams to be doing everything well and easy. But like any technologies, there is always down side and we we learn them the hard-way.
What are the main downfalls or problems when using Google Web Toolkit (GWT)?
(eg: Back/Forward Button support, Slow Response time, Layout Positioning, JavaScrit bugs, etc)
So far, I got the following from the response:
Lots of code for simple UI
Slow compilation
Thank you
I have been using GWT for nearly 2 years. Although I could be called a fanatic about GWT, there are some issues that one should know ...
As others have said, JavaScript compilation is slow. My application requires nearly 4 minutes for core i7 CPU, 8 GB memory. Total size of generated JavaScript is about 5 MB. But thanks to development mode, compilation to JavaScript is not needed frequently.
GWT RPC is extremely slow in development mode. It is 100 times slower than hosted mode. It was quite a big problem for us. We did consider giving up GWT just because of this reason. the reason for this sluggish performance of GWT RPC in dev-mode is serialization. Serialization of types other than String is unbelievably slow in dev mode. We did implement our custom serialization, it is nearly 30 times faster than GWT built-in serialization.
Claims that writing GWT application requires only knowledge of Java is just an illusion. You should have solid information about CSS and DOM. If you don't, you will spend too much time debugging your user interface.
You should consider that you can only use a small subset of the JDK to implement GWT applications. Reflection is not available; you should use third party libraries, such as GWT ENT, or write your own generator for reflection.
Another caveat that one should consider is the size of generated JavaScript by the GWT compiler. Most of the GWT applications consist of a single web page, as opposed to multi-paged traditional web applications. Therefore, loading of the application requires significant time. Although it could be mitigated by using a multi-module approach and code splitting, using these techniques is not always straightforward.
All calls to the server are asynchronous. You should adapt yourself to writing asynchronous code. And the downside of asynchronous code is it is more complex and less readable than the equivalent synchronous code.
Here are my observations on the downfalls:
steep learning curve if one wants to use GWT effectively in large applications, due to enormous number of high level conventions associated with GWT.
Model View Presenter paradigm - in fact there are 2 different approaches to MVP proposed on GWT site.
UiBinder
CellWidgets
Editors
concept of Activities and Places
RequestFactory
AutoBeans
asynchronous requests require different mode of thinking when it comes to designing the whole application
long compilation time, it does not affect Development Mode as much as full builds (all the permutations for all the browsers and languages are compiled which can take hours for big projects). JRebel can reduce requirement of Development Mode restarts a bit.
problems with unit testing - GWTTestCase starts so long that it is unusable for unit testing. However thanks to GWTTestSuite it can work well for integration testing. Thanks to keeping clean MVP it is also possible to unit test Presenter logic by mocking Displays (see my answer).
it requires some experience to decide whether specific logic should be implemented client side (compiled to JS) or server side.
and of course there are some small bugs, especially in new features like Editors and RequestFactory. They are usually resolved quickly with new releases, however it could be annoying when you encounter some GWT issue. Anyway the last downfall applies to any Java framework I have been using so far. ;)
lack of reflection on client side, which could be resolved with Deffered Binding and Generators, but it is another convention to learn.
If I was to start new GWT project I would:
add dependency on Google GIN library (unfortunately it does not work with GWT 2.2 at the moment, but should be compatible soon).
design general layout with LayoutPanels
structure application "flow" according to concept of Places and Activities.
put all the Places into separate GWT module (common navigation references)
put each Activity in own GWT module (it could help in application code splitting later on)
treat Activity as glue code which has View and Presenter providers injected with GIN
design data entities to be compatible with RequestFactory
create all data editors with UiBinder, MVP and Editors framework in mind
use RequestFactory in Presenters, as well as in Activities (to fetch initial data to be shown).
inject with GIN every identified common component like standard date format, etc.
The spring roo tool can generate a lot of GWT based code for standard application elements.
I did a prototype app with GWT some time ago, and I found that the time it takes to compile the java to javascript took a very long time. Even more the time to compile increased noteably with each line of code we wrote.
I just wasn't happy with the code, compile test phase getting slower and slower through time.
Another question on SO about the compiler: How do I speed up the gwt compiler?
I think that main disadvantage is that GWT often requires to write lots of code, to acomplish simple tasks (but it's getting better and better with each release). On the other hand it's brilliant when it comes to developing complex, custom widget where it shines.
During couple of projects GWT has proved to be very good in terms of performance and there hasn't been many bugs - it's very good in terms of cross-browser support imo.
as a fan of nativity...
I prefer JQuery rather than GWT, because, it's easy to animate or accomplish complecated tasks without writing many classes..
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
the latest plugin, which has high user rating, has any restrictions? or it work seamlessly with all gorm features
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)
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
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.
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.
unsure
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.
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