Archive for March, 2012

Web App Design With Google Web Toolkit (GWT)

I’ve been exploring Google Web Toolkit (GWT) for a little more than six months now.  I’m in the process of a rewriting an older web application, which was developed based on more of a traditional architecture – with forms and form handlers.  It was written in ColdFusion and Java.  The CF layer is used as more of a scripting language, with most of the work done by several Java class libraries built for the app.

While using GWT I’ve started to experience a change in how I think about the design of web apps specifically built in GWT.  In particular, the management of application state is quite a bit different.  That leads to a different way of executing various actions, which would typically be persistence related (ie. reading and writing to a database).  I would be curious to hear feedback about this, particularly from other GWT developers.

First, let me review how I think of “traditional” web app development.  We all know that HTTP is stateless.  In other words, one page knows nothing about prior or successive pages served by the web server.  Fortunately, there are cookies and sessions to circumvent this limitation.

For purposes of discussion, let’s use a bookstore web app as an example.  Assume the online bookstore allows books to be browsed and purchased.  A shopping cart stores purchased items.  The bookstore also includes informational material – say on authors and publishers, etc.

With the bookstore, information typically needs to be remembered when a user visits.  For example, the collection of books in the shopping card must be remembered until the user checks out.  Typically, this is done in session variables.  The session variables are actually stored on the web server (and managed by the application server).  Each user has there own set of session variables.

It would be possible to build a web app without session variables.  One way is to simply store all state on the URL.  For simple apps this isn’t too difficult.  For more substantial apps it can lead to some ugliness in design.  For example, consider the bookstore shopping cart.  The following could appear in the URL to represent books in the cart:…/*.html?booksincart=123,456,789

Note the part after the question mark.  The “booksincart” argument is a list of book ids.  This would have to appear as part of every URL in the online bookstore.  It proves to be rather ugly to implement.  Fortunately, session variables provide an easier way to store information in a stateful way.

With GWT, I am beginning to see an alternate way to store state.  A GWT app appears, from the programmer point of view, like a Java app that runs in the browser. It is really Javascript (and that is part of the magic of GWT), but conceptually think of it as a Java app.  Java apps can store all sort of variables – global variables, class variables. static variables.  I am learning that this is a great way to store application state and it replaces the need to store state in the session.

Compare a “traditional” web app with a GWT web app.  A traditional web app stores state in the session.  The actual session data resides on the server.  With GWT, state is stored in the app, which is on the client (in the browser).  This is a bit of a revelation for me.

The location of app state (on the client) then leads to a change in how I think about performing actions (on the server).  The server side operations (ex. save cart or place order), are stateless.  The client has to pass all state to the serve (or RPC).    This can even include the user, which is typically store in a session with a traditional web app. The operations then become very web-service-like in form.

Another way to think of this is going back to the comparison with a traditionally designed web app.  To get rid of most session variables, one could store all state on the URL (as discussed above) in arguments.  GWT could be thought of as a much more convenient way to store application state.  A well designed GWT provides for better conceptual design and state management.


March 29, 2012 at 2:49 am 4 comments

RSS Twitter Timeline

  • An error has occurred; the feed is probably down. Try again later.
March 2012
« Jan   Dec »