Hacker News Reader

Comment by stevebmark | Hacker News Reader

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

View on HN

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.

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.

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
          }
        }
      }
    }

Reply on news.ycombinator.com