Support for Page based pagination with a total page and total elements count

[Daniel-Fermoselle]

Hello everyone, I am trying to build pagination with spring graphql. I noticed that on graphql specification (https://graphql.org/learn/pagination/#end-of-list-counts-and-connections) a totalCount property is defined to allow us to know the total number of elements stored and not only the ones returned in the query. From what I saw until now I think spring-graphql doesn't support that. Any timeline for this feature to exists or is it not at all planned?

Kind regards

Daniel Fermoselle

[RhysXia]

Is there any progress on this issue?

[bclozel]

I don't see the totalCount field being mentioned in the official relay spec nor in the graphql-java Connection type that we are implementing.

Can you elaborate?

[RhysXia]

@bclozel In the spec, pageInfo and edges are required fields, but the spec also mentioned that you can add additional fields to Connection. I think totalCount is such a field. In actual use, we often need totalCount as the basis for calculating the number of pages. Currently, spring-graphql does not provide the ability to inject additional fields into Connection.

In the spec, you can see this introduction: They may have additional fields related to the connection, as the schema designer sees fit.

So, can spring-graphql provide the ability to customize Connection?

[andimarek]

side comment: while it is valid to add a totalCount to a connection type from a schema design aspect it is often problematic. Either it is very expensive or even impossible to have a total count.

[RhysXia]

@andimarek I think the key to the matter is whether Connection supports expansion to meet custom needs in various situations. As for whether totalCount should be added, it is the user's own business.

[wsaca]

In our case, we use a custom connection to add a shortcut to the nodes that are inside the edges, many times the cursor information is not needed.

[rstoyanchev]

Pagination support has different parts:

1. ConnectionTypeDefinitionConfigurer adds ~Connection types to the schema.
2. graphql.relay.* models the spec.
3. ConnectionAdapters adapt pagination types to graphql.relay.Connection.

For 1), we can introduce protected methods to make it customizeable.
For 2), you can extend those types as needed.
For 3), we can add a method in ConnectionAdapter to customize the creation of PageInfo given the first and last edges and the "container" of data (the underlying pagination object) that was returned by the controller (or any other data fetcher).

A key question for everyone here. What pagination mechanism do you use? Spring Data provides Window and Slice with offset or keyset positions, and that allows us to provide built-in ConnectionAdapter implementations so you can use those in a controller without having to adapt to Connection.

For any other way of paginating, you need to provide a ConnectionAdapter and a CursorStrategy. Or alternatively, return graphql.relay.Connection directly, in which case we wouldn't even be involved. This is why it's important to clarify how you paginate, and what you plan to return from controller methods.

[GoncaloPT]

Pagination support has different parts:

1. ConnectionTypeDefinitionConfigurer adds ~Connection types to the schema.
2. graphql.relay.* models the spec.
3. ConnectionAdapters adapt pagination types to graphql.relay.Connection.

For 1), we can introduce protected methods to make it customizeable. For 2), you can extend those types as needed. For 3), we can add a method in ConnectionAdapter to customize the creation of PageInfo given the first and last edges and the "container" of data (the underlying pagination object) that was returned by the controller (or any other data fetcher).

A key question for everyone here. What pagination mechanism do you use? Spring Data provides Window and Slice with offset or keyset positions, and that allows us to provide built-in ConnectionAdapter implementations so you can use those in a controller without having to adapt to Connection.

For any other way of paginating, you need to provide a ConnectionAdapter and a CursorStrategy. Or alternatively, return graphql.relay.Connection directly, in which case we wouldn't even be involved. This is why it's important to clarify how you paginate, and what you plan to return from controller methods.

We use Page. From our ( me and @Daniel-Fermoselle ) perspective, it would be nice to add the same behavior we have with the ~Connection for a ~Page. This would expect a Page instance to be returned instead of a Window.
With this page, we could provide the caller the count, which is mandatory when you implement a offset-based pagination, in which you normally have to inform about the total count and current page.

In a side note, we have started the implementation of this option on a library since we need this for a feature we need to deliver soon. We can, therefore, make this code a contribution for the project if you find it useful.