Vaadin 24.4 integrates with React, unifies Flow and Hilla development, and more!

Minimized Vaadin servers for IoT solutions

Matti Tahvonen
Matti Tahvonen
On Oct 6, 2015 4:35:00 PM

Trimming down the last bytes of deployment artifact size and server startup time has never really been a top priority for business app developers. These measures just need to be within reasonable values, and are seldom essential things in business applications, neither in development or production environments.

Lately we have seen a lot more interest in using Vaadin UIs in embedded systems and IoT solutions, and sometimes running Vaadin based UI’s from really light weight servers, where you want to save all the bytes you can. To help Sven Ruppert with his Vaadin related projects and to finalize my “make jar not war” week, I hacked together two examples with minimalistic jar packaged server+Vaadin setups.

Undertow + Vaadin ~ 5MB

Undertow is a new sleek web server powering the WildFly application server, which can also be used as a plain servlet container for embedded systems weighing only a couple of megabytes. Also, you can use a programmatic way to define your deployment, freeing your app server of expensive classpath annotation scanning and/or web.xml parsing during startup. The startup time of this kind of server is never measured in seconds :-)

By default Vaadin will add some libraries and source files to the setup and increase the size of the generated überjar closer to 20 megs, but you can get rid of most of the overhead.

These are the tricks I did to bring the jar file size down to about five megabytes:

  • - This service moves the static files generated by GWT compilation into the cloud. And it also does the same for compilation, so there is no need for a vaadin-client-compiled module or the most commonly used setup with an application specific widgetset. The setup also frees some resources from your application server to do more intelligent stuff. This is a great way to save bandwidth if you trust our community maintained CDN and can rely on your end users having an internet connection. The Maven plugin generates a web listener that needs to be registered to the deployment info.
  • Dawn theme - The Dawn theme is a slimmed version of our official Valo theme that delegates font serving to Google’s free font service. I also moved Dawn to be served from an external domain. Note that if you need to serve the theme from your minimalistic server, you probably still want to filter out all scss files as .css.gz and .gif files are all you need from the package during runtime.
  • Excluded sass compiler and other optional dependencies - Vaadin by default supports compiling your theme at runtime. I pretty much always exclude all dependencies related to it as I want to compile my themes in a separate project. The vaadin-server module also contains all server side stuff from GWT projects (Vaadin embeds GWT), which are also almost never needed: I rudely excluded all packages from the überjar.

If you can’t rely on an Internet connection e.g. for some intranet systems, you can still use “CDN-style” methodologies with widgetset and theme. Just set up a separate server into your local network to deliver these static resources, and setup your build so that files generated by theme and widgetset compilation get uploaded to it.

The example setup is available in GitHub.

Jetty 9 + Vaadin = 3.4MB

Jetty has for a long time been the favorite in these kind of embedded java server setups. I took an example by Sami Ekblad and fine-tuned it with similar tricks as with Undertow, and its artifact became even smaller, only 3.4MB. If you can manage with an older version of Jetty (or/and Vaadin), I’d guess it could become even smaller.

Are these setups actually good for anything?

Well, that depends on what you are doing. If you really only need Java and a good looking Vaadin UI then why not? You can also extend the setup with some small but powerful Java libraries, and still have a tiny deployment artifact compared to a typical server + war file setup.

But if you are doing anything bigger (e.g. throwing in CDI or JPA), I’d suggest to look into modular application servers like Liberty or jar file based modular approaches, namely Spring Boot or WildFly Swarm. In IoT applications, if you can have your stuff attached to the Internet, it is most probably easier to move the actual UI code to a server with decent resources using an MQTT broker, than to waste your energy on server optimization.

Also, when wasting your time ironing out the last bytes of your server+Vaadin setup, you should remember that the application server and the actual web application are just a slice of what is actually needed by the server. The underlaying OS and JVM will grab a major part of the disk and memory requirements. Before doing too much exercises in this area, be sure to check out if there are other sweet spots to lighten up your server setup.

Matti Tahvonen
Matti Tahvonen
Matti Tahvonen has a long history in Vaadin R&D: developing the core framework from the dark ages of pure JS client side to the GWT era and creating number of official and unofficial Vaadin add-ons. His current responsibility is to keep you up to date with latest and greatest Vaadin related technologies. You can follow him on Twitter – @MattiTahvonen
Other posts by Matti Tahvonen