[stevebmark]

edges and node come from Relay, not from the core GraphQL spec. They're just one way to do pagination.

I like edges and node, it gives you a place to encode information about the relationship between the two objects, if you want to. And if all your endpoints standardize on this Relay pagination, you get standard cursor/offset fetching, along with the option to add relationship metadata in the future if you want, without breaking your schema or clients.

edit: the page you linked to has similar rate limiting behavior for both REST and GraphQL lol

[andrewingram]

Technically the spec is part of GraphQL itself now, but an optional recommendation, not something you’re obliged to do.

That said, like you I am a fan.

It’s a pretty defensible pattern, more here for those interested: https://andrewingram.net/posts/demystifying-graphql-connecti...

The overall verbosity of a GraphQL queue tends to not be a huge issue either, because in practice individual components are only concerning themselves with small subsets of it (i.e fragments). I’m a firm believer that people will have a better time with GraphQL if they adopt Relay’s bottom-up fragment-oriented pattern, rather than a top-down query-oriented pattern - which you often see in codebases by people who’ve never heard of Relay.

[Aeolun]

Also by people that have heard of relay but already have an existing codebase. It’s not something that’s very simple to adopt out of hand.

[wyattjoh]

Seconded. I feel that the pagination style that Relay offers is typically better than 99% of the custom pagination implementations out there. There's no reason why the cursor impl can just do limit/skip under the hood (if that's what you want to do), but it unlocks you to change that to cursor based _easily_.

    {
      products(first: 3) {
        pageInfo {
          hasNextPage
          endCursor
        }
        edges {
          cursor
          node {
            handle
          }
        }
      }
    }