Open amaster507 opened 3 years ago
Dgraph is comprised of 3 main parts, Badger, Ristretto, and the core Dgraph layer. The core layer can be sectioned up into parts per the folder structure on Github. One of Dgraph's sections is the GraphQL to DQL rewriting functions. What we need is to understand is why does Dgraph not work well on non unix systems and find an alternative solution for those parts or the whole if the rest of it greatly depends on the incompatible parts.
The core layer, and Badger both use Ristretto for a caching layer. I know that jmalloc is unix only and seems to be the main problem with incompatibility but without it, Dgraph bloats on memory. Can we solve this memory bloat by ripping out some features that we don't need? Or would it be better to redevelop the wheel in a way to avoid these memory bloats by only doing what we want in the way we want.
The scalability and the speed of Dgraph is provided in Badger which is a distributed key-value store that distributes data by predicates. So, do we want to use Badger since we don't need any of this distribution?
I almost think that we should build this in a way that is very simple which may lead to writing new code and leveraging a different key-value store that we can then use to persist data and use Dgraph core algorithms to implement the DQL and GraphQL endpoints.
I'll just use this comment to backup a few links and will comment on these later:
I think genji might fit your needs as a dgraph client side dB
i use it now inside browsers, desktops and mobile .
it uses badger dB, is golang, compiles to tinygo and so can run in browsers and iOT devices
https://github.com/genjidb/genji
Also other devs have added a graphql layer on top . See the issues
Discussion to agree on a tech stack that will work with low system requirements