Why Javascript for dgraph-lambda?

I was wondering why you went for javascript for dgraph-lambda? Couldn’t you just allow implementation of custom resolvers in golang?

Javascript just makes cross-platform-shipping of lambda functionality a real pain.

I think there are two main reasons:

  1. most of the users of GraphQL are frontend developers, and they do know javascript
  2. there are some advantages of using interpreted languages: you can store your logic as a data (in dgraph itself) and easily update it without recompilation/deployment.

Still, I would prefer lua as a script language.

You can check out my take on the lambda solution: https://github.com/miko/dgraph-luambda
There are examples of custom resolvers both in golang and lua.

Note: it is not production ready, just proof of concept.

3 Likes

Can someone of the team maybe step in and explain the reasoning behind this?

Dgraph is shipped cross-plattform but dgraph-lambda is currently not. Can we expect to have a cross-plattform lambda server at some time?

Hi @maaft, thanks for the question.

Any http server can be used as a lambda server, as long as it honors a very simple http endpoint interface.

We chose Javascript for the initial implementation, and the version that Is used for slash graphql for a few reasons

  • maximize developer reach, especially to the front end crowd
  • ability to lock down what the language can do (I don’t need someone to attempt to run a bot net from a lambda). Node provides this via vm isolates and contexts. As an example, fetch is the only way to do any IO from dgraph lambda.

The dgraph-lambda project just takes a function, wraps it in all this security context, and serves it as an http endpoint. Its a fairly thin wrapper. Dgraph-lambda can be launched via docker, so that may provide the cross platform nature you are looking for.

Tejas

1 Like

Okay, thank you for the explanation.

I think I’ll have to read a bit more into the lambda code to understand it and write my own server then.