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:
@aral thanks for this update in this project, as at this point Kitten is amongst my top 10, tech tasks to do now after I start my tech updates overall (which will be very soon after the roof is done if I'm not sizably injured by that). The simplicity factor is probably amongst my favorite aspects of it, it's a approachability to me, as someone who's spent the most time within coding & prompt realms just before Microsoft basically stole windows from Apple.
@aral Wow. This an astounding amount of work! You basically recreated a friendlier version of Nextjs in your own style. I have no idea who the target audience is besides me, but this is incredible.
Hopefully these should be the last of the large refactors/changes until launch.
This was necessary to optimise server start time (and it just makes sense not to pollute the database used by apps with data not specifically stored there by the app for the same reasons you don’t pollute the global namespace).
(There’s still a lot to build – most importantly automatic updates but it’s getting there… one small step at a time.)
@Monstersx Thanks. The way it’s designed (for production) is that it’s one Kitten service per server. That way it can make some assumptions and manage the TLS certificate, etc.
That said, on your own devices, you can run as many as you like/system can handle on different ports. You’d have to manage the services, exposing ports and handling TLS certificates, etc., yourself though.
(The Small Web design keeps things simple to optimise for ease of deployment and maintenance.)
Add comment