-
Notifications
You must be signed in to change notification settings - Fork 728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitHub v4 GraphQL API support #521
Comments
|
As noted in #1319 GraphQL However, you can't mix and match - REST API requires numeric ids to reference objects, while GraphQL requires 😡 😡 This means that when we start implementing and moving to GraphQL there will need to be some way to convert objects returned with events to their GraphQL equivalents. On the plus side, GraphQL supports renaming of returned fields, so we could force GraphQL queries to return their |
Breaking changes do occur in GraphQL API, but they are rare: Non-breaking changes happen much more often: |
has there been any further thought about this? i have a feeling that access to dependabot alerts are only going to be available via graphql. i guess there's nothing that would currently prevent me from using that endpoint as well... |
Yeah, there's a bunch of underlying work to be done here. But this might be a case where we start with something closer to the raw API and then make it more Java friendly over time. What do you have in mind? |
IIUC a key advantage of GraphQL is that you can generate type-safe client interfaces from schema. That sounds like a different library altogether, though there might be a bit of overlap (or at least a factored-out common library) to deal with authentication. |
Just generating the schema is not enough. Authentication, rate limits, retrying, stable api that compensates for bugs and backward compatibility. Also GraphQL offers more data but requires the client to specify the fields they want. Which means everyone can generate queries for exactly the data they need, but if they are not sure of what data is needed at query time (as with Jenkins, with its plugins), they have to request all possible data. Which defeats one of the key features of GraphQL. Shrug. |
Perhaps; depends on what code is constructing the query and for what purpose. If it is exposing some sort of GH object for other unknown plugins to inspect in arbitrary ways, then yes this would defeat a key aspect of GraphQL. |
FWIW, in Quarkus GitHub App, I expose both the GitHub REST API using this very API and a low level GraphQL client. |
PurposeThe purpose of using GraphQL is resolving the same information required by plugins but using GraphQL instead of the GitHub search API (which is inefficient). You don't need a general purpose "plugins request whatever they want" kind of client. You simply need to provide the same metadata currently provided for plugins but using GraphQL instead of the GitHub search API. Jervis has its own clientJervis has its own client specifically for GraphQL because this library was not up to the task. I would recommend either using it or relying on something similar in concept.
ExampleQuery all branches and tags for jenkinsci/jenkins and resolve latest contributor metadata for each. samrocketman/jervis#133 (comment) In the above code example you can change the following to get JenkinsCI repo. -String githubOwner = 'samrocketman'
-String githubRepo = 'jervis'
+String githubOwner = 'jenkinsci'
+String githubRepo = 'jenkins' This resolves the jenkinsci/jenkins Git metadata in under 10 seconds (the GH api library resolves the same information in a couple of hours using over 4000 API requests). |
The v4 API provides a much more customizable API based on GraphQL. It is out of scope for this library to provide a generalized API the fully leverages the power of GraphQL, but having some way to construct queries for trees of items would be useful.
https://developer.github.com/v4/
The text was updated successfully, but these errors were encountered: