Open CMCDragonkai opened 2 years ago
Should investigate the usage of node-addon-api
before tackling #5 or #1 as they would involve more C/C++ code. In fact #5 would be prime candidate for migrating to using node-addon-api
.
And also the integration of ccache
#44 as it would be quite slow to compile.
The rust way of doing things is a far simpler. And NAPI-RS does alot of good things. If we switch to using the rust's rocksdb, we might get around some of the problems.
Of course one has to be aware of the block encryption requirement. Right now no mention of that API support. I created an upstream issue https://github.com/rust-rocksdb/rust-rocksdb/issues/802
Also see: https://github.com/cockroachdb/cockroach/blob/master/docs/RFCS/20171220_encryption_at_rest.md
I have a feeling that delegating the lifecycle and resource management to JS side is the right thing, and instead the C++ code shouldn't be using classes at all, but instead exposing underlying state possibly through opaque pointers that can be managed manually be JS. This does require a bit of rearchitecture.
Specification
The work from #19 introduced rocksdb, and inherited the architecture from leveldown and rocksdb.
This means that we have roughly 3 layers of abstraction:
DB.ts
,DBTransaction.ts
andDBIterator.ts
- this is what is used by the end user of this librarynapi-macros
, but doesn't use thenode-addon-api
framework. This creates a flat list of functions exposed fromindex.cpp
, and these functions manipulate classes likeDatabase
,Transaction
, these classes embed logic involving thenapi
system in nodejs, the code here is not portable to the non-node environmentnode-gyp
, and all of its objects are encapsulated in classes in our C++ NAPI bindingThere's a couple things here that aren't as robust as they can be:
napi-macros
, let's just usenode-addon-api
, it seems like a much more comprehensive framework for integrating into nodejsI have some ideas to make the C++ classes behave more like JS classes, and to use the napi bindings to connect them together. Then instead of exposing raw functions, we just extend the native class constructors with the JS classes. However at the same time, keeping the interface simple might simplify the expectations the JS side has of the C++ side, so that when android/ios work is involved, and napi conveniences are not available, then we have to consider if there's an additional bridge layer like Java or Swift/Obj-C that sits in-between the JS and C++ code.
Additional context
Tasks