zmapi VS oxide

Simple things like:

Spodcast, a Spofify->RSS bridge [1], made it because I listen to netcasts while working outside out of network reach (forest and field work).

Reader, a native-look epub/pdf/cb[rz] reader for Nextcloud [2], made it when my daughter was issued an iPad at school on which she was not allowed to install any "apps" while I thought the thing was tailor-made for reading books. The iPad was returned years ago but I recently updated Reader to make it run again.

...and a host of small tools which I make just when I need them, dumping them to GH for all to peruse, e.g.:

ZMapi, a Zoneminder CLI tool [3], made it when I installed a video surveillance system in the new barn which uses Chinese cameras which I do not want to be able to access the 'net directly.

bs, a Bookstack API CLI tool [4], made it when I needed to upload a large number of conference videos to a Bookstack site.

...etc

I don't have much time for these side things since I'm mostly busy on and around the farm but every now and then the weather is a good excuse to keep me inside...

[1] https://github.com/Yetangitu/Spodcast

[2] https://github.com/Yetangitu/files_reader

[3] https://github.com/Yetangitu/zmapi

[4] https://github.com/Yetangitu/bs

Sorry about that, it's just a shortcut for https://github.com/fcoury/oxide.

Mostly on MongoDB to PostgreSQL translation server: http://oxidedb.com or https://demo.oxidedb.com.

I have been wanting to dive deep into a Rust project and the challenge of implementing the MongoDB protocol and then translating it into some sort of SQL counterpart was the first thing that really clicked and got me excited enough to get me working on it nonstop for 3 weeks now.

Some backstory:

I have created a product that relies on MongoDB for a document store but doesn’t really need any of the distributed features to really justify having a hosted MongoDB or DocumentDB instance. Now that we’re trying to turn this into a product, we’re seeing that some companies have a little bit of resistance around managing yet another database. Most of our clients already have and manage PostgreSQL in one form or another. I knew that PostgreSQL already offered first class JSON support, but I didn’t want to rewrite the application data layer from scratch if I could avoid it. That’s when I started researching if there was a “proxy” that would translate the MongoDB protocol - that I was completely ignorant about - into PostgreSQL. To my surprise there was nothing ready for production use but I found MangoDB that later on became FerretDB. I delved into the code and was in love with the idea. The team around is really nice, but I found that they had greater ambitions - they basically wanted to offer multiple backends, namely Tigris, on top of PostgreSQL.

On the other hand, I have been waiting to find an excuse to delve deeply into the rust ecosystem but never really found something I was passionate about until I had the idea of challenging myself to see if I could learn about the protocol that MongoDB uses by relying on their public documentation and the hints I found on FerretDB.

Another thing I added to my toolbelt while developing this was about creating parsers. In order to transform MongoDB JSON to SQL queries, I ported an existing library from the MongoDB team from PEG.js to pest.rs!

It’s in very early stages, and it’s work from someone that is not yet super comfortable with the stack so keep in mind this is the beginning of a journey for me that I embarked out of pure joy on getting a tiny bit better on rust and making things click internally.