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.
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.
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.
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