JHipster Custom Pagination with Spring Data Pageable

Problem: Pagination feels stuck in JHipster

When you scaffold a JHipster monolith, the generated CRUD UI already supports paging, but the default behaviour often feels too generic for real‑world data sets, especially when the underlying table contains thousands of rows or when you need to filter before pagination.

Thesis: Customizing pagination with Spring's Pageable gives precise control without rewriting code

By customizing the Spring Data JPA Pageable contract you can shape exactly how pages are fetched, apply precise sort orders, control eager fetching, and avoid costly N+1 queries, all without modifying the client‑side UI code.

How JHipster handles pagination out of the box

JHipster generates repository interfaces that extend PagingAndSortingRepository or JpaRepository. Both provide a findAll(Pageable pageable) method that Spring translates to a SQL LIMIT and OFFSET clause, allowing the framework to slice results on the database side.

Why custom pagination matters

In many applications you need to apply additional filters, join multiple tables, or restrict the projection before the database limits the rows. Relying solely on the default findAll method can cause the database to return the entire table, leading to high memory usage and slow response times.

Step 1: Define a custom repository interface

Create a custom repository interface in the same package as the generated repository. Name it RepositoryCustom and declare a method that accepts a Pageable parameter, for example findAllCustom(Pageable pageable).

Step 2: Implement the repository

Implement the interface in a class annotated with @Repository. Inject the EntityManager via @PersistenceContext and use it to build a query that respects the Pageable offset and size. Adding @EntityGraph on the query helps avoid N+1 fetching when you need to join related entities.

Step 3: Wire the custom implementation via JHipster gateway

JHipster’s entity gateway looks for a bean named Repository. To use your custom implementation, name the class RepositoryImpl and place it in the same package. Then add the repository package configuration in application.yml so Spring discovers the bean automatically.

Trade‑off: Bigger page sizes can exhaust memory

Increasing the default page size (via spring.data.jpa.properties.hibernate.default_fetch_size or spring.data-rest.pageable.default-page-size) improves UI smoothness but may load large result sets into the JVM. In production, a size above a few thousand rows can trigger an OutOfMemoryError, especially when the data volume grows unexpectedly. Always cap the size according to expected traffic and monitor heap usage.

Verification checklist

• Run the application and open Swagger UI (e.g., /swagger-ui.html). Call GET /api/customers?page=0&size=20&sort=name,asc.
• Confirm the response includes pagination headers X-Total-Count and Content-Range, and that the JSON array length matches the requested page size.
• Enable SQL logging with spring.sql.show=true and inspect the generated statement; it should contain LIMIT and OFFSET clauses, not a full SELECT * FROM customer.
• Check the application logs for any warnings about excessive result set size or memory pressure; if you see OutOfMemoryError, reduce the page size or add a fetch join to limit the data retrieved.
• Verify that the custom repository method is invoked by adding a log statement or using a debugger; the log should show the offset and limit values used in the query.

Actionable closing: implement and test

To finish, add the custom interface and implementation, rebuild the project with ./mvnw clean install, and restart the service. Then run the verification steps above. If the pagination behaves correctly, you have successfully customized JHipster pagination; otherwise, revisit the repository naming convention and the SQL log to ensure the query respects the Pageable parameters.