I guess a mutation is the best you can do

last I checked the graphql spec was intentionally vague about how subscriptions get delivered

I don't even know what lacinia has to handle subscriptions by default, but once you get low level enough with lacinia you can use whatever you want for subscriptions (at work we have it setup to write to a core.async), so you could have a subscription that takes a url as an argument and then posts data to the url

Indeed, like hiredman said it's up to you. So you can use a subscription. https://github.com/Ancient-Dragon/dgs-sse-subscriptions-backend-example is a Netflix DGS example that might help.

Right yea, I was thinking more of the registration step, like if there is a good way to re-use the subscription type inside of a mutation or something. It looks like no.

E.g.,

mutation {
   registerWebhook(query: subscription { employeesMutated (...) } ) { id }
}

So the query would need to be passed as a string or plucked apart as separate fields

We have websocket subscriptions working now, just thinking about the best API possible for supporting webhooks since customers are asking for that now

not sure what you mean?

like a subscription can take arguments (the url to push to, whatever)

Yea, but normally that is done via a websocket individual message, which wouldn't make sense for registering a webhook, you'd probably want a simple 'POST' request

Here is how Shopify does it, for example: https://shopify.dev/api/admin-graphql/2022-04/mutations/webhookSubscriptionCreate

But I know what you mean - you can still do it that way. Though it doesn't provide an obvious way to unregister the webhook.

yeah, all our subscriptions return a subscription id, and we have a separate unsubscribe mutation

Ah I see. What transport are you guys using? Websocket?

the big difference between websockets and webhooks for subscriptions is going to be life times of subscriptions, for websockets the subscription is kind of dead once the connection is dead

http://socket.io so sort of websockets

websockets+long polling

Ah, cool

so it is reasonable to assume a subscription over websockets wouldn't outlast a server

but the life time on webhooks could get weird if you are driving them via lacinia

we were going to create a new service to handle those

yeah, I just mean you won't be able to count on any internal state in lacinia to keep driving the webhooks

right

Webhook is not the same as subscription. For webhooks I indeed would expect a mutation to manage them. The actual webhook is out of scope for GraphQL.

I mis read the initial question, sorry.