Added a simple diagram just for the flow of program logic when we receive a query.
It is a rather high level point of view… and missing lots of “stuff”. Please pardon me.
But broadly speaking, I think we need to be more careful about what each component is, e.g., which packages, what minimal set of functions are exposed, what minimal set of other components they talk to. Otherwise, things can get confusing as we add more features and we might start having import cycles etc.
There is just one server – not a separate query server and mutation server. PLs are accurate, in fact there are 2 layers of mutations in them, and a small cache in Go just above RocksDB which stores the immutable RocksDB version of the PL.
In fact, I’d suggest going one by one in design concepts https://wiki.dgraph.io/Design_concepts#Concepts, and generating a diagram best explaining that concept in a bit deeper dive. Then, we can build a high level overview diagram which ties all these components together.
For e.g., PLs can really use explanation about move indices and the two mutation layers.
Thanks for pasting the diagram. I shouldn’t have used the word “server”. I was just thinking of server-client whenever we have a grpc. Let me rename to Query handler and Mutation handler and also update the main post.
The components are not really fleshed out as such in the code yet. I just hope we can organize the code such that there are clearer boundaries between the different components in our code.
I’d argue that there are clear boundaries between existing components 
. Go’s compiler would fail if there’s any cycle detected, so if the code is compiling, we do not have a cycle.
If you want to represent the server client interaction – note that workers are sort of peers instead of a clear client server. Both sides open connections to each other. So, you ideally a Worker component which can describe the nature of RPC communication going on.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
