Improving Backend Performance Part 1/3: Lazy Loading in Vaadin Apps

If you have a table or data grid with, say, more than a few hundred rows in it, you should be using lazy loading. This is especially true in the case of Vaadin's Grid component which makes it very easy to show data from an array or collection of POJOs. In this article, I'll show you how easy it is to take advantage of Spring Boot data to easily implement lazy loading in Vaadin Flow applications. You can find a video version of this topic if you prefer:

Understanding the Example Application

Let's start with a previous Vaadin Flow application that I developed from scratch in a previous article. In short, we have a Spring Boot application that connects to a MariaDB instance using Hibernate/JPA to read data about books. There is a JPA Entity called Book, a Spring repository called BookRepository, and a service class called BookService. This is a common pattern you might find in the industry. The web user interface (UI) is implemented with Vaadin Flow in a class called BooksView.

Understanding the Problem to Solve

Let's say the application has been in production for some time and there are 50.000 books in the database. With this rather modest number of rows in a table, we can easily run out of memory with the default JVM configuration of a Spring Boot application.

If we use the findAll() method to get all the books from the database and show them in a Grid, every time a view is requested, a new copy of the data is kept in memory. With 50.000 books in the example application, this means that once there are two views opened in a browser (two users or one user with two tabs showing the view), we'll get an out-of-memory error. Even if we increased the JVM memory to zillions of bytes, we'd find that loading the books takes too long for a good user experience.

Any time we think a table could contain more than, say, 100 rows, we should stop using the findAll() method and consider the lazy loading technique. Lazy loading allows us to query only part of the data set from a database. A screen will rarely be able to show 50.000 rows, so it's a waste of resources to load all the 50.000 books when we can show only a few.

Fixing the Backend

In Spring Data, the findAll() method is overloaded with a version that allows us to specify a slice or "page" of data. JPA uses this information to build the underlying SQL query using the LIMIT and OFFSET clauses. Here's the change we need in the service class:

@Service
public class BookService {

    private final BookRepository repository;

    public BookService(BookRepository repository) {
        this.repository = repository;
    }

    public Stream<Book> findAll(int page, int pageSize) {
        return repository.findAll(PageRequest.of(page, pageSize)).stream();
    }

}

Fixing the Grid

The Grid component overloads the method setItems() with a version that allows us to pass the information of the page of the Grid that is currently visualized in the browser according to the position of the scroll bar. The change is simple:

@Route("")
public class BooksView extends VerticalLayout {

    public BooksView(BookService service) {
        var grid = new Grid<Book>();
        ...

        grid.setItems(query ->
                service.findAll(query.getPage(), query.getPageSize()));

        ...
    }

}

Testing the Solution

With these simple changes, we can try the application and check that it certainly loads the data much faster and that we can open many tabs without crashing the application. We could also enable SQL query login by adding the following to the application.properties file:

spring.jpa.show-sql=true

If we scroll through the data in the browser, we should see the queries in the server's log.