I work at GitHub and would love to hear more. Can you describe some of the data interactions that you find more convenient with the v3 API?

Everything is easier to use with rest because it's so simple it works with curl trivially.

Not just cURL; most of the time I want something from the GitHub API it's something fairly simple; using REST from Python, Go, Ruby, $preferred_language is easier than using GraphQL, too. I'm sure there are libraries out there, but hard to beat a simple "fetch me data from that URL yo".

GraphQL uses HTTP like the REST API and speaks JSON. There's no need for a library if you're comfortable sending a POST request.

It seems to me like the main friction that you and others are getting at is that GraphQL is more work to use than REST because you have to write a query. That's a fair point! Perhaps we could publish "canned" queries that are the equivalent of the most commonly used REST endpoints, or make them available for use in the API with a special param.

Yes, you need to write a query; and it's also not at all that obvious how to write a query. Let's say you want to list all repos belonging to a user or organisation, a fairly simple and common operation. I found [1] in about 30 seconds. I've been trying to do the same with GraphQL for five minutes now using the docs and GraphQL Explorer, and thus far haven't managed to get the same result.

I worked a bit with GraphQL in the past, but never all that much. Now, I'm sure I could figure it out of I sit down, read the basics of GraphQL, familiarize myself with GitHub's GraphQL schema, etc. But ... it's all a lot of effort and complex vs. the REST API; even with a solid foundation in GraphQL there's still lots more parts.

GraphQL is kind of like giving people a schema to an SQL database and telling them that's an "API"; it kind of is, but also isn't really. There's a reason almost all applications have some sort of database layer (API!) to interact with the database, rather than just writing queries on the fly whenever needed.

[1]: https://docs.github.com/en/rest/repos/repos

There's a divide between at least two types of persona here. On one side is integrators building products and features on top of the GitHub API. For these people GraphQL is arguably superior since the learning curve is manageable and in exchange for scaling it you can make an extremely specific query that returns your product's exact data requirements. The cost of writing this query is amortized over the lifetime of your integration.

On the other side are e.g. users automating some part of their GitHub workflow to save themselves time. I can see how the REST API feels like a better choice here, it's certainly simpler to get started with.

For what it's worth, here[0] is an example of using the `gh` CLI's graphql feature to print a list of all repository URLs for a given organization by login, sorted in a relatively complicated way. It's more verbose than doing this with the REST API but significantly more flexible. This could just as easily be done with curl but as others have pointed out, pagination requires a minimal level of logic to implement, so it's more convenient to use an existing helper. This output gets flushed 10 lines at a time as pages come in, making it suitable to compose with other commands using pipes.

  $ gh api graphql --paginate -f query='
    query($endCursor: String) {
      organization(login: "rails") {
        repositories(first: 10, after: $endCursor,
                     orderBy: { field: STARGAZERS, direction: DESC }
        ) {
          nodes {
            url
            stargazers { 
              totalCount
            }
          }
          pageInfo { endCursor hasNextPage } # needed for auto-pagination
        }
      }
    }' -q '.data.organization.repositories.nodes.[]'
  # output follows
  {"stargazers":{"totalCount":50643},"url":"https://github.com/rails/rails"}
  {"stargazers":{"totalCount":5298},"url":"https://github.com/rails/webpacker"}
  {"stargazers":{"totalCount":4849},"url":"https://github.com/rails/thor"}
  {"stargazers":{"totalCount":4075},"url":"https://github.com/rails/jbuilder"}
  # snip
  {"stargazers":{"totalCount":3},"url":"https://github.com/rails/hide_action"}
  {"stargazers":{"totalCount":2},"url":"https://github.com/rails/gem-buildkite-config"}
  {"stargazers":{"totalCount":2},"url":"https://github.com/rails/sqlite2_adapter"}
  {"stargazers":{"totalCount":1},"url":"https://github.com/rails/fcgi_handler"}