quickjs VS LevelDB

You don't need V8 for running JS for scripting, you have quickjs[1] or mquickjs[2] for example. You might have problems importing npm packages, but as we can see from lua plugins you don't even need support for package managers. Performance is not as good as luajit, but it is good enough

[1]: https://bellard.org/quickjs/

[2]: https://github.com/bellard/mquickjs

It wasn't a QuickJS developer but developer from a fork: https://github.com/bellard/quickjs/issues/445

I see a few mentions of QuickJS, but they all refer to the fork of Bellard's QuickJS https://bellard.org/quickjs/, which I think deserves a mention. It seems to be still active (last release 2025-04-26, GitHub mirror at https://github.com/bellard/quickjs shows some activity).

This is a fantastic approach.

BTW, it looks like the js engine is "QuickJS" [0]. (I'm not familiar with it myself.)

I like it because sqlite by itself lacks a host language. (e.g., Oracle's plsql, Postgreses pgplsql, Sqlserver's t-sql, etc). That is: code that runs on compute that is local to your storage.

That's a nice flexible design -- you can choose whatever language you want. But quite typically you have to bring one, and there are various complications to that.

It's quite powerful, BTW, to have the app-level code that acts on the app data live with the data. You can present cohesive app-level abstraction to the client (some examples people will hopefully recognize: applyResetCode(theCode) or authenticateSessionToken(), or whatever), which can be refined/changed without affecting clients. (Of course you still have to full power and flexibility of SQL and relational data for the parts of your app that need it.)

[0] https://bellard.org/quickjs/

Considering the extremes of prolific developers gives interesting contrast to dogmas such as "functions/files should never be above x lines", where `quickjs.c` is 50k lines and has functions that are hundreds of lines long:

https://github.com/bellard/quickjs/blob/master/quickjs.c

(Obviously different approaches suites different circumstances.)

Porting LevelDB[1] to Seastar[2], for internal metadata storage in Redpanda[3]. Before you ask why can’t something off the shelf be used, seastar has unique constraints around its runtime and its memory allocator that means we can’t reuse an existing library.

1: https://github.com/google/leveldb

2: https://github.com/scylladb/seastar

3: https://github.com/redpanda-data/redpanda/pull/28351

The real-time sync of Spuddy is currently powered by a manual deployment of y-websocket-server on Fly.io. It's annoying to manage, as y-websocket-server depends on a seldom used DB - leveldb, which doesn't have much tooling around it. Moreover, as this is YJS, and I am using React, I had to roll my own hooks & integration from React to YJS - all of it is fairly ugly code.

LevelDB: https://github.com/google/leveldb

I'm partial to how cleanly written https://github.com/google/leveldb is. It is a reasonable size to fully read & grok in not too long.

[4] leveldb/doc/impl.md at main · google/leveldb. GitHub. Retrieved October 21, 2023 from https://github.com/google/leveldb/blob/main/doc/impl.md

git clone https://github.com/google/leveldb.git