Debug Dgraph with VSCode

Showcase
#1

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.

Captura de Tela (20)
Captura de Tela (20)1812×925 261 KB

2 Likes
#2

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

#3

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
#4

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:

#5

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:

#6

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

#7

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.