Here’s a little backstory. I have a Node.js module that is an in-memory key value store, with async disk syncing (not unlike redis, only in process, and super simple.) I called it jbase. Well, it turns out there’s a company with a database product of the same name. They own a trademark, and recently contacted me, requesting I rename my project. I’m not looking to fight them, so I’m looking for new names.
Last night (technically, this morning at 3am) I hit on an interesting idea. Right now JBase has two APIs, a model-based on, and a super simple, straight-forward
key-value api. (Most of the development is on the model api, to be blunt.) So, I was thinking, with this rename, what if I also split the two projects up? This would have a benefit of anything I develop against what’s now jbase will have a migration path to a more grown-up database without any code changes on my part, if I do it right.
So, without further adieu, here is my proposal:
The project formerly known as jbase
This would become just the simple
key-value storage api. It’s simple, clean, and very targeted. There are a couple points worth talking about with this, however:
- It has no use for promises (which currently make it slower).
- We could make promises optional.
lodashsupports chained lazy evaluation, and we use it exclusively under the hood, we could expose that, too.
- We need to actually benchmark it so we can really talk about how fast/performant it really is. Right now we have no clue, other than, ‘good enough’.
What’s in a name?
I have a list of possible names we can go with:
Right now, I favor
store.io, because it’s punchy, not taken on npm, and allows for the models project to have a similiar name…
This would be the current model api from jbase. We would split it off, and give it the concept of
drivers. It would have a built-in memory driver (which might be so close to jbase, we don’t even bother), and should probably ship with
the-project-formely-known-as-jbase as a dependency. (It’s so small, I don’t see a problem bundling the two.)
After the split, we’ll need to implement relations, an improved type system (so we can do auto-incrementing fields), and sub documents, but those were all on my radar anyway. After which, we could probably implement a postgres driver and a redis driver, just to prove it’s possible.
So, there’s my idea, guys. @Developers I’d really like you guys to weigh in, but other thoughts are welcome too.
Oh, I should mention, this has some impact on Precursors, since we wanted to move from rethinkdb to something more lightweight while developing, and this plan would give us a clear migration path back to rethinkdb in the future.