Re:Show HN: InstantDB – A Modern Firebase
by shunia_huang on Friday August 23, 2024 @03:00AM
(#41326710)
Good point on the update frequency, I believe it is a must to batch the requests and responds for any of this type of lib/service to work in a production environment, a performance report/comparison is still required for ppl to get the idea if this is good to support their business model.
About the synchronized data though I think it's not about the database but the data types designed to sync the data? I worked on multiple-player canvas games and we didn't really care that much about relational db or document db, they worked both fine. I would love to know what's the difference and the challanges.
Would love to hear how you went about doing things at Framer!
We do indeed batch frequent updates! Still many opportunities for improvements there, but we have a working demo of a team-oriented tldraw [1]
Re:Show HN: InstantDB – A Modern Firebase
by stopachka on Sunday August 25, 2024 @06:02PM
(#41351869)
We would love to hear more about the architecture you used at Framer. Would you be up for a coffee? My email is [email protected]
Does Instant have a way to merge many frequent updates into fewer Postgres transactions while maintaining high frequency for multiplayer?
Regardless this is super cool for so many other things where you’re modifying more regular app data. Apps often have bugs when attempting to synchronize data across multiple endpoints and tend to drift over time when data mutation logic is spread across the code base. Just being able to treat the data as one big object usually helps even if it seems to go against some principles (like microservices but don’t get me started on why that fails more often than not due to the discipline it requires).