Inspired by Meteor! By @maxnowack. Neat project!
7 Likes
Thank you for sharing!
I always missed the simplicity of minimongo and thought about a similar solution for general usage since I left the meteor area.
I‘d love to hear your thoughts about it! 
4 Likes
A persisten reactive database like this could be nice for lots of use cases, f.e. static sites without a backend that just need a reactive app state that is easy to sync to backend when/if needed.
I still use Meteor for full stack simplicity when I need a backend. It’s just so easy and there’s nothing quite like it today that is as simple and with signals (or is there?).
It would be interesting if you eventually come up with full stack examples with SignalDB. What could be really interesting is that the full stack app author chooses which signal library to use across the stack, unlike Meteor which is locked in with Tracker only.
1 Like
This is exactly the plan I have with SignalDB. At the moment we’re transitioning from RxDB to SignalDB at VineForecast (the company I co-founded).
SignalDB is used for local data management and for the meantime I’ve implemented a persistence adapter for RxDB to make use of its replication functionality to sync with our backend.
The plan is to implement a similar replication functionality into SignalDB in the future to finally ditch RxDB completely.
Regarding usage in meteor: since Tracker is very similar to signals, I was able to implement a reactivity adapter for it (you find it in the documentation). So SignalDB should be already usable in combination with Meteor Tracker
3 Likes
Interesting, I might research using it in GitHub - leonardoventurini/helene: Real-time Web Apps for Node.js and Bun
Perhaps I can replace my own data layer, @maxnowack would it work if I plugged signaldb into a live query system? Is the matcher accessible and fully compatible with mongodb features?
1 Like
Interesting project!
I don’t have the replication functionality ready yet, but it could be possible to implement a persistence adapter for plugging into the live query system.
It depends a bit what exactly you want to achieve. How do you want to access the matcher? It uses mingo under the hood, which supports almost all mongodb features.
I also took a look at the documentation and found another thing that might be challenging.
I designed SignalDB to hold all data in memory and gave it a synchronous api to get rid of unwanted loading states in the UI. However, I also plan to implement async collections to be more efficient on the server side or in scenarios where it’s not possible/relevant to hold a snapshot in the memory.
1 Like
I don’t fully comprehend how the live query system works as I haven’t built one yet, but based on what I have seen I would need the matcher to filter the changes detected coming either from Oplog or Change Streams, and I would also need to run some simulations on a cache consisting of the data a subscription has access too, like sorting, skip and limit (skip seems to be particularly problematic).
I would try to avoid adding it as a layer between the app and the database as much as possible, limiting it only to the workings of Observer and Multiplexer. So in essence I believe I could use mingo on the server and SignalDB in the client and optionally on the server. I just need to make sure it can replace what I have in Helene Data.
I didn’t know about mingo actually, might be very useful. Thank you!
Ah, I see. Currently, the focus of SignalDB is more on the frontend side. The synchronous interface and the in-memory storage would make server-side implementation a bit challenging. However, in the future, once I’ve implemented async collections, implementing a live query system should be a lot easier, I believe.
If you only need the observing functionality, it might be more reasonable to bypass SignalDB altogether and implement it directly in Helene. Some of the code I wrote for observing queries might also be useful for your implementation. Feel free to use it!
1 Like