Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: InstantDB – A Modern Firebase

github.com

Post reply on HN
Print view View original

281–290 of 308 posts

Re: Show HN: InstantDB – A Modern Firebase

#281

Post by stopachka »

imslavko wrote: post #117
stopachka wrote: post #16

Earlier quoted context omitted.

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…

I worked on LiveGraph for a long time at Figma. We went through our own evolution: 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…

LiveGraph was an inspiration for us Slava, made me smile to see your comment. 2. is _really_ interesting.

I'll reach out to you on twitter; would love to learn more about your experience

Re: Show HN: InstantDB – A Modern Firebase

#282

Post by stopachka »

recoup4307 wrote: post #56
nezaj wrote: post #21

Earlier quoted context omitted.

We provide support for optimistic updates and offline mode out of the box. Without these it's a real schlep to build Linear-level applications. [1] [1] https://www.instantdb.com/essays/next_firebase#supabase-hasu...

This has been tried with Supabase using electricsql https://supabase.com/partners/integrations/electricsql Interestingly the team at electricsql are now rewriting their solution because it didn’t scale and was too complex https://next.electric-sql.com/about

Electric SQL had a different design. Instant is more inspired by systems like LiveGraph, which power apps as big as Figma. LiveGraph was itself inspired by Luna, which powers Asana.

Re: Show HN: InstantDB – A Modern Firebase

#283

Post by stopachka »

bigblind wrote: post #47

This looks very cool! I'm slightly worried about permissions evaluating to "true" if they're not specified. I think this will lead to a lot of actions being accidentally allowed.

Thank you!

We wanted to lean towards a faster getting started experience. We are thinking about options to change the default, or introducing a kind of 'wildcard' in permissions.

Re: Show HN: InstantDB – A Modern Firebase

#286

Post by Chipshuffle »

stopachka wrote: post #275
Chipshuffle wrote: post #274

I‘m wondering how this compares to convex ( https://www.convex.dev/ )

Both convex and Instant let you build apps quickly without worrying about the backend. Where Instant differs, is that queries and transactions can run on the client: you get optimistic updates and offline mode by default. On the other hand, convex lets you define queries as functions that can run on the edge. I haven't used convex deeply, but this is my understanding.

Thank you so much! I’m a first time builder of a bigger CRUD app. While I’m happy to build it with traditional methods the first time (REST API, SSE, auth etc.) I would love to use offers like Instant or Convex in my next projects.

Both look really promising in my opinion.

(Edited for typos)

Re: Show HN: InstantDB – A Modern Firebase

#287

Post by WolfOliver »

mixmastamyk wrote: post #226
mattfrommars wrote: post #214

Earlier quoted context omitted.

> If you want offline mode, you worry about IndexedDB I don't understand the offline mode. If I was to make a single player offline game that runs on the browser, sure, offline mode makes sense and I want to store on client machine. But in the space of web apps, everything data needs to be synced with server db. Why would I want to store half of my to do list on client and other half on the server? The end goal is th…

So the user could keep working on a plane, when cable, or electricity is out, etc. Wants to experiment without inflicting changes on others, like dvcs. The user may not have “their data on your cloud” as an end goal. There’s a paper by Kleppman et al about local-first apps that is worth a read.

I'am always skeptical about this offline use case. Is it really as important as the CRDT community claims?

If you are on a plain, you could also just read a book.

Re: Show HN: InstantDB – A Modern Firebase

#288

Post by refset »

koito17 wrote: post #273
stopachka wrote: post #248

Earlier quoted context omitted.

> but it did surprise that someone would decide to use this syntax over a syntax used in other Datalog engines (and predating Datomic itself). We are clojure programmers, so our introduction to Datalog was actually though Datomic in 2014. We are fans of other query syntaxes (SparQL looks cool too), but we find Datomic's flavor the most ergonomic for us, and it's an added win for us that we can express queries as plai…

Thanks for the answer. I learned that the backend is implemented in Clojure, so presumably de-serializing JSON means client-side queries trivially become Clojure data usable for databases like Datomic, Datascript, etc. I noticed Postgres is used as the storage layer for Instant's triple store. I'm still curious why making a custom triple store over using e.g. XTDB v1. Like Instant's data store, XTDB is schemaless, an…

> What were the show stoppers in adopting solution like XTDB?

#1 would be the lack of a production ready DBaaS (like Aurora offers for Postgres), if I had to guess.

Re: Show HN: InstantDB – A Modern Firebase

#289

Post by unsupp0rted »

randomdata wrote: post #224
unsupp0rted wrote: post #219

Earlier quoted context omitted.

Building a logistics app, I wish I could query in Firebase for items that don’t have a “shipped” field. But I can’t.

Technically you can: Scan all of the documents. A "relational query language" would have to do the same thing.

That wouldn’t be querying though, right?

Grabbing all the docs in the db into my controller and filtering down that array is what Firebase makes me do instead of writing queries.

Re: Show HN: InstantDB – A Modern Firebase

#290

Post by randomdata »

unsupp0rted wrote: post #289
randomdata wrote: post #224

Earlier quoted context omitted.

Technically you can: Scan all of the documents. A "relational query language" would have to do the same thing.

That wouldn’t be querying though, right? Grabbing all the docs in the db into my controller and filtering down that array is what Firebase makes me do instead of writing queries.

> That wouldn’t be querying though, right?

Why not? You're asking a question, of sorts, and getting an answer from the result. That's the literal definition of querying.

> Grabbing all the docs in the db into my controller and filtering down that array is what Firebase makes me do instead of writing queries.

A query language is just an abstraction. One you can have in your code. At some point you still need to "grab all the docs into a controller and filter them down", though. You could push that step into the Firebase service, but it would still have to do the same thing you're doing. There is no magic.

Better would be to provide something indexable so that you don't have to go through all the docs, but you can't index that which does not exist.

Post reply on HN