Server-side Tetris with Vaadin Flow

The server-side nature of Vaadin Flow often causes concerns for those who evaluate it: The UI must be slow, as the UI logic is on the server and the “chatty” connection will bring the server to its knees. In this era, it can be hard to convince your boss or fellow engineers in the face of these preconceptions, even though the typical performance issues in Vaadin applications are exactly the same as in your existing Angular application: Slow database queries and browser rendering performance.

Testing and trying it yourself is the way to go and we have just decided to make that a bit easier by deploying a server-side Tetris game (with sources) to a simple demo environment. If you can play Tetris implemented using server-side logic, you can for sure implement your “grids and forms style” business application, as well. And, it also makes it really fun to test the capability of Vaadin Flow for your next project!

Tetris demo app

The application is an up-to-date (14.6.1) version of an older example app that we have used to demonstrate our “server push” feature. It is by no means optimised, neither for UX nor for hosting, but its purpose is to demonstrate what server latency means in 2021. Unlike typical Vaadin components that automatically compensate for the server round trip, the app brutally redraws the UI state using the HTML5 Canvas API, after each key press and twice per second.

The demo, running at tetris.demo.vaadin.com, is currently deployed on a couple of servers, which are geographically load-balanced by AWS Route 53. You should automatically get the closest server of the cluster, but if you want to see how an interactive game like this suffers from the server-side round-trip, go ahead and manually pick a server from a different continent:

• tetris-euw1.demo.vaadin.com (EU/Ireland)
• tetris-use1.demo.vaadin.com (US East/Ohio)
• tetris-usw2.demo.vaadin.com (US West/Oregon)
• tetris-apse2.demo.vaadin.com (Australia/Sydney)

The demo now also makes some trivial calculations to estimate the number of players the active node can host. The UI shows both the current CPU usage of the server and memory details, and the estimate of maximum players is calculated based on memory usage. The EC2 instances are of type t3.small, which are – well – small: 2 gigs of RAM, 1.5 gigs for the JVM. These should still be able to host thousands, or even tens of thousands, of simultaneous players, based on the memory consumption estimates. 

CPU is seldom a problem for Vaadin applications. We haven’t run scalability tests against the setup, but our educated guess is that the first bottleneck in this system would be the maximum number of sockets on the OS or JVM level. The non-optimised setup has nginx as front-proxy, in front of the actual Spring Boot application (because we had a ready-made template for it to enable https), which consumes 3x more sockets than it would need when serving directly via Java server. By fine-tuning OS variables, sockets shouldn’t be a problem either.

Interested in developing your own Vaadin Flow app? Go to start.vaadin.com to configure and download a free starter!