TURDUCKEN – How to handle big GWT projects?

How do you split big GWT projects?

A pattern used internally by Google (e.g. by adwords) was presented by Rob Keane and carries the name TURDUCKEN, which comes from “TURkey DUck chiCKEN”, that pretty much describes the approach…

turducken

When tackling big applications, you can either go for the monolithic one module approach, or try to split the application into many smaller ones with separate entry points, breaking the “single page” principle.

  • One module problems: one release, one build, very large if split not working, hard to test.
  • Many modules problems: full page reload, no split possible at all

According to Rob, at the end, multiple GWT modules is the only way to go… but how to handle page reloads?

The TURDUCKEN approach describes a surrounding global container, the first thing to load.  This way we still have a global single page GWT application that only reloads parts (submodules), providing a custom global shared place in the global container. For example,  the container could handle the overall history and the submodules containing their own entry points.

When a module should get loaded, you add the required script tag to load the corresponding module. All modules live then in the same container.

  • The container provides the main UI management, modules not going for the root panel anymore
  • CSS should avoid global style names (@external) to avoid conflicts (change body ID if you really need @external and must avoid collisions)
  • Introduce a custom history handler that does not change the URL directly, but propagates history changes via events to the container

To make inter app communicaton possible, you must create a global event bus hosted in the global container. This global event bus must be accessed via a JSNI based wrapper, wrapping and unwrapping of events must be implemented properly. One approach could be introducing GWT auto beans to serialize objects being passed back and forth between modules through the container.

Introducing a TURDUCKEN approach depends on number of teams, application size and submodules structuring. Most important: when using the actual common approaches typical to GWT rich client development, moving into such an TURDUCKEN approach should be possible.

 

GSS – Google Closure Stylesheet support for GWT

Surely anyone will agree that GWT badly requires a better CSS report. While the CSS resources introduced in GWT where a major step forward, CSS3 is here and it would really be great to have Closure Stylesheets working with GWT:

Closure Stylesheets is an extension to CSS that adds variables, functions, conditionals, and mixins to standard CSS. The tool also supports minification, linting, RTL flipping, and CSS class renaming.

GSS is a open source project at Github that brings a lot of CSS magic to GWT. It is planned to merge into GWT 3.0, but you can use it right now.

Unlike stated in the Github page, GSS does not require a trunk version of GWT as soon as you start using GWT 2.6…

GWT as an open source project, current status

Since GWT has been open sourced years ago, GWT mainly stayed an open sourced project run by Google. This has been changed with the introduction of the GWT committee and the big move into more openness.

Matthew Dempsky shared a few insights with the current state of GWT as an open source project. GWT finally detached from integral Google build process, moved to external GIT and Gerrit as first source of truth.

The GWT “re-opensourcing” and move to GIT started paying of. From 5% non Google patches in 2012 to actually 20% in 2013. Still rough spots in the review process, no official ownerships: only unofficial owners and un-owned code. Integration builds are still a problem, since testsuite too large, too expensive to run. Presubmit testing delivers fast response.

The build process is a work in process. The move to maven was stopped as seen as unfitting for GWT. The ant build files are working but are not good, there is some interest in gradle/ buck. Unfortunately there is no dependency management yet.

The future of GWT and web development

Vaadin is actually hosting a purely GWT focussed, not the first one, but it is a long time since we had a GWT conference, and Joonas (from Vaadin) shared some stats: we have 600+ attendees in San Francisco and in Frankfurt together, Frankfurt being sold out.

Ray Cromwell just held the keynote on the gwt.create conference in San Francisco and shared some quite interesting insights on where GWT has come from and how it is moving forward.

While GWT has it’s roots in a time where JavaScript VMs where slow and incompatible, the current state of the browsers and their JVMs is quite different.

chart

So the main challenge in web development changed, and GWT being used so widely at Google, will move forward as well. While speed is going to improve further (Google is still working very hard on the compiler, improving split point generation, fully integration of the closure compiler and much more), the main magic (from my personal view) is happening in the JS inter-operation.

There are really many powerful JS libraries, and modern web development uses them all. The GWT team is working on seamless integration of JS libraries, from lightweight wrappers (say goodbye to JSNI and overlay types) to zero effort JS interop, where the required Java interfaces get generated auto-magically for the JS libraries you drop into your project. And best of all – those libraries should be used un-minified in development and will be parsed by the GWT compiler and get all the optimizations the GWt complier is great at. This means that you can drop the complete jQuery library into you project, but only the JS you use will find its way into your application.

The next major GWT release is expected to come mid 2014 with full Java 8 support and hopefully a bunch of the new magic demoed today.

WJAX 2013 – GWT DAY

Nach längerer Sendepause mal wieder Folien von mir aus zwei GWT Vorträgen, dieses Mal von der WJAX 2013. Neu dieses Jahr ist ein dedizierter GWT Day mit Themen Rund um die Software Entwicklung mit dem Google Web Toolkit.

Den Anfang hat Daniel Kurka mit einem sehr interessanten Vortrag über GWT im allgemeinen und JavaScript Besonderheiten im speziellen: History, Present and Future of GWT → Folien.

Meine Vorträge hatten den Fokus auf Architekturentscheidungen in der GWT Anwendungsentwicklung, sowohl auf dem Client als auch in der Kommunikation mit dem Server:

GWT Architectures and Lessons Learned → Folien

GWT-Entwicklung ist Rich-Client-Entwicklung, und das ist für viele Webentwickler neu. Mit den “Lessons Learned” aus der Entwicklung von Google AdWords wurden Architekturmuster für GWT-Anwendungen vorgestellt. Einiges davon ist inzwischen in GWT gelandet und kann sofort eingesetzt werden. In diesem Vortrag werden Architekturmuster vorgestellt, die in den letzten Jahren in einigen Projekten erfolgreich eingesetzt wurden.

Client-Server-Kommunikation mit dem Command Pattern → Folien

Eine Client-Server-Architektur stellt besondere Anforderungen an die Client-Server-Kommunikation. Einerseits wird Sparsamkeit angestrebt, andererseits absolute Flexibilität, Wiederverwendbarkeit und Wartbarkeit. Gerade im GWT-Umfeld fehlen clientseitig eine vollwertige JVM und das Reflection-API. Hinzu kommt noch der teilweise ungewohnte Umgang mit den asynchronen Aufrufen. In diesem Vortrag wird das Command Pattern vorgestellt. Es werden konkrete Lösungsansätze für Batching, Caching, Security und Journaling vorgestellt.