It can work partially with Lambdas. As the Lambda is part of Dgraph core. But as it is JavaScript, it’s not possible to fully debug. As this debug is Golang only. But it is possible to debug GraphQL stuff. Just add breakpoints in the graphql resolvers.
And it is not possible to debug a binary or cloud image. As they are builds. Debugging only happen in the code, before building.
That’s what I was expecting. I don’t think there is a need of debugging the Cloud server since usually nobody who is using the cloud, is interested in debugging code you don’t even have access to - that’s the entire reason of paying for the cloud
However, debugging the GraphQL stuff in lambdas is something which can come in quite handy. This way we do not need to console.log everything when developing a new custom resolver and check the outcome in the cloud interface or return a crazy string in the GraphQL response…
Debugging Lambdas is usually painful. I have a dev environment that makes it much simpler to develop Lambda functions. It has hot reload and you can implement tests before shipping Lambda resolvers. You can see the logs in the console as well. Check this out:
In my case I was using our own Server and before deploying anything on this server I was able to test everything in this Local development environment.
@pshaddel would be nice to start an RFC in the Dgraph repository about Lambda dev improvement.
We have this topic in the roadmap and I’m really interested by your experience here, especially on how we can organize the lambda functions ( deploying a big file is always scary IMO) and how to help the testing / debugging process. @MichelDiz can help on the RFC writing process if you are willing to contribute this way. I’ll also have a look at your repo.