Feature Request: Allow external generic http(s) webhooks in Dgraph

Lambda resolver is my favorite feature of Dgraph. We can implement application logic without even needing a separate server.

The only one missing feature is to be able to handle webhoook events from external sources.

Since there is already a .addWebHookResolvers() method

I suggest we handle an http request event just like other add/update/delete webhook
then we might call something like this

self.addWebHookResolvers({
    "Http.get": httpGetWebhook,
    "Http.post": httpPostWebhook,
    "Http.delete": httpDeleteWebhook,
})

Or we can handle this with a dedicated method and and resolvers by url paths

self.addHttpWebHookResolvers({
  "/": httpRootWebhook,
  "/stripe": httpStripeWebhook,
  "/somepath/:someparam": httpSomepathWebhook
})

I think lambda server should stay in internal network, and not be exposed to the outside world.
I would deploy a separate http server for this (just handling HTTP requests and calling graphql/dql), as I understand you do not need any lamba server functionality for this.

1 Like

I would deploy a separate http server for this

That’s what I’m doing right now, I have a private lambda mutation that accept http request object sent from a separate http server.

This feature request is targeted at the Dgraph Cloud, it doesn’t necessarily needs to be implemented in lambda server. Dgraph Cloud could have another http server that forwards requests to lambda server.

This would make a Dgraph Cloud almost an all-in-one serverless solution.

I don’t think that would be the purpose of a lambda. Just in case you’re not aware, you can query external sources with the @custom directive:

https://dgraph.io/docs/graphql/custom/directive/

J

This isn’t about querying external sources, but listening for external requests (push not pull). Webhooks would let you authorize an application to call lambda resolvers on certain events.

Gotcha. Someone from Dgraph should respond to this. As far as I know you can still run fetch in the lambadas fwi.

J

I think there are two separate issues here:

  1. Webhook support
  2. “External” Lambda server.

On the second point, I echo @miko 's thoughts: A lambda server should stay in the internal network.

On the first point, I am marking this as an official feature request - since this is clearly a good idea. It will go into the backlog and @hardik will prioritize it.

I will also edit the post to make clear that the feature desired is webhook management, not lambda servers

2 Likes