Nick Schrock

Graphscale has not been deployed to a public cloud provider. It should be done to GKE using Kubernetes. Use Kubernetes secrets instead of hardcoded-passwords. Then do perf testing etc.

It would be very useful to have a docker composer file to be able to easily spin up a local instance of Graphscale. This would require a mysql container, a...

Eventual consistency in Kvetch is guaranteed by "cleaners" which ensure that indexes and edges correctly mirror the canonical data stored on objects. These are not yet implemented. This is a...

This will be necessary for many application graphs. A good example of many-to-many edges is twitter's follow graph (directional) or facebook friend graph (bidirectional). One challenge will be managing which...

When I first wrote the in-memory kvetch shard, I wasn't aware that there was a viable in-memory implementation of sqlite. Reimplementing the memory shard on top of that would allow...

Right now kvetch just does a mod of the user_id in order to allocate shards. That is dumb. Consistent hashing, for example, is a superior strategy. See http://michaelnielsen.org/blog/consistent-hashing/

It's easy to write manual code in generated files and accidentally check it in. This should be controlled by tooling. One good way would be a "signed source" system where...

In order to be high-performing, the entire working set of the application should resident in memory. The easiest way to do this would be to add a lookaside caching layer...

Graphscale hasn't been tested with multiple shards and some operations are unsupported. This needs to be actually done.

Using pickle is a bad idea for kvetch storage. It should use json instead. This would be trivial except that UUIDs are heavily used within kvetch and type information is...