Webhooks and subscribing to a query via GraphQL


Can webhooks be graphql-ified any time soon? Currently it appears developers who want to query or mutate with GraphQL but also want data pushed to them from Github are required to write separate code that handles the old/traditional Github formatted responses. :frowning:

In light of the RFC to implement subscriptions in GraphQL https://github.com/facebook/graphql/pull/267 and the existence of a Node library that does this quite well already, might it be possible that we too can have subscriptions? :slight_smile:


We had a spike back in November doing this as a proof-of-concept. I suspect once things around subscriptions get codified we will very much implement them. We also think the giant blob of mostly meaningless information sent from a webhook is too much!


Hi @gjtorikian, :wave: I wanted to bump this and see if any more thought has been put into subscriptions. That PR was merged in March and they are looking pretty solid in the spec. Also, is the current thought that subscriptions will be webhook based?


We haven’t given much thought, to be honest. The team is meeting in a couple of weeks to discuss webhook improvements in general (among other things), and I’ll make sure to get this on the agenda.


Awesome. We would really like to move more of our stuff over to the GraphQL API; however, we are hesitant to invest too much until we know how subscriptions will work.


Any update on subscriptions? Will you implement event-based subscriptions only or do you plan to implement Live Queries, too?


Hey @gr2m,

This isn’t something we’re going to be focusing on in the short term.

Out of curiosity, what are some use cases that you see GraphQL live queries or subscriptions solving?


This isn’t something we’re going to be focusing on in the short term

Bummers! I’m very excited for it

what are some use cases that you see GraphQL live queries or subscriptions solving

All current use cases I have would be nicely covered by event-based subscriptions. Live queries would make it simpler to build live-updating dashboard-esque applications where I’d pull lots of data from different entities. I’m sure I could achieve the same thing with event-based subscriptions, it would be more work on my side though.


@d12 & @gjtorikian :wave:

A big thing for us is that we are currently translating between REST webhooks and GraphQL data shapes. We have views that hydrate their data from GraphQL, but then to keep them up to date in realtime we have to have a webhook receiver who’s sole purpose is to receive GitHub webhooks (in REST form), translate the data into the GraphQL schema, and then republish them over our own websockets. Every time we build something new on GraphQL, we have to build the translation layer for the webhooks. It is not the end of the world, but it is quite error prone and fairly burdensome for your integrators.

Also, it makes it hard for some of your integrators to know how to invest in the GitHub ecosystem right now. It appears as though GraphQL is the recommended path going forward; however, if we do use GraphQL, we end up needing things like our translator to fill in the gaps. It is one thing for it to be an interim thing, but it is discouraging to hear there is no plan to make GraphQL a stand alone solution for integrators.

Hopefully that’s helpful. I know we probably use the GitHub GraphQL API in some unique ways as compared to other integrators. It is definitely a pain point we feel though.


Thanks @burtonjc, I see how live queries and subscriptions would help with developing applications like this. I’ve taken note in our issue tracker, if anything changes I’ll be sure to ping you here!


Sounds good, thank you.


Bumping to make sure that this stays on the radar. As always GraphQL allows to reduce the amount of data that is sent and the number of requests that are needed. I have a bot subscribing to many webhook events but for each of them most of the events are discarded (I filter by action). Being able to filter more precisely would help my bot run well beyond Heroku’s free-tier limits (in particular not wake it up for events it doesn’t care about).
Furthermore, most of the time I need to do follow-up queries to fetch the additional data I need because even though the webhook has sent me quite a big chunk of data, I haven’t the one that I need.