-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Holster currently provides a simple API by calling for example, const holster = Holster() in either Node or the browser.
This provides access to holster.get() and holster.put() methods, as well as holster.wire which provides access to another set of get() and put() methods, which are complimentary to the Holster API and use the wire specification directly. See the examples folder for how they can be used to achieve similar outcomes.
The Holster API itself uses the wire API, but it's aim is to get only strings as keys and put a limited set of data types. These are the same as GunDB's data types, ie strings, numbers, objects, true, false and null. The graph data stored on disk consists of nodes referenced by id, which is what the wire API works with. This means the Holster API is responsible for resolving keys to their node ids, and creating ids for objects where they don't exist.
The wire API uses the store API, which is not exposed to the user. The store API also provides get() and put() methods which themselves call radisk(), the radix-on-disk function initially from Porting Gun. I mention these layers because one of the goals of Holster is to make it easy to follow the code. Each layer can be run on it's own and has it's own tests. If there's a problem at any layer a test should be added that shows it was fixed.
There are already some TODO's in the code:
- The in-memory graph stores all puts, which means it will grow indefinitely over time.
- Websockets repeat all data, so all clients receive and store all data, this probably needs some filtering.
- Options aren't passed in to Holster yet.
- Storage is only on Node, need to add to browsers.
Besides these TODO's in the code, there's some other work required to make Holster useful. First is a listen() or on()/off() methods for listening to changes on a key. I also mentioned above that the Holster API is responsible for resolving keys, but it returns data with references in it for nested objects. If it's role is to hide the underlying data structure, maybe it should resolve all references before returning?
I would like to add indexedDB so that the browser version is the same as the Node version. I'm not sure about localStorage as an option as it's so limited, but will at least make it possible to switch storage adapters. It should also continue to work without any storage in the browser.
After that I want to get something like SEA working, as it's a requirement for using Holster in a real web application. I'm hoping indexedDB and SEA can both be incorporated from the existing GunDB code. Lex is also currently only supported with the get item format, {".": "item"} it would be great to have the rest available. After that who knows maybe DAM will be possible too.