I’m building a Node native addon wrapper around Couchbase Lite for C to provide a cross platform solution for Windows, MacOS, Linux, iOS, and Android.
The library currently supports nearly all the features in the Community Edition (including querying, replication, and blobs), but has only been tested on MacOS so far, and there are occasional bugs that have been extremely difficult to track down.
Note: this is very much a work in progress and the API is not guaranteed to be consistent.
Thanks a lot for your effort in developing the Node.js bindings for Couchbase Lite. We would love to have you listed alongside some of the other bindings for Couchbase Lite. I can also suggest joining our Discord community where you could get some support from other community members/staff.
Additionally, it might be useful for you to get in touch with the developers of another one of our community bindings, the Dart/Flutter package.
I took inspiration from the other listed bindings when building this library and would be happy to join their ranks. I see the Dart bindings authors created a GitHub org just for that library, and I think I’ll do the same so it doesn’t look like just some abandonware personal project.
Thanks for the invite to the Discord community and link to the Dart/Flutter bindings. I’ll reach out in both places for help and feedback.
Do you have any preference on an NPM package name for this? I’m not looking to step on Couchbase’s toes by stealing the “cblite” or “couchbase-lite” package name.
Well that would certainly have saved me some time. I never wanted to implement my own solution; just couldn’t find a solution anywhere else.
Unfortunately, this doesn’t seem to cover all the bases. It lacks support for replication and (if I’m not mistaken) saving blobs. That makes sense for a vscode plugin, but I believe it would be needed for most applications since replication is the reason you would choose Couchbase Lite. Are there plans to add replication?
Also unfortunately, I can’t get the plugin to work for me in vscode to try it out. After installing, the “Open database” command doesn’t appear to do anything. Nothing in the output panel to debug it either.
The C++ code in vscode-cblite is certainly easier to read. I chose to go with plain C because the Couchbase Lite C readme states that other language bindings “(even C++) have no official support by Couchbase.” I thought it would be best to minimize the number of layers of abstraction, especially if those layers don’t have official support. Though I could be convinced otherwise.
As far as official node.js support I cannot say anything about that. Casually adding in new supported platforms that cover multiple operating systems puts a very large resource strain on any development and QE team.
I can only say for me the bindings did work as also the vscode extension and i am vscode contributor always on newst edge versions of everything to address issues even most time before they reach LTS and the c++ assumption is correct from @borrrden while the most best would even be rust and go for neon bindings as this skips the ugly gyp and allows better cross platform builds faster.
It is unlikely that the Rust bindings will get back on track from our side. We don’t have anyone who knows Rust particularly well, and since I looked at Rust years ago it has transformed into something unrecognizable to me. Not to mention it then goes through two layers of unsupported, unofficial projects instead of one (node.js → rust). I guess you could make the same argument now (node.js → c++) but at least we have developers who are well versed in C++ working on the latter variant.
Also, the biggest purpose of the bindings repos that we have on top of C is just to show PoC that it is possible to leverage C to bring Couchbase Lite to other languages, not to claim that we are going to release the next platform as language X. I’m not sure if this demonstration was a factor or not, but as noted above a community user created a beautiful set of Dart bindings for use in Flutter, for example.
In terms of package naming, I’m not familiar with NPM specifically but most package managers offer the concept of prefixes. Were we ever to make an entry into NPM I imagine we would claim the couchbase. prefix as we have done elsewhere (and get a blue checkmark for it, if that is a thing, thereby invalidating other packages that may have that prefix). So if your package does not contain that prefix it should be fine, even if it contains the words couchbase lite inside of it. This is from a technical standpoint though, and I don’t know what other stances need to be considered ( @priya.rajagopal ? )
You cannot bundle/distribute the CE/EE binary version with the bindings. The CBL libraries should be specified as dependencies and pulled down separately by the users. That way, the users are agreeing to T&C of EE/CE license respectively and also compliant with commercial use of BSL license
You cannot link to any BSL licensed code (i.e. build CBL dependency and link the library).
We should not ship any bindings we can only share build instructions including download instructions.
as couchbase says download and executing build instructions manual is equal to license aggreement.
we can ship d.ts files for the resulting bindings.
also it makes no sense to build bindings for the community edition of CB-Lite as even that is covered by the BSL so it makes total no diffrence from User perspectiv if he uses CB-lite ee or ce. Both are useable without a EE Subscription out of License view. There is no single case where the Community Edition could be used and the EE Could not.
Hmm, that makes things a bit more difficult for users. My library currently downloads the Couchbase Lite code and builds upon install. Since the couchbase-lite-C repo doesn’t give any rules about how to include the source code (it uses the Apache 2.0 license), I assumed the same would follow about the built dynamic libraries. Maybe we can build directly from the source code. Can you share where you found those licensing guidelines?
It makes sense to build bindings for the Community Edition though, since that is free to use in production, whereas the Enterprise Edition requires a paid subscription for use in production.