Looks great! How is the migration story when schema changes are needed? How do you deal with old clients?
Show HN: InstantDB – A Modern Firebase
171–180 of 308 posts
Re: Show HN: InstantDB – A Modern Firebase
#172This seems like a game changer for real time applications. We have been using Firebase mostly for it RTDB and websocket kind of implementation without actually maintaining websocket at the backend. This takes things a step ahead.
Re: Show HN: InstantDB – A Modern Firebase
#173I'm using Hasura connected to a postgres DB at the moment. What you have built sounds great.
Hasura offer a self hosted solution so that I know if they decide to close shop for whatever reason, I'm not stuck in the lurch and have to reengineer my entire solution. Do you offer this now or are you planning to?
Re: Show HN: InstantDB – A Modern Firebase
#174Earlier quoted context omitted.
Tetrafecta would be cooler
Cursory googling says tetra is Greek and perfect is Latin, so its a bastard word like erogenous or television.
Side point: television is a bastard word, but erogenous is not Greek eros + Latin genus; it's all greek (ἐρωτογενής — it would be erotogenous in English since the root of the word eros is erot- , but the extra syllable was dropped; another example of differentiated transliteration is φωτογενής which became photogenic instead of photogenous).
Re: Show HN: InstantDB – A Modern Firebase
#175I'm missing clarity about how do I escape Instant DB when I need to, and how to make it part of a larger system.
Say I have an InstantDB app, can I stream events from the instant backend to somewhere else?
Re: Show HN: InstantDB – A Modern Firebase
#176Kind of like Horizon + RethinkDB? which sadly disappeared out of nowhere
Re: Show HN: InstantDB – A Modern Firebase
#177Databases accessed directly from javascript in the browser, may change yet again how multi user webapps is being written. Looking forward to playing with InstantDb.
Re: Show HN: InstantDB – A Modern Firebase
#178[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”!
"Supafecta"
Re: Show HN: InstantDB – A Modern Firebase
#179Earlier quoted context omitted.
Cursory googling says tetra is Greek and perfect is Latin, so its a bastard word like erogenous or television.
Side point: television is a bastard word, but erogenous is not Greek eros + Latin genus; it's all greek (ἐρωτογενής — it would be erotogenous in English since the root of the word eros is erot- , but the extra syllable was dropped; another example of differentiated transliteration is φωτογενής which became photogenic instead of photogenous).
I have just written an essay about the word water in the sibling post comments.
One thing I discovered in the process is that the word water comes to english all the way from Proto Indo European. The word hydro, however, comes from ancient greek, which comes from the same PIE word for water.
Re: Show HN: InstantDB – A Modern Firebase
#180Earlier 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…
This would be very cool, my first thought is that this is something that could be added to something like a kilter board. There you already have a high cost setup where holds are normalised across a huge number of installations, integrated apps, etc. Some more premium option for force sensors per hold, I'm sure climbers would go pretty nuts for all the force data given how much people like the same kind of thing just on fingerboards.