First of all, thank you for the work on this project. The implementation feels very clean and thoughtfully designed, and the documentation is clear and well structured.
I’m currently evaluating SignalDB alongside TanStack DB, and I’d appreciate your insights on two areas where TanStack DB appeared to have an advantage for larger or more complex operations, but after digging deeper into the docs here, that impression may not fully hold.
I'm adding this as docs: issue since I think many other devs would appreciate if answers on this would improve the docs as well.
Relationships
The support for flexible relationships via sub-queries appears to be somewhat buried in the documentation:
https://signaldb.js.org/orm/#resolving-relationships
From what I can tell, relationships can be composed in ways that are just as expressive as TanStack DB, but implemented with a cleaner separation-of-concerns approach.
Would you say that both are equally powerful?
(PS: I think it'd make sense to give relationships their own dedicated documentation page since it's a core capability for most dbs and it deserves stronger visibility.)
Differential Data Flow
TanStack DB’s relies on ElectricSQL's d2ts flow engine.
My understanding is that SignalDB might achieve similar performance by using transformAll:
https://signaldb.js.org/orm/#solving-the-n-1-problem-with-transformall
Are there any significant differences in how incremental computation is handled?
And if so, do you see something like the differential flow engine as something that could eventually integrate with or influence SignalDB’s design?
I appreciate your insights on the differences between these approaches!
Again: I really enjoy the API design and the straightforward, readable documentation here - it somewhat feel like the "German engineering" myth of the good old days :P .
First of all, thank you for the work on this project. The implementation feels very clean and thoughtfully designed, and the documentation is clear and well structured.
I’m currently evaluating SignalDB alongside TanStack DB, and I’d appreciate your insights on two areas where TanStack DB appeared to have an advantage for larger or more complex operations, but after digging deeper into the docs here, that impression may not fully hold.
I'm adding this as
docs:issue since I think many other devs would appreciate if answers on this would improve the docs as well.Relationships
The support for flexible relationships via sub-queries appears to be somewhat buried in the documentation:
https://signaldb.js.org/orm/#resolving-relationships
From what I can tell, relationships can be composed in ways that are just as expressive as TanStack DB, but implemented with a cleaner separation-of-concerns approach.
Would you say that both are equally powerful?
(PS: I think it'd make sense to give relationships their own dedicated documentation page since it's a core capability for most dbs and it deserves stronger visibility.)
Differential Data Flow
TanStack DB’s relies on ElectricSQL's d2ts flow engine.
My understanding is that SignalDB might achieve similar performance by using
transformAll:https://signaldb.js.org/orm/#solving-the-n-1-problem-with-transformall
Are there any significant differences in how incremental computation is handled?
And if so, do you see something like the differential flow engine as something that could eventually integrate with or influence SignalDB’s design?
I appreciate your insights on the differences between these approaches!
Again: I really enjoy the API design and the straightforward, readable documentation here - it somewhat feel like the "German engineering" myth of the good old days :P .