I must admit I’m late to the party and I’ve only been researching graphs for the last couple of years, but after a worthwile struggle with SPARQL and RDF ontologies, I’ve now decided to partake in a very interesting project, which involves using dgraph a lot.
We’re trying to build a graph VM with its own bytecode, assembler, sophisticated caching mechanism, etc. with dgraph as the primary I/O. I haven’t measured this, but I can imagine there’s quite a bit of overhead constructing GQL queries in Go (our application), pushing them over the API, and deconstructing them in Go (dgraph) again. Would it be reasonable to straight up import the GQL packages in the application, manually construct the queries, and send them over to a patched dgraph instance by wire as a binary or gob–like low–level construction [according to https://godoc.org/github.com/dgraph-io/dgraph/gql] of the query?
I’m not sure whether if this is going to work, but I’ve got this hypothesis that in graph calculus arbitrary morphisms can be viewed as monads; if that’s true, we should be able to describe any graph computation as a composition of morphisms like we would normally do with monads in functional compositions.
We want to create an assembly language that would have instructions to express both low–level ideas, such as vertices, edges, as well as high–level operations and search algorithms, so the byte–code could be iteratively optimized in pursuit of an optimal computation.
Does any of this make any sense?