How do you split big GWT projects?
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.