Discussion on implementing graphql connections correctly

[xoldd]

@EshaanAgg I'm going to outline the biggest flaw with your approach. You are fetching every single user that is assigned to a tag in a single db request. This completely goes against the concept of pagination. Pagination isn't only for providing data in little chunks to client, it's also to get data in little chunks from the database.

Now flaws regarding resolver arguments:-

1. Either argument first or last must be provided. If they're not the query should fail.
2. If both first and last are provided, the query should fail, there's no use case currently where both the arguments should be accepted in a single query.
3. Arguments work in pair here. first/after are a pair and last/before are a pair. Argument after is optional, but if it is provided first must also be provided. Clients cannot provide before with first. Argument before is optional, but if it is provided last must also be provided. Clients cannot provide after with last.
4. after and before are cursors. Cursors are base64 encoded strings that contain information to uniquely identify an edge in a connection. Edge here would be the user edge(in graphql schema). Primary id(mongodb _id) can be used as a cursor, though usually it's a combination of primary id and createdAt field.
5. For getting information about hasNextPage and hasPreviousPage(depending upon whether you're forward or backward paginating), you can increase the number of items you're fetching from database by 1. If that extra item is fetched too, it means you have a next page of data(hasNextPage is true). Whether you're forward or backward paginating you're always going to have information about hasPreviousPage, because you're literally going to pass in a cursor which represents an object which will exist.

For sometime in the future when a good validation system is decided for resolver arguments:- You're not checking arguments first and last for minimum/maximum. The client cannot just query with 0 as the value for either first or last. Accordingly, client cannot query with a big integer like 999999 as the value for either first or last. Idk if the custom graphql scalar PositiveInt includes 0 as a positive integer, but if it does the query should fail. first and last dictate how many items are returned in a single query, their values should be constrained. The client cannot just ask to get 0 items or 99999 items in a single request.

This validation system would also account for many of steps I mentioned above. I just thought the min/max constraints are not something I should include in those steps because they're not related to the correct implemention of connection itself.

[EshaanAgg]

Got it @xoldyckk. I see the problems that you have outlined in my approach, and the need for the all validations that you have outlined.

I will start working on correcting the same.

[EshaanAgg]

Also, do you think we should move to using base64 cursors with both createdAt and mongo id, or current implementation of just using primary ids is fine?

[EshaanAgg]

Yes you are right. But I think it makes more sense to keep Mongo IDs as our cursors (and then use them to sort objects as well) as they have a feasible tangible meaning (for example, the client can use them directly to query for user details etc.), and abstracting away that meaning without any reason seems pointless.

[palisadoes]

We should stick with the defaults. If we change the Graphql implementation there is no guarantee it will support this.

We need something that abstracts from the underlying db

[xoldd]

Yes you are right. But I think it makes more sense to keep Mongo IDs as our cursors (and then use them to sort objects as well) as they have a feasible tangible meaning (for example, the client can use them directly to query for user details etc.), and abstracting away that meaning without any reason seems pointless.

Cursors are different than ids. Ids can be used as cursors, but a cursor should never be used as an id. Like on the client side, a cursor should never be used to uniquely identify an object, for that the clients should use the object's id field. Cursors are only used to uniquely identify a connection edge.

[palisadoes]

Are cursors only unique to the edge or the entire query result?

[xoldd]

Are cursors only unique to the edge or the entire query result?

They're unique to a single edge. Read this for more explanation:-
https://andrewingram.net/posts/demystifying-graphql-connections