I really like the lambda concept behind dgraph and was very fond to know I could provide my own custom lambda server. On the other hand I really like where DGraph Cloud is heading and would really like to use it once we need a production ready system. It would alleviate a lot of work especially at the start.
As I found out on the latest Community Call there is no way to specify a custom lambda server for DGraph Cloud.
Feature Request
Allow to specify a custom lambda server for DGraph Cloud.
If you could consider this feature request, I would be very pleased.
Thank you.
I would like a WASM based approach myself - where dgraph cloud (or self hosted) accepted a WASM binary (or a pointer to a WASM binary on S3 maybe). That way we could run any language we want in a sandboxed way.
Mostly I found that struggling to do what I need to do in javascript is doable but better in almost any other language (read: go fanboy I guess).
RedPanda (a contemporary kafka clone) took this approach and is highlighting javascript as a transform language, but will accept any language created WASM (as far as I understand).
Hi @Schartey We have custom resolvers which could solve this problem. Can you explore your use case with custom directive and let us know your experience. We would love to know more about your use case and see how can we help you in the best possible way.
For your reference here are the docs available on custom directive https://dgraph.io/docs/graphql/custom/directive/
Thanks for your response. I have the following missing features or problems with custom approach:
The schema becomes cluttered:
How I understand it, I would have to at least declare the same url, httpMethod and forwardHeaders on each field, query and mutation that uses the lambda server.
I would also have to define a body/graphql for each field, query, mutation:
From the docs I think not specifying the body/graphql will not send any data to the custom server. Using Lambda I’m used to a standard data structure and representation. Having to write a body/graphql everytime becomes cumbersome and also clutters the schema.
No lambdaOnMutate alternative
Please correct me if I am wrong at any point, but I think the only issue without alternative is lambdaOnMutate. Yet the other points are valid too imo.
I don’t have any specific use case. When I tested the JavaScript-Lambda server I had issues with building dependencies with webpack (firebase auth) and as suggested in Slash Lambda with Packages - #9 by amaster507 it is not really friendly to use imo. Also I just like to write my backends in other languages than Javascript.
I think the WASM approach suggested by @iluminae would also be interesting as it makes sure to run queries close to the database.
The only alternative for me currently would be to generate a lambda script from the schema and auto-upload it to the cloud that directly forwards requests to the custom lambda server.