Thanks for the quick response on this and I completely understand. Normally, I would have external databases running as well, but this is more of an embedded project for this one so I will keep searching for an embedded Golang solution.
Actually been researching this a bit an thinking about another possible direction.
As I understand things, for a Dgraph cluster we generally have:
Zero Node — One or more, but seems to be a standard of at least three, so that the cluster can be balanced as needed.
Alpha Node — These are the actual storage nodes and the cluster can have many of them. Perhaps thousands ??? (not sure on this part) that can dynamically join and leave the P2P mesh.
Ratel Node — These are the user UI nodes but seem to be optional and may not be needed for a P2P setup since other client code can make the API calls to the “Alpha” nodes.
If this is correct, then I think that the main P2P design will be to take the Alpha node and develop from there as the base such that the existing “main” function can be renames and spawned off from another Golang main function as a goroutine (thread) to run independently.
The objective is to have a few “servers” shelled off from the main wrapper as goroutines but to also have all of the Go servers compiled into a single application. (i.e. no independent Dgraph Alpha, IPFS node, etc…) so that everything is encapsulated as a single startup background application that starts and stops all of the servers.
That is the goal at least and if I am to use Golang, which has some very powerful features over C/C++ already built-in, then maybe this is the way to integrate all of these Golang servers into a single encapsulating application.
Any thoughts or suggestions would be greatly appreciated.
Thanks in advance