Yea, we’re making some breaking changes to our GraphQL queries to add pagination metadata like that. Luckily, we haven’t opened it up to external developers yet.
-
-
-
Moving toward relay style or doing my proposed way (not to spec)? Adding pagination to an existing field in graphQL is def an adventure. I would like to reduce that risk.
-
Sort of the relay style, except using the traditional total, limit, offset fields at the root with a field for the results. I like the idea of placing it in a PaginationMetaType def.pic.twitter.com/CGRCR3qY5o
-
This is exactly how I do it in my AppSync Elasticsearch resolvers. Seems totally normal/reasonable to me, as it basically mirrors what ES returns anyhow...?
-
I've done it this way and cursor based. My sense is relay went with cursors because FB has data systems that can't actually paginate. My original tweet is trying to get out of doing either method :)
End of conversation
New conversation -
-
-
Things like this are why GraphQL feels half-baked to me.
-
It just needs more time in the oven
End of conversation
New conversation -
-
-
`extensions` (adjacent to `data`) is currently in the spec for supporting stuff like this. Is that was you mean? Or are just saying there should be a better way to add to an object like that? I have used context and just formatted extensions in `formatResponse` in the past

-
Interesting. I may play with that. I wonder if directives could be used to indicate a field should belong in meta.
-
Definitely! Because you can use directives to wrap resolvers, where you can take ever return value and the path from info and apply it to some key on context, and then return that key from context in the extensions
End of conversation
New conversation -
-
-
What do you use for these screenshots?
-
Thanks!
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.