Feedback on GraphQL support
See original GitHub issue#472 introduced GraphQL support through context.github.query
. It’ll likely take a while to figure out patterns for efficiently building Probot apps with GraphQL. Your feedback is an important part of that. Feel free to comment here with ideas, friction, or suggestions on how we can make building Probot apps with GraphQL an amazing experience.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:8 (3 by maintainers)
Top Results From Across the Web
GraphQL Support
Private Slack channel with your team and Apollo's; Product readiness reviews ; 24×7×365 technical support; Guaranteed response time ; Identify the right project ......
Read more >REST vs. GraphQL: A Critical Review | Good API - Medium
Choosing GraphQL gives you easy to design and amazing to consume API. It also rewards you with effortless consistency between the APIs. By...
Read more >Feedback Driven API exploration at the service of GraphQL ...
A way to achieve that is through feedback-driven API exploration. The global idea is to prioritize requests by inferring which answer may allow ......
Read more >GraphQL Best Practices
A query language for your API — GraphQL provides a complete description of the data in your API, gives clients the power to...
Read more >GraphQL feedback - Support - Stardog Community
Just some quick feedback on the new GraphQL feature. It doesn't look like “stardog grapnel…” has made it into the bash completion.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This pattern is working really well for me… except when it doesn’t. I’ve noticed that some objects have “odd”
html_url
. One example isPullRequestReview
:https://github.com/<owner>/<repo>/pull/28#pullrequestreview-110303313
The fragment identifier is ignored when looking up the resource id, so you instead get the
PullRequest
global ID. I considered manually constructing the IDs (they are just Base64), but the version is volatile, I think.Instead I fetched the PullRequestReview id by looking it up:
I only grab the first 5 as that is enough for me. You could subsequently loop through those to find the matching one.
Maybe you could add support for
graphql-bindings
, I genuinely enjoy using these in my other GraphQL projects. And there’s already an existing one made especially for Github! 🎉