One bit of feedback: Its always appreciated when code examples on websites are complete. Your example isn't complete -- where's the `transact` import coming from, or `useQuery`? Little minor details that go far as your product scales out to a wider user base.
Show HN: InstantDB – A Modern Firebase
91–100 of 308 posts
Re: Show HN: InstantDB – A Modern Firebase
#92[Firebase founder] The thing I'm excited about w/Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story). Good luck, Joe, Stopa and team!
Thanks for creating Firebase! It's really the definition of an managed database/datastore. Do you see InstantDB as a drop in replacement ? To be honest I don't want to have to worry about my backend. I want a place to effectively drop JSON docs and retract them later. This is more than enough for a hobbyist project, though I imagine at scale things get might not work as well.
For what it's worth, we designed Instant with this in mind. Schema is optional, and you can save JSON data into a column if you like.
If you wanted to store documents, you could write:
```
useQuery({docs: {}}) // get documents
transact(tx.docs[docId].update({someKey: someValue}); // update keys in a doc
transact(tx.docs[docId].delete()) // delete the doc
```
Re: Show HN: InstantDB – A Modern Firebase
#93How about (inspired by another HN post) - a rebuild of a TUI for email, given how its built:
https://blog.sergeantbiggs.net/posts/aerc-a-well-crafted-tui...
It seems that building a version of this Aerc Email TUi with Instant is a completely doable?
Might be an interesting tutorial to build out an Instant FroBenDB (Instant is an instant Front-BackendDB :-) --- btu the txtual nature of aerc and its configs seem ripe for just bolting it to Instant.
Re: Show HN: InstantDB – A Modern Firebase
#94you could call it freebase, because this is very stimulating
Re: Show HN: InstantDB – A Modern Firebase
#95Earlier quoted context omitted.
Yep. Which climbs have you attempted, at what grades. My gym uses griptonite, but it's so slow I feel like it'd be quicker overall to create my own app for logging things. I decided to use instantdb as a backend database and it's working nicely so far.
Climber Dreamer here: Former RFID Sensor stuff. I'd love to see a smart Hold that integrates with an app where the gym cann associate holds/grips in a DB inventory - and pull them out and assign them to a boulder/wall & route. The smart holds have simple pressure sensors for knowing when they are gripped, and for how long. Advanced ones measure force/weight. Just walk in scan the boulder's code to slurp in all the ho…
I am not a climber, but that sounds like a really fun project!
Re: Show HN: InstantDB – A Modern Firebase
#96One bit of feedback: Its always appreciated when code examples on websites are complete. Your example isn't complete -- where's the `transact` import coming from, or `useQuery`? Little minor details that go far as your product scales out to a wider user base.
lol i was wondering the same thing
Re: Show HN: InstantDB – A Modern Firebase
#97[Firebase founder] The thing I'm excited about w/Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story). Good luck, Joe, Stopa and team!
This is an aside but “trifecta but with four” actually has an awesome name: “Superfecta”!
Re: Show HN: InstantDB – A Modern Firebase
#98I've been using Instant for about 6 months and have been very happy. Realtime, relational, and offline were the most important things for us, building out a relatively simple schema (users, files, projects, teams) that also is local first. Tried a few others unsuccessfully and after Instant, haven't looked back. Congrats team!
It's been great iterating with you AJ! Can't wait for what's ahead.
Re: Show HN: InstantDB – A Modern Firebase
#99Earlier quoted context omitted.
> Every object returned in a query is filtered by a 'view' rule. Similarly, every modification of an object goes through a 'create/update/delete' rule. Is that efficient for queries that return many rows but each user only has access to a few? Is there a specific reason to not use something like postgresql RLS that would do the filtering within the database where indexes can help?
Yes, reading the essay, that seems like the only "red flag" to me, the rest sound like a dream db. Not being able to leverage permission rules to optimize queries (predicate pushdown) seems like too big a compromise to me. It would be too easy to hit pathological cases, and the workaround would probably be something akin to replicating the permission logic in every query. Is there any plans to improve this?
Yes, in the near future we plan to convert CEL expressions to where clauses, which we attach to queries. This would push permissions to the query level, like postgres RLS.
Re: Show HN: InstantDB – A Modern Firebase
#100I've found triple stores to have pretty poor performance when most of your queries fetch full objects, or many fields of the same object, which in the real world seems to be very common. Postgres also isn't terrible, but also not brilliant for that use case. How has your experience been in that regard?
I've also found triple stores to have terrible performance, but it looks like the intended use-case for this (like Firebase) is rapid development, prototyping, and startups. You aren't going to generate enough traffic when you're building an MVP for this to be an issue.
And it's a hosted service, so the performance issues are for the InstantDB team to worry about, and they can fold it into the price they charge. It does mean that your application architecture will get locked in to something that costs a fortune in server bills when it gets big, but from InstantDB's POV, that's a feature not a bug. From your POV as a startup it may be a feature as well, since if you get to that point you'll like have VC to blow on server bills or use to rewrite your backend.