code splitting: vaadin versus plain gwt

I’m fairly new to GWT (been using for about 8 months) and have just read the Vaadin book.

Our web applications are divided into modules (features). A typical user does not have access to all the modules. For example, we have an application where the interface is tabbed, each tab being a module, and a typical user will not see all the tabs.

We have started migrating these applications from JSP with Ext JS to GWT. Using JSP, the code for a module (tab) would never be loaded into the user’s web browser, which is what we want for security reasons. We do not want the user to even know that a module (tab) exists when they don’t have access to it. If the module (tab) is loaded into the user’s web browser and simply hidden, the user can still inspect the code loaded into the their web browser and determine that this other module exists.

With the introduction of GWT code splitting, we expect to split the GWT compiled code into modules so the code for a module (tab) will not be loaded into the user’s web browser if they don’t have access to it.

Reading about Vaadin, it seems that one can readily code split out a widgetset, but I believe this is a different than what I want, because a widget from a widgetset may be used in (shared by) multiple modules.

Am I misunderstanding? Is it readily possible to do what I want with Vaadin, which is code split out a module (feature) of my application?


I think you are heading the right way :slight_smile:

The biggest difference between in GWT and Vaadin is that in Vaadin the user interface resides in the server-side memory. That makes it easier for you not to expose your UI code to anyone.

The full widgetset is loaded to client, but it only contains the core presentation logic of the UI widgets like a label or textfield. Otherwise your application UI is never sent to client unless it is visible.

So, in Vaadin if you just don’t make something visible to user, he/she has no way of knowing that a part of UI actually exists in the system at all.

(Note: I ignored the code splitting of a widgetset as well as built-in caching in the description above, but that does not change anything security-wise.)

Does this mean, that the GWT code for the hidden modules still exist on the server and can be requested with an HTTP request, the browser just doesn’t load these modules? If so, then your security would be based on so called “security by obscurity”, which means that you trust that the user doesn’t know (or is unable to guess) the URL for the hidden modules’ JavaScript code. If this is the case (I’m not familiar with GWT’s code splitting so I don’t know), I have to warn you that it is a very, very bad idea (from a security point of view).

Like Sami mentioned, with Vaadin, the widgetset only contains the presentation layer of an individual component - not the presentation layer of the application. This means that the application logic or “hidden presentation logic” is never exposed to the client and a malicious user would not be able to access the presentation logic of your hidden modules, not even with carefully crafted HTTP requests. Actually, since the widgetset only contains the client code of individual components, it means that multiple Vaadin applications could share the same widgetset, as non of the application specific code is ever exposed to the client.

Well, to understand our status better, we have started developing GWT modules that are being used in existing page-based applications that were developed using JSP and JavaScript. At this stage, when the user wants to access a GWT module he clicks a tab, which requests an entire new page from the server (page-based) that includes the GWT history

Just to clarify my and Kim’s point here for everyone else too:

GWT code splitting is good performance-wise, but introduces no extra security unless protected by some other mechanism. Application code in GWT is always loaded to the browser before it is executed.

In turn in Vaadin the client-side part is simply a
static set of widgets
compiled with GWT. Your actual application implementation is never pushed to the browser.