Debug Dgraph with VSCode

Now you can debug Dgraph via vscode.

It’s very simple to get started.

  1. Clone the repository.
    PS. Make sure you have the Go env ready.
  2. Go to the VsCode debug tab.
  3. In the debug execution field, choose the “normal” or “ACL” task.
  4. Add your breakpoints anywhere.
    PS. But make sure you are putting in the right place that it will be triggered.
  5. Use the variables panel to inspect the variables. You can change the value of variables on the fly.
  6. Use the debug control that will appear at the top to navigate between breakpoints.

Optionally:
You can use Jaeger out of the box. Just run an instance in the same port in the config and done.

Ready. You are debugging Dgraph.

Don’t forget to clear the paths every time you start a new debug. If you don’t want to use the same artifacts and dataset used in the previous debug.

3 Likes

Is this limited to stand alone Dgraph instances or would this work for the Cloud too? Eg. could we debug custom lambdas this way?

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.

1 Like

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 :grinning_face_with_smiling_eyes:

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…

Great work! :raised_hands: Thanks! :pray:

1 Like

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:

1 Like

Oh nice! So basically you test everything in a local container before deploying it to the cloud, right?

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.

1 Like

@Raphael I’d be happy to help write the RFC. I also look forward to your feedback on the repository and further discussions.