Close

Demystifying widget set cloud compilation

The Vaadin Framework 7.7 release brought major improvements for widgetset handling in general. Probably the most interesting part in the new release is the possibility to delegate the time consuming widgetset compilation to a cloud service, which can also host your widgetset. These are big changes that raise a lot of questions among Vaadin developers. How does it actually work? Is it secure? Can I trust this service in production? Let’s demystify the cloud compilation service.

We just held a webinar on the same topic, but as this is such an important renewal, let’s go through the same things here, as well.

What is the purpose of a widget set in general?

Each Vaadin UI component has a server side class, an API that you actually use in your application, and a client side implementation that takes care of the rendering and state synchronisation in the browser. Widgetsets in Vaadin are GWT modules which combine client side component implementations from the core and from various add-ons to a compact client side engine needed by your application. GWT compilation makes both Java to JavaScript transpiling and a vast amount of optimizations for the code, which makes the GWT compilation part a rather expensive process in terms of CPU and memory usage.

What gets sent to the cloud and back?

On each compilation, the actual output of a GWT compilation is practically identical, unless the Vaadin version or some of the client side extensions have changed. This is also what the new cloud service needs to know to compile the widgetset for you: the Vaadin Framework version and the list of add-ons (and their versions) you use in your project.

Cloud widget set modes.

Choose the mode

You can choose the way your widgetset gets served on compile time by setting the parameter in your pom.xml plugin configuration:

<build>
    <plugins>
        <plugin>
             <groupId>com.vaadin</groupId>
             <artifactId>vaadin-maven-plugin</artifactId>
             <version>7.7.3</version>
             <configuration>
                 <!-- Widget set compilation. 
                      Possible values are: local, cdn, fetch -->
                 <widgetsetMode>cdn</widgetsetMode>
             </configuration>
             <executions>
                <execution>
                    <goals>
                         <goal>update-widgetset</goal>
                         <goal>compile</goal>
                    </goals>
                </execution>
             </executions>
        </plugin>
    </plugins>

    <!-- Other build plugin configurations -->
</build>

or if you prefer, just simply setting the following project property in the beginning of pom.xml:

<properties>
    <!-- Widget set compilation. Possible values are: local, cdn, fetch -->
    <vaadin.widgetset.mode>cdn</vaadin.widgetset.mode>

    <!-- Your other project properties -->
</properties>

By default everything still happens locally as before, but when you use “cdn” or “fetch” options with the new vaadin-maven-plugin, the plugin gathers the version of Vaadin Framework and all your client side add-ons and sends this information to the cloud service, nothing more. No source code or details of other custom libraries is needed to cloud compute a widgetset suitable for your application.

Based on these details, the cloud service calculates a hash that works as a key to your widgetset. In “cdn” mode the service just returns a URL to a hosted version of your widgetset and always returns practically immediately. This way the rest of your build can continue while your widgetset gets compiled by the cloud service. If the widgetset is not yet ready when you, for example, have deployed your application for testing, you’ll get a notification in your browser that states the compilation may take a bit of time.

In the “fetch” mode the cloud service returns the compiled widgetset in the response and the maven plugin saves that to your project’s generated sources.

“Avoiding” GWT compilation

Widgetset compilation is often a major part of the full build of your project. Some Vaadin users have optimized this by creating a separate module for the widgetset, which is then used by the main software project. A new version of the client side module is compiled whenever any of the Vaadin add-ons or the Vaadin Framework version itself is updated. This way you can keep a full build of the main project super fast, even with “mvn clean install”.

The new cloud service uses the same kind of approach to “speed up” the compilation. There are lots of Vaadin applications out there which only use e.g. the core framework and Vaadin Charts. The cloud service compiles a unique widgetset just once and serves the cached version for other users. The very same client side module may now be used by you as well as your teammate and even your closest competitor. Caching works for both “cdn” and “fetch” modes.

Can I use it in production?

Well, that depends. I would certainly use it for my non critical hobby apps, but I wouldn’t suggest all parts of it to our customers.

The cloud service is hosted by Vaadin Ltd, the company which also contributes most to the open source project itself. So it is hosted by a credible company and it doesn’t cost you anything, but on the other hand, there is no guarantee that it will be always up. If the service goes down, your users cannot access your application in “cdn” mode and also, if just your own network connection is down, it might halt your development. Luckily you most often just need to change one parameter and you are back to traditional local compilation.

From security point of view, no source code is shared with the service, but you expose the Vaadin version and add-on version you are using to the service, both in “cdn” and “fetch” options. Also you’d probably like to host all resources from your own server if you are building really mission critical applications, so a no-go for the “cdn” option in that case.

The cdn hosting option supports TLS connections and is fronted by a strong CDN service for fast access from all over the world, but it is still a third party service increasing risks to your application’s stability.

So, we urge you to try it during development, but for production usage, it is still better to fall back to hosting everything yourself.

Other limitations?

Yes, there are. There are currently two major limitations. The first one is that no project specific client side customizations are supported. Currently all client side add-ons (and their transitive dependencies) you use must be available via Directory or from Maven central.

Also, you cannot provide a custom GWT module aka the YourApplicationWidgetset.gwt.xml file. That file is automatically generated by the cloud service and if you’d like, for example, to use a deferred binding rule to provide a custom client side implementation for certain component, it won’t work with the cloud service. The same thing if you’d like to use the widgetset optimization trick, it just doesn’t work with the current version of the cloud service.

Summary

Even though cloud compilation doesn’t fit each and every Vaadin application, because of security, stability and flexibility concerns, we believe it is a great step forward in developer productivity. For most, Vaadin development becomes both simpler and faster.

We are also keen on your feedback and enhancement ideas. We'll be actively monitoring your questions of forum or you can privately send us feedback with the form below!

Try Vaadin 7.7 today!

Feedback form:

Community Spotlight - August 2016

Welcome to another edition of Vaadin Community Spotlight. This month I had the opportunity to talk to Benjamin Larsen. Benjamin is a Software Developer who works for TDC, a big telecommunications company in Denmark, and he has been using Vaadin recently to develop an interesting web application. The most interesting part of his story is that he didn’t have much experience with web development or Java but still managed to deliver a completely functional web application on time.

Hello Benjamin, great to talk to you! Have you ever been to Finland, BTW?

Hi! I would love to visit Finland some time. All that forest and all the lakes, would be awesome to fly in!

It's pretty nice yeah, but I've heard Denmark is awesome as well! So... you are currently studying there, right?

That is correct. I'm studying at Aarhus University to become an ICT-Engineer, Information and Communication Technology. Just started my 6th out of 7 semesters and I also work as an Engineer Trainee for TDC Group. I’ve been working here since 2014, when I started in our technical support.

Cool! Do you find it challenging or difficult to study and work at the same time?

Yes! It can be a pain in the back. But as long as my work is okay with me putting school first, then it's all good. Especially when you love your job so much that you don't even think of it as a job. Seriously, sometimes I ask myself, "are they paying me for this?".

I’ve been there so I totally understand! How did you learn how to program?

Well. I had a small web design company back when I was in high school. That gave me the basic knowledge of programming. But it was when I took a basic course as an electrician that I fell in love with programming. Though it was with relays and electronics, I loved how AND/OR/NOR/NAND could drive an engine, or change a light setting. Later, when I began studying at Uni, I learned C, then C++ and then C#. So real programming was through my education.

How about Java? How did you jump into it?

Well, it's not that much different to C#, you know. So it wasn't really a big problem. I think the hardest thing (compared to what we did in school) was to make it all work in a new IDE, with an Application Server and so on. I needed something that could run on Linux, without me needing to do anything special, and it also should be “high level”. So Java was the obvious choice. I never developed a web application before I met Vaadin. I did use WPF in C# to build GUI's, though.

Interesting! How was it? Why Vaadin? How did you discover it?

Well, I wrote a backend for the system, and then decided to look for frameworks. I looked at many discussions and talked to some friends, and so on. Then I looked at two frameworks, Grails and Vaadin. My friends used Grails, and they all looked so depressed, haha! So, I just looked at some discussions about Vaadin and it seemed like a good, well documented framework with a great community. And it reminded me a little bit about WPF. I started the project in February and finished in late June. Though I am still maintaining it, of course.

I had a look at the screenshots, nice job! I mean, you did all that without any previous experience with Java and web development, right?

Correct. That just shows how easy it is to use Vaadin. Seriously. Look at some tutorials, and play. I've never experienced a framework that is so easy to get started with. The Vaadin community is awesome, the documentation contains examples, and it just works. No need to do all kinds of setups.

That's good to hear! So, what’s the application you developed all about?

The application simply creates a way to set up tests of DSL equipment. For example, when a new internet router comes up and a company wants to use it on TDC lines, we'll test it for them. The way we do it, is by creating a test (through the software) which iterates over a different set of lengths. For example from 0-2500 meters, and then logs data from the DSLAM (the DSLAM is the other end of a DSL line) and the router. Sometime it might show that at 1450 meters, the router does something weird, which needs to be fixed. Though it can test much more.

But the real fun stuff came when I needed to get the frontend to grab and show data from the DSLAM's. Again, with Vaadin it was super easy. In the end it was awesome to see users just choosing a couple of profiles, and then the system created everything automatically.

Interesting project. So it sounds like the final users were happy with the application you developed, right?

They really liked it. Before, they had to set up XML-test-scripts, where they manually have to type everything, and hope they didn't make any mistakes. They got their results as XML-files as well, so it wasn't really user friendly, and was really outdated. I received only good feedback, so good that it wasn't a problem buying Vaadin Pro Tools in case we need to make new projects.

So, what would you say to those considering Vaadin as an alternative to, say, C# or to those without too much experience with Java and web development?

Try it! It is so easy to start working with Vaadin, and it's so easy to maintain. For a noob-webapp-developer like I was, Vaadin is perfect. You can create a small project, and then get a feel for it. Then simply just continue to play with it. And get in the community, you might not know what to do, but someone in the community sure does!

And I have a great example of this: https://vaadin.com/forum#!/thread/12987749
This dude created an example project, just to teach me how to do it. HOW AWESOME IS THAT? That's Vaadin community for you!

Nice! And it was super-nice talking to you, Benjamin. Thanks for your time and best wishes in all the upcoming projects.

Right back at you!

Vaadin Framework 7.7 is out

On behalf of the Vaadin team, I am pleased to announce a new release, Vaadin Framework 7.7.0. The release contains major improvements for widgetset handling and a bunch of bug fixes.

Much less GWT (compiling)

By default the concept of widgetset is now completely hidden and you don’t need to think about it anymore. The GWT module definition file, the one that ends with *.gwt.xml, is now by default a generated resource and should not be added to source control management systems like Git. If a developer doesn’t have any (client side) add-ons in the project, the default widgetset is used and the build is super fast. Client side add-ons added to the project are automatically detected by the build script and a generated widgetset is compiled during a normal build. So no more hassles with .gwt.xml files or @Widgetset annotations, unless you explicitly define those for advanced use cases.

The most interesting improvement, however, is that you don’t need to spend your precious CPU time to do the widgetset compilation anymore. If your project is only using publicly available add-ons, you can use a new cloud service that will compile the widgetset for you. And we’ll store each permutation of framework and add-on combinations, meaning that if somebody has ever requested the same widgetset before, you’ll get it immediately without waiting for the longish GWT compilation at all.

A third enhancement to the widgetset handling is that the cloud service can also host the compiled widgetset. This makes your war files smaller and can also speed up the launch time of your application as its resources are loaded from multiple domains. The Vaadin CDN service is geographically distributed – thus reducing the latency. Still, in production applications, we suggest to serve the whole application yourself.

A more thorough explanation can be found from a recent blog entry, but we are also hosting a webinar explaining the widgetset changes next week, sign-up for that now!

LoginForm de-deprecated

The LoginForm was deprecated a while ago, when modern browsers stopped autocompleting usernames and passwords to it. Luckily an avid community member, Ingo Kegel, found workarounds for this issue and created a LoginForm add-on that works across all modern browsers and became immensely popular.

Ingo contributed these changes to the core and the new version of the LoginForm component is heavily based on the work done in his add-on. There are some small API changes and incompatibilities with the deprecated version in Vaadin 7.X, but it now works with all modern browsers and the @Deprecated annotation is gone. Also the login form can now be customized in plain Java as opposed to the previous HTML template solution.

Build the framework yourself!

There are also some changes under the hood. Vaadin Framework is now built using Maven and the build can be really easily repeated by anyone. This makes it more agile to work with the Vaadin Framework project itself and we hope it will make it much simpler to contribute to the core framework. This is how you build your own custom version from the master branch:

  1. Checkout the project (git clone …)

  2. Make your desired changes

  3. Build a snapshot version (mvn install -DskipTests)

  4. Change your project to use your snapshot build

The long list of smaller bug fixes and enhancements can be read from the release notes.

Get 7.7 now