This is just one perspective in tracing the trend. It does not aim to address all segments or applications.

Snapshot: December, 2009.

Recently, I got around to exploring the possiblity of using GWT as an alternative to the current server-centric presentation layer framework stack I have been using.

My initial study brought me around to the not so subtle differences in GWT’s approach;

• GWT actually takes us back to the old days of fat-client client server designs, where the world centered around the user interface and the server was just a means to share data. On the surface it might appear that this is a step back, but there are other tradeins that might make it worthwhile.
• GWT takes away the pain of deploying such a client interfaces on end user workstations; an aspect that drove application designs to the server centric web application model prevalent today. In the GWT world the internet browser becomes the runtime host for the client application. More specifically, the Javascript engine within the browser becomes the runtime environment. Client application code downloaded on first request is actually Javascript. Yes, it is possible to view the client side code. GWT team has make considerable effort in obfucating it.
• GWT allows the user interface to be developed and maintained in Java. Developers do not need to learn the intricacies of Javascript. GWT takes care of cross-browser compatibility issues.
• Considering GWT as an option is now going to involve revisiting all those 2-tier client server design problems. To understand how many of those issues GWT addresses and what solutions I can devise for the loss of server-centric goodies.

Delving deeper into GWT, I can clearly see the following benefits GWT aims to provide:

1. Scalability: More concurrent users per server; cpu cycles are not lost in rendering the view. My jaws dropped when I turned trace on for a JSF application. The component structure in JSF sure comes at a price. For a company like Google which would like to save every server cpu cycle it can, I can see why the GWT approach is so attractive.

   In today’s application delivery landscape that is steadily moving towards virtual clouds, should’nt the choice of application architecture prepare us to optimally use the new landscape?

2. Cross-browser compatibility: Browser quirks are messy and here to stay. The promise seems to be that GWT designers have solutions for these quirks and GWT itself will insulate me by generating the quirk-fixed javascript application (client) code specific to the requesting browsers. This happens prior to the application deployment, during the application compile phase.

   I think this is a huge plus. How much of this promise does GWT really keep is something I would like to confirm.

3. Attractive and clean looking user interface widgets: It is really simple and almost Swing like to develop using the GWT widgets. There are good 3rd party libraries too; though for optimal application size it is recommended that developers stick to using the standard set.
4. Responsive user interface: GWT renders the view from within a browser and does not need to send expensive http requests to the server to render its user interface. This decoupling sure provides a better responsiveness to user actions.

   Actually, there is an interesting design within GWT that makes this responsiveness happen. It has to do with the single-threaded ui event handling legacy we live with in the browser. If you click a link or POST a request, the browser waits for the request to complete, before it can update any part of the ui. GWT introduces an Asynchronous handling behavior that ensures that user clicks/actions return quickly; and the response to the dispatched service request is processed in the background. The AJAX capabilities are built-in.

What price would we end up paying for the GWT goodies?
Choosing a design element does involve an understanding of the tradeoffs one needs to make. In the context of the space that typical web/presentation frameworks fill, I was able to isolate the following aspects that could pose a problem while adopting GWT.

1. Runtime modularization of the user interface is not going to be easy
   Why? GWT compiles the application code (java) within a module into a separate javascript application. The generated code is self-sufficient and contains within it all the required dependent javascript libraries. At runtime, it runs as an independent javascript application within the browser. Another module will need to be developed as a similar independent application and GWT does not seem to be provide a seamless way for the two to communicate within the runtime space.

   I believe this limitation is imposed due to the javascript compilation and obsfuscation step which prevent runtime binding of method calls. The workaround is to achieve a compile time binding during the application compilation process. Doing so, however results in larger compiled application size (that would need to be downloaded on first use) and the option to only deploy the parts of the application that the user needs is lost.

   This should not be confused with the long compilation time problem that lot of developers have complained about during development. I think the long compilation time is a smaller issue compared the lack of runtime moodularization that large and complex applications need.

   The server-centric web frameworks do not having this problem as they generate the presentation view on demand.

   This limitation could become glaring when the application runs on an OSGI framework where the runtime modularization provides some very interesting module lifecycle capabilities and application design options.

   A hybrid approach of using the server-centric presentation layer to manage the top level navigation for the application and leaving it to GWT to manage the user interface within the content/workflow areas could be a workaround.

2. A different pattern to secure the web application will need to be used
   Typical web/presentation frameworks controlled access to the requested view and secured the application. Acegi and similar security frameworks are easily integrated into the servlet infrastructure to provide security. The GWT application user interface however runs on the browser and there is no easy uncompromising way to enforce view/functionality level security.

   Securing the GWT application is going to involve a paradigm shift. We would need to assume that user interface workflow and call sequence may be comprised. On the server, all the RPC call requests will need to pass through the authorization filter. We cannot view the page views as securable items, instead we need to view the RPC requests as securable items. For existing applications being migrated to GWT, such a paradigm shift would be really expensive.

   An interesting workaround would be a smart approach in the RPC api design. Instead of being overly grannular, each RPC should represent all the data required from the server to effect a view change on the user interface. RPCs represent the data required to service a page view, rather than just a grannular application data chunk. Such a model might even work for REST based design where a resource represents the group of data backing a view.

3. Data that backs the View now pose interesting design implications
   In the server-centric presentation frameworks, developers used templating infrastructure (velocity, ftl, facelets etc.) to intelligently map the data from the service layer into the view. It was easy to do so as the View was generated on the server itself after the invocation of the service call. Even if only a fraction of the data from the service was used in the view, the overall request was efficiently processed.

   With GWT, this now poses a new problem. The intelligence of what data to show in the view is now running on the client. The server has no way to optimize what data to send over the wire to the client. This could mean that the GWT applications may end up sending larger chunks of data over the wire. A lot of this data may never be used in the view, subject to the type of application. A careful design of the data returned by the RPC will be warranted for complex applications, and the effort involved in doing so could be large. A side effect of this optimzation could mean that the “view generation intelligence” would now need to be located at two places (client and server) and there would be additional memory requirements on the server.

4. DTO step, GWT Serialization and Lazy initialization of persistent collections
   The GWT-RPC mechanism allows POJOs to be sent over to the client side almost transparently. The design of the POJOs however should be available to the GWT compilation process and making this happen would definitely involve a little bit of tweaking of the build process especially if maven is being used to modularize the codebase.

   A tricky aspect shows up when the application uses hibernate managed POJOs. When Lazy initialization of collections are used while retrieving data, hibernate creates proxy placeholders. The data represented by these placeholders will not get transfered to the GWT client side. This probably implies that in most cases we will have to avoid the use of lazy initialization. There is a library called Gilead which can possibly address this problem by taking away the programming overhead of fetching the collections before serializing it for the wire.

   Domain Driven Design principles seem to suggest that the domain objects (POJOs) should be used as far into the presentation tier as possible. Additionally providing the benefits of not requiring a DTO step. With GWT, if we use the GWT-RPC mechanism, GWT serialization will do the DTO step. If instead GWT-REST were used, then we would need to explicitly serialize to an XML stream.

   DTO or other optimization steps when considered on the server side to address these aspects will invariably come at the cost of increased memory usage on the server.

5. GWT RPC can turn out to be a limiting proposition for complex applications
   GWT RPC does not seem to fit very well if an application already has considerable Spring MVC/Webflow infrastructure on the server side. There is in interesting library called GWT-SL (server library) that allows the spring beans to be RPC endpoints. How well these 3rd party libraries will be supported in future will be a point to consider.

   An alternative to GWT RPC is to use GWT-REST. Doing so would allow the RESTified applications expose the Spring MVC based services with lesser work.

Summary
The choice of GWT is surely going to provide a responsive user interface, force a good design of the service layer, bring about a considerable decoupling of client and server code and quite importantly reduce the computing overhead on the server and improve scalability. When I started off with this GWT analysis, I was hoping to learn how GWT might reduce the weight on product development teams. After my analysis, I feel it is not going reduce burden; it might only allow me to shift some weight from one leg to the other.

The choice of how to distribute the weight depends on the context of the problem we aim to solve. Nothing new, right?

I would be glad to hear what system architects who have considered bringing GWT into their design think about the tradeoffs associated with using it.