It uses the latest version of JSDB (5.1.3) which fixes an issue where instances of EventEmitter subclasses persisted to the database were erroneously persisting their (by convention private) _events arrays containing AsyncFunction instances and thereby causing a crash on the database open attempt when the AsyncFunction class could not be found as it wasn’t provided to the JSDB.open() method.
… JSDB, by the way, is short for JavaScript Database, which is, umm, a JavaScript database.
It’s an in-process, in-memory database for Node.js for Small Web use that persists to an append-only JavaScript – not JSON, JavaScript – transaction log.
JSDB’s very easy to work with because you just use native JavaScript objects and they just automatically get persisted for you.
e.g., Here’s a quick 6-line Kitten app that persists a counter:
Just published a minor update (version 5.1.1) to JavaScript Database (JSDB) that optimises the custom data type¹ serialisation code by removing a redundant return statement:
This change is backwards compatible and shouldn’t require and updates to your projects, including the ones you have in Kitten (which uses JSDB internally).
This is a little something I ended up playing around with this morning before figuring out how to do it (after spending far too much time down a rabbit hole with object destructuring when what I really needed was creative use of the spread operator).
Philosophically, JSDB – which writes out to native JavaScript logs – is very much the JavaScript version of SWX, the native data format for Flash that I released around 2007 (where data was written out in native SWF format). I have to say that I’m glad I didn’t have to reverse engineer SWF bytecode this time around :)
Here’s a video of a younger me doing an impromptu demo of SWX at some conference or other from 16 years ago.
100% test coverage doesn’t mean your code’s bug free but it did just lead me to find and fix an issue in JavaScript Database (JSDB)¹ with a code path that wasn’t being hit that I would have otherwise missed because it was causing the relevant test to pass.
¹ JSDB is a zero-dependency, transparent, in-memory, streaming write-on-update JavaScript database for the Small Web that persists to a JavaScript transaction log (an append-only log).
To really drive home the above 👆 point that 100% test coverage does not mean ‘bug free’, just found a bug in JSDB¹ 5.0.0 where running JSON.stringify() on a complex custom object (actually: the automatic Proxy of the custom object created by JSDB) results in an error.
Already have a failing test and about to implement fix.
(It’s at this point where the test harness is invaluable.)
Realised last night that JavaScript Database (JSDB) doesn’t run the constructor on persisted custom objects (https://codeberg.org/small-tech/jsdb#custom-data-types) when deserialising them because I didn’t know that you apparently have to define your constructor manually when using Object.create().
Will fix it today but it’s something to watch out for if you’re using Object.create() directly.
This is a niche one and will likely not affect any of the (three?) people playing with Kitten¹ right now but, in any case:
If you persist custom types to your Kitten database, you might be hit by this bug that was introduced when I released versions of Kitten with minified identifiers.
I briefly wrote about what happened, how you can identify if you’re affected, and how you can fix it here:
Coming soon: it’s going to be trivial to deploy a different app on your Small Web server. Useful if you’re a dev and you’re playing around with different apps.
(Also, notice the speed at which deployment happens. I’m one step away from implementing this in Domain using pre-warmed Kitten instances – called toasty kittens – thereby bringing the time it takes to deploy your own Small Web place down to a handful of seconds.)
When I speak about spending the last few years “building infrastructure”, you might be wondering what sorts of things I’m talking about.
Here are some examples:
JSDB: an in-memory, in-process database that writes to a JavaScript append-only transaction log and which you can use as if you were interacting with regular JavaScript objects.
I want to make a web app for viewing, creating, and modifying entries saved to a local file. I will use it on my old budget Android phone, and I want it to be as performant as I can possibly make it.
Just got it working in Domain² (a Kitten³ app). It’s such a sweet workflow. Store state keyed to session keys and use Streaming HTML⁴ to stream hypermedia interface updates.
The state class is no longer a proxy itself but instead uses a proxy to guard access/update of states. This means instances/subclasses of State can now be persisted in JavaScript Database (JSDB)² objects. e.g., for use in Kitten³ apps.
Also, if you are looking at the code, notice how I’m persisting and retrieving custom JavaScript objects from the database and generally interacting with the database as I would with any JavaScript object.
Removed table-level proxies for the table delete(), addEventListener(), and removeEventListener() methods. These were erroneously being injected not just into table objects but into every data object in them (which was destructive in the case of delete()).
Given you can persist custom JavaScript objects in JSDB, this namespace pollution was a problem.
Kitten¹ now keeps two JSDB² databases per project: an internal one ('kitten._db) that holds data Kitten manages (sessions, uploads, etc.) and the default one (kitten.db`) that holds your own tables.
You’ll mostly only care about the latter.
I also took the opportunity to create a Database App Module example and document it in the readme:
It’s so cool to be able to tail your database (append-only JavaScript log¹) when playing with Kitten².
(If I do say so myself.)
The output on the right is the initial state of running the following command on your project folder to tail the domains table when the project is being served on the domain dev.ar.al:
Just released JavaScript Database (JSDB)¹ version 3.0.3
This is a bug fix patch that fixes options defaults not being applied when an options object is passed to the JSDB and JSTable constructors².
¹ JSDB is a zero-dependency, transparent, in-memory, streaming write-on-update JavaScript database for the Small Web that persists to a JavaScript transaction log (https://codeberg.org/small-tech/jsdb)