Author here!
Surprised to see this on the front page again (hello fellow pottery enthusiasts?), but figured this could be a good chance to address some of the comments from the recent discussion [0] since I missed it last time :P
The most common feedback seemed to be, "this is dumb, just use SQLite", which is definitely valid.
This was actually how I initially started building the app (using SQLite), and it worked pretty well. There were a couple reasons I abandoned this approach though: one, whenever I had to uninstall and reinstall the app, the data would get wiped; two, I still had to deal with migrations and other annoying boilerplate; and three, I wanted to be able to share my results with my friends in a read-only web view.
(That being said, I'm also curious to explore how tools like ElectricSQL [1], PowerSync [2], TinyBase [3], etc. play with SQlite to handle some of these issues. At a glance, it just seemed like these would require more time to setup compared to InstantDB [4].)
Another similar comment that popped up a few times was the idea that if I'm trying to model _relational_ data, it would be ridiculous to use anything other than a _relational_ database.
I think that's fair, but I also think it's fair to say a graph database is also "relational" in some sense, or at least "relationship-centric" [5] :)
Either way, I had a lot of fun with this. And I was definitely optimizing more for speed/scrappiness than for doing it The Right Way, so if anyone has any thoughts on how to build stuff faster, I'd love to hear it!
[0] https://news.ycombinator.com/item?id=40860116
[1] https://electric-sql.com/
[2] https://www.powersync.com/
[3] https://tinybase.org/
[4] https://www.instantdb.com/
[5] https://aws.amazon.com/compare/the-difference-between-graph-...
Surprised to see this on the front page again (hello fellow pottery enthusiasts?), but figured this could be a good chance to address some of the comments from the recent discussion [0] since I missed it last time :P
The most common feedback seemed to be, "this is dumb, just use SQLite", which is definitely valid.
This was actually how I initially started building the app (using SQLite), and it worked pretty well. There were a couple reasons I abandoned this approach though: one, whenever I had to uninstall and reinstall the app, the data would get wiped; two, I still had to deal with migrations and other annoying boilerplate; and three, I wanted to be able to share my results with my friends in a read-only web view.
(That being said, I'm also curious to explore how tools like ElectricSQL [1], PowerSync [2], TinyBase [3], etc. play with SQlite to handle some of these issues. At a glance, it just seemed like these would require more time to setup compared to InstantDB [4].)
Another similar comment that popped up a few times was the idea that if I'm trying to model _relational_ data, it would be ridiculous to use anything other than a _relational_ database.
I think that's fair, but I also think it's fair to say a graph database is also "relational" in some sense, or at least "relationship-centric" [5] :)
Either way, I had a lot of fun with this. And I was definitely optimizing more for speed/scrappiness than for doing it The Right Way, so if anyone has any thoughts on how to build stuff faster, I'd love to hear it!
[0] https://news.ycombinator.com/item?id=40860116
[1] https://electric-sql.com/
[2] https://www.powersync.com/
[3] https://tinybase.org/
[4] https://www.instantdb.com/
[5] https://aws.amazon.com/compare/the-difference-between-graph-...