Author here!<p>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<p>The most common feedback seemed to be, "this is dumb, just use SQLite", which is definitely valid.<p>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.<p>(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].)<p>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.<p>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] :)<p>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!<p>[0] <a href="https://news.ycombinator.com/item?id=40860116">https://news.ycombinator.com/item?id=40860116</a><p>[1] <a href="https://electric-sql.com/" rel="nofollow">https://electric-sql.com/</a><p>[2] <a href="https://www.powersync.com/" rel="nofollow">https://www.powersync.com/</a><p>[3] <a href="https://tinybase.org/" rel="nofollow">https://tinybase.org/</a><p>[4] <a href="https://www.instantdb.com/">https://www.instantdb.com/</a><p>[5] <a href="https://aws.amazon.com/compare/the-difference-between-graph-and-relational-database/" rel="nofollow">https://aws.amazon.com/compare/the-difference-between-graph-...</a>
This is awesome. About five years ago I wanted to solve the same problem of tracking my pots and glazes. I also noticed the many:many relationship very quickly and deliberated on the schema. Neo4j looked really cool but I think I ended up going with join tables (ie pots, glazes, pot_glaze) in Postgres. I think I didn’t get nearly as far as you did in a weekend though!<p>Lately I hack in firebase and have been interested in trying supabase. I’ll have to add instantdb to my list.<p>You should productionize this! Get glaze recipes in there too!
there is actual science behind this, check a glaze calculator like insight <a href="https://insight-live.com/" rel="nofollow">https://insight-live.com/</a> and component info like <a href="https://digitalfire.com" rel="nofollow">https://digitalfire.com</a>
If you're trying a lot of different options you may want to check out something called Design of Experiments. [0]<p>0. <a href="https://en.wikipedia.org/wiki/Design_of_experiments" rel="nofollow">https://en.wikipedia.org/wiki/Design_of_experiments</a>