111–120 of 308 posts
Is it fully self-hostable? A lot of the time you have to hunt down small clauses in tools like these that state that some essential part of it can't be self-hosted.
I'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?
We're also working on an individual Postgres adapter. This would replace the underlying triple store with a fully relational Postgres database.
[1] https://www.usenix.org/system/files/conference/atc13/atc13-b...
Apparently I signed up for Instant previously but completely forgot about it. Only realized I had an account when I went to the dashboard to find myself still logged in. I dug up the sign up email and apparently I signed up back in 2022, so some kind of default invalidation period on your auth tokens would definitely make me a bit more comfortable.
Regardless, I'm still as excited about the idea of a client-side, offline-first, realtime syncing db as ever, especially now that the space has really been picking up steam with new entrants showing up every few weeks.
One thing I was curious about is how well the system currently supports users with multiple emails? GitHub popularized this pattern, and these days it's pretty much table stakes in the dev tools space to be able to sign in once and use the same account across personal accounts and orgs associated with different emails.
Looking at the docs I'm getting the sense that there might be an assumption of 1 email per user in the user model currently. Is that correct? If so, any plans to evolve the model to become more flexible?
Earlier 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…
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.
Earlier quoted context omitted.
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…
That would be really cool, but also really expensive - gyms have thousands (tens of thousands for some) of holds and they're usually cleaned by power washing and otherwise constantly abused. Maybe a middle ground would be computer vision? Not nearly as accurate or comprehensive of course, but a lot less hardware. (Most gyms in my experience have comprehensive camera coverage already for insurance purposes so I don't…
https://old.reddit.com/r/Spline3D/
Can see a simple route design widget in spline that can be a nifty ux for a climbing thing that uses the app ID.
Can you clone an Instant AppID?
I know I am just thinking out loud - but its pretty easy to envision how to use these neato tools and services that have been cropping up recently... Its inspiring.
> we tail postgres’ WAL to detect novelty and use last-write-win semantics to handle conflicts can you elaborate more on how you achieve this
We use the concept of 'topics'. A topic encodes: 'The part of the index a query cares about'. For example, given a query like "fetch user where id = 1", there could be a topic like "users:id:1" [1] When a WAL record comes in, we find queries by their topics, and invalidate them. This triggers a refresh. This is inspired by Figma's LiveGraph [2], which in turn is inspired by Asana's Luna [3]. The essays cover the idea…
1. first we would use the WAL records to invalidate queries that could be affected (with optimizations for fast matching) and requery the data
2. then we used the info from the WAL record to update the query in-memory without asking the DB for the new result, it worked for majority of the queries that can be reliably modeled outside of the DB
3. I believe after I left the team reverted to the re-query approach, as managing a system that replicates the DB behavior was not something they were excited to maintain, and as the DB layer got scaled out, extra DB queries were less of a downside
Data always needs a schema (unless it's random bits aka max entropy). The question is just where it's managed and enforced.
[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”!