Queries

Graphql means you don't need a query language because graphql is an agnostic one.

Just write non join queries in each graphql resolver. Good match for KV stores !

Seems like a perfect match for this project.

It maybe that these basic queries can be done agnostically in the resolvers too at runtime using reflection. Storm led the way there. I don't think it's that huge a task if things are restricted like storm does.

If a developer does not want the performance penalty of reflection based query builders they don't have to use it. In graphql the resolvers are very simple so there are no side effects either of this developer choice

https://github.com/asdine/storm

Insummary the two together gets us an agnostic query layer

[philippgille]

Storm looks interesting, I seem to have given it a star on GitHub a while ago, but totally forgot about that project.

I'm not sure if I understand you correctly though. Do you mean:

• Create something like storm, but for other key-value stores instead of BoltDB? So maybe fork storm, refactor it so that instead of using BoltDB directly an interface like gokv.Store is used, meaning all gokv implementations can then be used for storm? Or
• Add a query method to the gokv.Store interface (like GetAll(query string, vals interface{}) error) and use storm or parts of storm to achieve that?

[GwynethLlewelyn]

I would certainly love a GetAll() query method, too! 😹

On the other hand, I see there may be a conceptual conflict here. Storm uses a minimalistic query language to achieve good performance, but currently, support is limited to BoltDB (at the moment of writing this comment; the author has ported his other tools to support additional KV stores, but there seems to be no information regarding doing the same to Storm). gokv, by contrast, supports a huge set of (interchangeable) backends, at the cost of having only 3 basic operations (plus Close()). Not having taken a close look at the code of either solution, it seems to me that, to achieve its magic, Storm is really tightly bound to BoldDB and expects it to be able to do by default everything it requires; gokv would have to develop a minimum set of primitives across all supported backends to give Storm what it needs. That might be a huge task to do!

But I understand the OP's point (his account seems to have been deleted in the meantime). For many simple cases, you can live with just the basic 3 (+ 1) primitives and the ease with which the backend can be replaced, especially for those nasty clients that insist that they really want memcached and not Redis... and a year later swear by BoldDB or Badger... and so forth; using gokv, the ease with which you can replace the backend is a really major feature — which comes at the cost of using only the least common denominator of all existing database backends.

It's just when things become a little more complicated that gokv shows how much it could benefit from even a basic, very rudimentary query language. Consider the following scenario: you want to check if one element of a struct has been stored under at least one key, but possibly more than one. The only 'simple' way to do it with gokv, IMHO, is to have several open store clients, one for each element of that struct (i. e. for all purposes these would be 'indices'), and create a further layer of complexity on top of gokv to keep all those indices correctly updated. I foresee that such an arrangement would require either duplicating the same content stored in the struct on each of the 'index stores'; or keep the actual data on a separate store and just store a pointer to it... well, in essence, designing your own database engine on top of gokv!

Nothing wrong with the latter approach, of course... it's just that it seems overkill for most projects — you could just easily pick a RDBMS instead (such as SQLite3...) and let it do its job...