Nested paginators

[coatezy]

Hi all,

I'd like to implement nested paginated fields to mitigate performance issues. I'm implementing a simple notes app driven by a GraphQL API to test this. I have come up with an approach but I'd like to understand if I'm on the right track. Let's assume we have the following query whereby a notebook is fetched along with all associated notes, there is no limit on the number of notes that can be created so this list could be empty or have an infinite number of notes. I'm naturally worried about the size of the payload and the time it takes to return the result if a large number of notes exist.

query FetchNotebook($id: ID!) {
    notebook(id: $id) {
        id
        name
        notes {
            id
            body   
        }
    }
}

What I'd like to do is describe my Notebook type in such a way that the notes field can be paginated, for example:

query FetchNotebook($id: ID!) {
    notebook(id: $id) {
        id
        name
        notes(limit: 20, page: 1) {
            data {
                id
                notebook {
                    id
                    name
                }
            }
        }
    }
}

I didn't find any documentation or examples on how to do this so I came up with the following approach:

<?php

declare(strict_types=1);

namespace App\GraphQL\Types;

use App\Models\Notebook;
use GraphQL;
use GraphQL\Type\Definition\Type;
use Rebing\GraphQL\Support\Type as GraphQLType;

class NotebookType extends GraphQLType
{
    protected $attributes = [
        'name' => 'Notebook',
        'description' => 'A notebook',
        'model' => Notebook::class,
    ];

    protected function resolveNotesField($root, $args)
    {
        return $root->notes()->paginate($args['limit'], ['*'], 'page', $args['page']);
    }

    public function fields(): array
    {
        return [
            'id' => [
                'type' => Type::nonNull(Type::id()),
            ],
            'name' => [
                'type' => Type::nonNull(Type::string()),
            ],
            'archived_at' => [
                'type' => GraphQL::type('DateTimeTz'),
            ],
            'created_at' => [
                'type' => GraphQL::type('DateTimeTz'),
            ],
            'archived' => [
                'type' => Type::nonNull(Type::boolean()),
            ],
            'notes' => [
                'type' => GraphQL::paginate('Note'),
                'args'          => [
                    'limit' => [
                        'name' => 'limit',
                        'type' => Type::int(),
                        'rules' => ['required', 'numeric', 'min:1', 'max:20'],
                    ],
                    'page' => [
                        'name' => 'page',
                        'type' => Type::int(),
                    ],
                 ],
            ]
        ];
    }
}

<?php

declare(strict_types=1);

namespace App\GraphQL\Types;

use App\Models\Note;
use GraphQL;
use GraphQL\Type\Definition\Type;
use Rebing\GraphQL\Support\Type as GraphQLType;

class NoteType extends GraphQLType
{
    protected $attributes = [
        'name' => 'Note',
        'description' => 'A note',
        'model' => Note::class,
    ];

    public function fields(): array
    {
        return [
            'id' => [
                'type' => Type::nonNull(Type::id()),
            ],
            'body' => [
                'type' => Type::nonNull(Type::string()),
            ],
            'notebook' => [
                'name' => 'notebook',
                'type' => GraphQL::type('Notebook'),
            ]
        ];
    }
}

Although this works, it doesn't feel right as I cannot leverage things such as SelectFields, which again triggers my performance anxiety, I also hit an error when constructing a query whereby each note returns its parent notebook and that notebook returns its notes.

I'd be interested to know if my approach is correct or if it can be tackled in another way. Happy to log the error I experience once I know if I'm on the right track or not. 😄

[mfn]

Short: IMHO, this is fine.

it doesn't feel right as I cannot leverage things such as SelectFields

It works for many but not all cases, so not using it is "totally fine ™️". In fact, project can have complex relations and not using SelectFields at all but just custom resolver logic combined with something like https://www.google.com/search?hl=en&q=graphql+dataloader+php and are doing excellent in terms of performance.

infinite number of notes

I'd say this part and if you're using offset-based pagination, this is where you will run into performance issues from DB side at some point (dunno, 50k? 100k? 🤷‍♀️).

I also hit an error when constructing a query whereby each note returns its parent notebook and that notebook returns its notes.

if that includes pagination logic on multiple notebook in a single GraphQL, you will also run into a n+1 problem in that pagination has to run separately for reach notebook; that might also become a performance issue.

I'm happy to give more feedback if you want, but for that I suggest you publish a public project with some sample code ready-to-run locally and some instruction what to check specifically.

[coatezy]

Thanks for the detailed reply @mfn! All really useful and good to know I was on the right track and not missed anything obvious. I parked this while waiting for a reply as I was just doing this a little pet project. I'm going to pick this back up again and will be sure to post a working example if I have any more questions. 👍

Thanks again!