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

291–300 of 308 posts

Re: Show HN: InstantDB – A Modern Firebase

#291

Post by rajatkulk »

stopachka wrote: post #239
rajatkulk wrote: post #138

Earlier quoted context omitted.

I'm a bit naive here, so asking a stupid question. I have an `offline only` app where I read things from the file system (markdown) and currently store them in a redux state for accessing filepaths and ids. I've been planning to move to indexedDb using dexie for kinda the same use case of easier transaction, not maintaining a huge redux state (16k lines or so), and improved performance. Now if my app is not supposed…

I would not recommend using IndexedDB as your primary storage. This is because browsers can sometimes delete the underlying store (there are various reasons for this, but one is that the user is running out of space on their machines) [1] If you have access to the file system, I would consider using SQLLite to store everything. If you end up then wanting auth / collaboration, you could try Instant. [1] This is a good…

Ooo nice read! Since I use tauri, mac would have the browser as safari, and since it's a purely offline app, losing that is disastrous!

I'll move over to SQLite in that case, since that can atleast be persisted! Thanks!

Re: Show HN: InstantDB – A Modern Firebase

#292

Post by RoboTeddy »

(1) This is awesome. Feels like this wraps enough complexity that it won't just be a toy / for prototyping.

(2) When a schema is provided, is it fully enforced? Is there a way to do migrations?

Migrations are the only remaining challenge I can think of that could screw up this tool long-term unless a good approach gets baked in early. (They're critically important + very often done poorly or not supported.) When you're dealing with a lot of data in a production app, definitely want some means of making schema changes in a safe way. Also important for devex when working on a project with multiple people — need a way to sync migrations across developers.

Stuff like scalability — not worried about that — this tool seems fundamentally possible to scale and your team is smart :) Migrations though... hope you focus on it early if you haven't yet!

Re: Show HN: InstantDB – A Modern Firebase

#293

Post by mixmastamyk »

WolfOliver wrote: post #287
mixmastamyk wrote: post #226

Earlier quoted context omitted.

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.

It’s about being in control of your data. git folks thought so too, and why not? The paper mentioned is approachable.

Re: Show HN: InstantDB – A Modern Firebase

#294

Post by stopachka »

RoboTeddy wrote: post #292

(1) This is awesome. Feels like this wraps enough complexity that it won't just be a toy / for prototyping. (2) When a schema is provided, is it fully enforced? Is there a way to do migrations? Migrations are the only remaining challenge I can think of that could screw up this tool long-term unless a good approach gets baked in early. (They're critically important + very often done poorly or not supported.) When you'…

Thank you for the kind words!

> When a schema is provided, is it fully enforced?

Right now the schema understands the difference between attributes and references. If you specify uniqueness constraints, they are also enforced. We haven’t supported string / number yet, but are actively working towards it. Once that’s supported, we can unlock sort by queries as well!

> Migrations though... hope you focus on it early if you haven't yet!

We don’t have first class support for migrations yet, but are definitely thinking about it. Currently folks use the admin SDK to write migration scripts.

Question: do you have any favorite systems for migrations?

Re: Show HN: InstantDB – A Modern Firebase

#295

Post by RoboTeddy »

stopachka wrote: post #294
RoboTeddy wrote: post #292

(1) This is awesome. Feels like this wraps enough complexity that it won't just be a toy / for prototyping. (2) When a schema is provided, is it fully enforced? Is there a way to do migrations? Migrations are the only remaining challenge I can think of that could screw up this tool long-term unless a good approach gets baked in early. (They're critically important + very often done poorly or not supported.) When you'…

Thank you for the kind words! > When a schema is provided, is it fully enforced? Right now the schema understands the difference between attributes and references. If you specify uniqueness constraints, they are also enforced. We haven’t supported string / number yet, but are actively working towards it. Once that’s supported, we can unlock sort by queries as well! > Migrations though... hope you focus on it early if…

Nice!

Re: favorite systems for migrations — not really; I've always just kind of not used one, or rolled my own. Desiderata:

* fully atomic (all goes through or none goes through)

* low-boilerplate

* can include execution of arbitrary application code — data-query-only only migrations feel kind of limiting.

* painless to use with multiple developers multiple of which might be writing migrations

Re: Show HN: InstantDB – A Modern Firebase

#296

Post by stopachka »

RoboTeddy wrote: post #295
stopachka wrote: post #294

Earlier quoted context omitted.

Thank you for the kind words! > When a schema is provided, is it fully enforced? Right now the schema understands the difference between attributes and references. If you specify uniqueness constraints, they are also enforced. We haven’t supported string / number yet, but are actively working towards it. Once that’s supported, we can unlock sort by queries as well! > Migrations though... hope you focus on it early if…

Nice! Re: favorite systems for migrations — not really; I've always just kind of not used one, or rolled my own. Desiderata: * fully atomic (all goes through or none goes through) * low-boilerplate * can include execution of arbitrary application code — data-query-only only migrations feel kind of limiting. * painless to use with multiple developers multiple of which might be writing migrations

That's a great list, thank you! We are thinking along similar lines; looking forward to when we can design this portion. If you have other feedback, please let us know.

Re: Show HN: InstantDB – A Modern Firebase

#297

Post by jgeurts »

This looks great! Is there a way to sync with an api? For instance, my site currently has a rest based api with a non-Postgres backed db but I’d like to add offline, sync, real-time capabilities. Is there an option to sync the updates outside of the Postgres store?

Re: Show HN: InstantDB – A Modern Firebase

#298

Post by zarathustreal »

codersfocus wrote: post #58

For those looking for alternatives to the offline first model, I settled on PowerSync. Runner up was WatermelonDB (don't let the name fool you.) ElectricSQL is still too immature, they announced a rewrite this month. CouchDB / PocketDB aren't really up to date anymore. Unfortunately this area is still immature, and there aren't really great options but PowerSync was the least bad. I'll probably pair it with Supabase…

> CouchDB / PocketDB aren’t really up to date anymore.

Source? I’ve been using CouchDB as my game world DB for years, works fine for me?

Post reply on HN