It’s been 7 years since we deployed our first Vaadin app for production. The whole process has been more than interesting. We developed the application according to an analysis (several modules for the agenda in the field of local government) based on a verbal assignment. The customer started testing on our server and after 2 months found only 3 bugs and requested 2 modifications beyond the original brief. Once implemented, we installed at the customer’s site. The application started for the first time and is still running :-).
SW stack we have used:
- SpringBoot 1.5.x
- Vaadin 8.x
- MongoDB 3.x
- ElasticSearch 1.x
- Java 8 on Apache Tomcat 8
Even after 7 years, the application is still running in the same configuration, we only updated the main versions of the individual software packages (there was no budget for doing more). After a successful deployment, the customer started using the application and apart from one small issue, we have not heard from them for more than a year. In fact, we thought the application was not being used much. We were even more surprised when we found out that the application was actively being used and the customer had not heard back as he had no problem with the application.
Lessons we learned (from this and another Vaadin projects):
- quality of the initial development version was excellent. Individual parts/modules were working as expected and no runtime memory leaks or whatever. We were actually very surprised at how stable Vaadin is. In Vaadin everything is a Java object, so it's easy to avoid any typos and other inconsistencies.
- we haven't used any SW testing tool. The entire application has been and still is, tested manually only. Having Java static typing, and no weak bindings like REST endpoints, surprisingly we have had very minimal issues. Most of them were caught by developers during initial development.
- the application was created in the style of a “modular monolith”. The entire application consists of 6 modules, we split those inside the SpringBoot application using Java packages in the same structure inside. We just followed some conventions we defined. (btw. have you heard about a recent Spring Modulith ?)
- before being involved in Vaadin, we used SpringBoot MVC with Thymeleaf templating. It was nice but not flexible for large forms with complex logic, with different buttons, fields visible only under some conditions, etc. We also used Angular, and many REST endpoints but it slowly became very difficult to maintain and synchronize the front-end development with the backend.
- we still do updates every year. We are adding new modules or enhancing existing ones. If you don't see a code for around one year, it's generally not easy to get into it. But it's not the case with the Vaadin. It's very easy to locate the form and button and it’s an onClick listener. Static typing of Java helps here a lot.
Do we still enjoy it?
We are running many Vaadin apps in production since that first one. If there are not any specific requirements we use a “modular monolith” concept, which fits our stack best. We pack applications as WAR and deploy them under Apache Tomcat. And yes, we enjoy the development process. It’s very straightforward and Vaadin and SpringBoot fit together well.
If you are successful enough, you will slowly switch the app into long time maintenance mode. From time to time a customer comes back and requests some changes or additions. Keeping the entire stack small helps here a lot. It's easy to find the place that needs to be updated and see all in-place relationships/dependencies, SpringData provides data to our Vaddin components directly, and SpringSecurity covers all logins/permissions requirements. Everything is under your control.
Are you still with me? Nice. If you are interested in details and can get a whole idea of how you can use Vaadin in your new or existing projects, you are welcome to take part in this Udemy Course: “FullStack Vaadin (14–23+) — Practical Solutions”