Making sense of Dgraph's source code—where to start?

Users Dgraph
1

https://octo-repo-visualization.vercel.app/?repo=dgraph-io%2Fdgraph

image
image1104×1132 220 KB

I’ve just been scanning through Dgraph’s repo, I want to get a better idea of how it works, and also learn Golang. I figured it’d be impossibly hard to understand for a CRUD dev like me, however, it’s seems to be really modular and quite approachable. I’m sure the core team are laughing reading this, lol.

My question is, what are the best things to focus on in order to get my head around the Dgraph codebase? What are the most important parts to understand, and which parts of the codebase make the most sense to focus on first?

3 Likes
2

I don’t think so. It is really nice to see the attempt in going deep into the code.

This mapping is interesting. Nice way to see how the things are disposed.

I think that the VS Code navigation for Go can help a lot. This map is also very precise.

What is your goal? what you wanna do?

I’m not a core dev. But I have dug the code from time to time. Things in go are quite simple to do. In the case of Dgraph I think that a map explaining things would be great for new supporters.

1 Like
3

I think that the VS Code navigation for Go can help a lot. This map is also very precise.

Thanks, I’ll look into this.

What is your goal? what you wanna do?

Ideally, I’d love to know enough to be able to make a PR for a GraphQL feature that isn’t being worked on. Nothing specific in mind, but I see feature requests that have been deprioritised and wonder whether it’d be possible for me to build it myself.

1 Like
4

I think the GraphQL part is fine to deal with. The “big problem” is that you have to always create tests along with the coding.

3 Likes
6

Great picture :+1:

7

One thing that surprised me the most from the codebase, is that they use globals a lot. I’ve never seen a successful Go project using globals to this extent. There’re lots of singletons. I’m not sure what is the reason of this coding style, but understanding this fact helped me to dive deeper.

1 Like
8

lots of singletons

I noticed that too - not my cup of tea but they seem to be not causing any issues that I know of.

As far as working through the code (from an outsider’s perspective) I like to start at the gRPC server implementations of the call I am starting with (mostly Query or Alter) which are implemented by edgraph.Server.

As far as the non-call based operations, like database value log compaction and other operations like that, look in ./worker/ which is where most of the alpha code is. Obviously (or maybe not obvious, I dunno) the entrypoints and http wrappers are in ./dgraph/cmd/{alpha,zero}

1 Like