Back when I began working on PliantDb, @dAxpeDDa and I struggled to come up with a good name for the project. I came up with this idea, but never really had a solid vision behind the branding for it.
While chatting the other day, we were lamenting how even after all these months it still didn’t roll off of our tongues. As I tried to name the serialization format we’ve been working on, I pointed out how I wished I could tie it to “pliant” somehow, but because the original name was so generic, we weren’t coming up with any good ideas.
In the midst, he asked a crazy idea, what if we renamed it? At under 50 stars on GitHub, it seemed like the earlier the better. After a fairly quick brainstorming session, we came to a new idea: BonsaiDb
Why BonsaiDb?
The analogy makes a lot of sense: a bonsai tree is something you grow, but it has a life of its own. That’s a great analogy to what a database does over time when building an app or business. How often do your first designs remain unchanged in the final product? Databases need to be cared for and maintained. Just like a bonsai tree might sprout a new branch, users of your app might stress your storage model. Should you embrace it or snip it?
Beyond the analogy, I’ve always loved the beauty of bonsai trees. In fact, before @dAxpeDDa suggested the name, I had been casually researching them in a thought of adding some plants to our home. Now with this name selection, it’s a foregone conclusion that I’ll be continuing forward with that plan at some point! The biggest problem is the limited kinds that will grow in the very dry climate.
What’s up next for BonsaiDb?
We are waiting for some upstream changes to stabilize before we release this crate under the new name. After the new crates have been published, the old ones will be updated with a note that they’re up for grabs.
In the meantime, I haven’t been resting idle. The user authentication pull request was merged at the start of the week. I spent a few days updating Pot (formerly known as PBOR) based on a few conversations I’ve had.
The last change I did today was working towards the app platform: adding out-of-band custom API responses. It allows easy broadcasting (from counter/server/src/main.rs#L86):
self.server.broadcast(Response::CounterValue(new_value)).await;
And, on the client, you can now register a handler for responses received that weren’t originated from a request (from counter/client/src/main.rs#l145):
Client::build("ws://127.0.0.1:8081".parse().unwrap())
.with_custom_api_callback::<ExampleApi, _>(move |response| {
let Response::CounterValue(count) = response;
client_context.context.with_widget_mut(
&client_context.button_id,
|button: &mut Button, context| {
button.set_label(count.to_string(), context);
},
);
})
.finish()
.await
With these features, we’re very close to being ready to build real apps. We’re about to shift back into Gooey a little bit to try and get a log in/sign up screen working that we can wire up in an example.