Vaadin Web app with Computation heavy back-end

Question

I've developed a java application that analyses huge chunks of data from a database which results in a fairly long computation time and generates cvs files that i visualise with a charting library.

So in order to avoid switching between a java-swing interface for user input and the visualisation in the browser, i decided to develop a Vaadin application that uses the already existing code as a back-end and offers the interface for the inputs and the visualisation.

Since it is my first time working with Vaadin i'm trying to figure out how much of what i'm trying to do is feasible especially since time consuming computations will definitely generate a session timeout.

if i use polling wouldn't that be too much workload on the server considering many users might lunch calculations at the same time?

another thing i should mention is that i'm using actors in my existing application, is there a way to use it for a push like behaviour to send a notification when the work is done?

Answer 1

Yes, your project may be a good fit for a Vaadin app.

Scalability

Scalability can be an issue with Vaadin as your entire app lives on the server, with only a representation of the UI widgets on the client. All your business logic and data structures live on the server, not the client. So a Vaadin app can eat up memory and CPU usage on the server.

Whenever possible, cache results on the server, and share data amongst the users’ sessions. Most of the UI widgets cannot be shared, as they have state that changes per user. But you may be able to share your backing data.

Look at this two resources about scalability in Vaadin. Vaadin certainly can scale. The Vaadin company has made simulations with 11,000 simultaneous clients. See:

• Vaadin Scalability Study - QuickTickets (company blog post)
• Scaling with Vaadin and WildFly Webinar with Arun Gupta (video presentation, YouTube)

See my Answer on a similar Question for some discussion of when to consider Vaadin.

Threading

Threads may be very useful.

Java now offers some powerful yet simple support for threading. If you can perform chunks of your computation over time, then do so on threads.

Vaadin has built-in support for updating the user-interface from a background thread(s), similar to Swing’s SwingWorker. The UI object (all your content in a browser window/tab) offers the access method for scheduling a Runnable to update widgets. Something like this:

getUI().access(
    new Runnable() {
        @Override
        public void run() {
            // Update widgets here. 
            // Change Label text, TextField contents, and so on.
            // Show results of your computation (interim or final).
        }
    }
);  // Or use Lambda syntax in Java 8.

You definitely want to avoid those long computations within the user’s UI thread. At the very least, it will lock up the UI resulting in the user’s frustration and possibly thinking the app has crashed. At the worst, the session may time out as you mentioned. Just as with Swing, the solution is to do the busy work on a background thread, then schedule updates to be done on the user-interface.

Spinning Wheel

If your app has no other usefulness until the computation is complete, then you can display a spinning wheel indicator. Use the Progress Bar widget in "Indeterminate" mode. See demo of Progress Bar, click Gear icon to check the "Indeterminate" mode on "Sample" tab. Use the "Theme" tab to see each different wheel style for Valo and Reindeer themes.

If you can quantify the progress of your computation as a number between 0.0f and 1.0f, you can use a Progress Bar with "Indeterminate" property turned off.

Push

Background processing with threads is easier than ever now in Vaadin 7. Push technology is now built in to Vaadin.

See this chapter in The Book Of Vaadin.

Without Push, updates to the UI would only be delivered to the browser after a user’s action such as a button click (unless you pulled some tricks).

In Vaadin 7, you merely add the @Push annotation to your main class. Then the bundled Atmosphere library takes over. Atmosphere takes care of automatically trying WebSocket connections to deliver the updates. If WebSockets is not available, it falls back to other approaches such as polling.

Atmosphere has been a very successful project, used in many products. So for the most part it works very well. Be aware though that Push and especially WebSocket is relatively new technology with many changes in specs, implementations, servers, and browsers. There may be some bumps along this new road.

Working Examples of Push

I have provided the source code for two entire example projects of using Push with Vaadin. See this Question for a simple one. See this other Question for more depth.

Polling

Regarding your specific question:

If I use polling wouldn't that be too much workload on the server considering many users might launch calculations at the same time?

Various kinds of polling are used all the time on the web in Push technology. I imagine you are seeing it right now (if using a web browser) as StackOverflow updates your "Recent inbox messages" & "Recent achievments" badges up at the top of this page.

Polling is by definition inefficient. The browser will be making calls to the server that will often be fruitless with no fresh data yet produced on the server. And an HTTP connection is relatively expensive to establish.

But the overhead and expense is not inordinate. Polling works, probably happening billions of times a day around the Internet.

With HTTP/2 arriving, these calls will become more efficient with less overhead.

The optimal solution would be for the server to notify the client when fresh data has become ready. This is the raison d’être of WebSocket technology, for the browser and server to keep open a live network connection to allow bidirectional communication at any time. As I said above, the Atmosphere library automatically tries WebSocket and falls back to Polling if need be.

So, the answer to your question, is "No, not too much workload for server.". Polling is a practical solution in common use for keeping a web client up-to-date with server-side events.

Updating UI

I'm not savvy about actors.

---

UPDATE: Vaadin 8 has a new data model that is much simpler, discarding the Container and Item constructs shown below to basically use POJOs by leveraging modern Java syntax and generics.

---

But I can explain that Vaadin comes with its own data model. Behind all the UI widgets is a backing data structure. This structure is built on top of Vaadin-defined "properties", as Java lacks its own good property support.

When you modify that backing data, the widgets are automatically notified and update their display. I presume that your actors would be the triggering device for updating that backing data.

The Vaadin data model is explained thoroughly in The Book Of Vaadin.

Multi-module Project

If you want to keep your current back-end project separate and independent from your Vaadin UI project, you can.

The new Maven archetypes provided by the Vaadin company support the option of multi-module development. So you can continue development of your backend as an independent project, yet plug it into your Vaadin project as another module.

See this recent YouTube webinar, Crash Course to Official Vaadin Maven Archetypes Webinar, by a couple of people on the Vaadin team.

When learning Vaadin, I suggest you start with a throwaway project using the simple single-module archetype. Unless you are already a Maven maven, in which case, go for it.

Charting

Two options for charting: use Vaadin Charts product or roll your own.

Vaadin Charts

The Vaadin company offers a commercial product (fee required), Vaadin Charts, for producing interactive nicely-rendered charts in a Vaadin app. Try the live demo.

Vaadin Charts is basically a Vaadin (pure Java) wrapper around the highly successful JavaScript charting library project, HighCharts. So Vaadin Charts is well-worn and very advanced in its charting, as it is not brand-new.

Using Vaadin Charts means you can prepare all your data in pure Java, and package it up for display in the charts using pure Java. Vaadin takes care of getting that data to the client. Then the built-in HighCharts library automatically performs the rendering of the chart’s graphics on the user’s machines using the JavaScript engine in the user’s browser. So your server is not burdened with that rendering chore. And you are not shipping images across the network or Internet.

I am using Vaadin Charts (2.1 beta) in my own project. I highly recommend it.

My only disappointment has been the limitation of allowing only a single time zone to be applied to date-time values in my charts. All the users must share a single time zone’s representation of time zones. This is due to the fact that Highcharts is actually rendering the charts, the rendering is built in JavaScript, and JavaScript has lousy date-time support (no Joda-Time or java.time equivalents in JavaScript). You may be able to hack around this limitation with a couple of included crude time adjustment functions, but it may make your brain hurt.

The Vaadin company offers a free trial.

You might want to watch this webinar on YouTube with some of the Vaadin team talking to the boss from the Highcharts company about their combined efforts.

Roll Your Own

If you are already generating images or svg files to represent your charts, you could generate those server-side and deliver them to the client within your Vaadin app.

If you are using JavaScript to generate the images, you could conceivably build your own Vaadin add-on. You would need to learn about GWT and other technical matters, so there would be a significant learning curve and effort. See this chapter of The Book Of Vaadin. Basically, you would be creating the equivalent of the Vaadin Charts product.