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

231–240 of 308 posts

Re: Show HN: InstantDB – A Modern Firebase

#231

Post by nezaj »

blixt wrote: post #155

I saw the reference to “apps like Figma” and as one of the people that worked on Framer’s (also a canvas based app) database which is also local+multiplayer I find it hard to imagine how to effectively synchronize canvas data with a relational database like Postgres effectively. Users will frequently work on thousands of nodes in parallel and perform dragging updates that occur at 60 FPS and should at least be propag…

We do indeed batch frequent updates! Still many opportunities for improvements there, but we have a working demo of a team-oriented tldraw [1]

[1] https://github.com/jsventures/instldraw

Re: Show HN: InstantDB – A Modern Firebase

#232

Post by stopachka »

kabes wrote: post #189

From skimming through the site, it's not clear to me how the BE looks like. Obviously, the BE part is the hard/interesting part. Is that open-source and/or self deployable? Or is this fixed to a backend-as-a-service you guys provide?

The backend is completely open source. The code is in the `server` directory:

https://github.com/instantdb/instant/tree/main/server

Re: Show HN: InstantDB – A Modern Firebase

#233

Post by aidos »

RoboTeddy wrote: post #223
stopachka wrote: post #218

Earlier quoted context omitted.

You make a great point about missing .save(). Mark (our team member) has advocated for a callback-based API that looks a lot like what you landed on. It has the advantage of removing an import too! Question: how do you solve the 'draft' state issue that remolacha mentioned?

I haven’t seen a better solution than remolacha’s #2 (create separate temporary state for the form). Forms just inherently can have partially-finished/invalid states, and it feels wrong to try and kraal model objects into carrying intermediary/invalid data for them (and in some cases won’t work at all, eg if a single form field is parsed into structured data in the model)

Exactly that. It’s tempting to try to combine them - we’ve all been there. They’re subtly but inherently different, in my experience.

Re: Show HN: InstantDB – A Modern Firebase

#234

Post by stopachka »

monomers wrote: post #175

I'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?

> I'm missing clarity about how do I escape Instant DB when I need to, and how to make it part of a larger system.

Instant is completely open source. We have no private repos, so in the event that you want to run the system yourself, you can fork it.

> how to make it part of a larger system.

If you have an existing app, right now I would suggest storing the parts that you want to reactive on Instant.

We're working on a Postgres adapter. This would let you connect an existing database, and use Instant for the real-time sync. If you'd be interested in using this, reach out to us at founders@instantdb.com!

Re: Show HN: InstantDB – A Modern Firebase

#235

Post by terpimost »

terpimost wrote: post #110

If it's offline where the data is stored? IndexDB?

I saw in the docs that it uses IndexDB. Didn’t read carefully to understand how full is the replica and if it’s possible to make 100% offline app and what would be the limits of storage in the browser.

Also it would be nice to clarify memory consumption.

In general I’m glad such thing now exists!

Re: Show HN: InstantDB – A Modern Firebase

#236

Post by stopachka »

nikodotio wrote: post #163
stopachka wrote: post #103

Earlier quoted context omitted.

> Is the datalog engine exposed? Is there any way to cache parsed queries? We don't currently expose the datalog engine. You _technically_ could use it, but that part of the query system changes much more quickly. Queries results are also cached by default on the client. > Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this? There's no shorthand for recursi…

Definitely waiting for the datalog query to be exposed before I’d use this. If it was I would never use another database again. I think the amount of people coming from datascript/datomic who have to work in js and would prefer to use datalog instead of learning a new query language is big.

Noting this feedback, thank you.

Re: Show HN: InstantDB – A Modern Firebase

#238

Post by stopachka »

mizzao wrote: post #209

A really exciting product from many years ago was Meteor, which included a realtime database layer on top of Mongo that facilitated many very novel realtime apps. However, it didn't scale well in terms of performance to large numbers of users. Would anyone have thoughts on comparisons to Meteor?

Firebase, Parse, and Meteor were definitely inspirations for us.

Instant's main advantage is that we support relations. This means you can create data models like 'users -> comments -> apps'. For a bit more about why this matters, this is a good post:

https://mdp.github.io/2017/10/29/prototyping-in-the-age-of-n...

Re: Show HN: InstantDB – A Modern Firebase

#239

Post by stopachka »

rajatkulk wrote: post #138
stopachka wrote: post #126

Earlier quoted context omitted.

Imagine a you want to create a 'todo' list. If you used classic Rails, you'd be very productive. You could write most of your code on the server, and sprinkle some erb templates. However, if you want to improve the UX, you generally end up writing more Javascript. Once you do that, things get hairier: You create REST endpoints, funnel data into stores, normalize them, and denormalize them. Then you write optimistic u…

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 comment that goes deeper https://news.ycombinator.com/item?id=28158407

Re: Show HN: InstantDB – A Modern Firebase

#240

Post by aCoreyJ »

satvikpendem wrote: post #200
aCoreyJ wrote: post #198

Earlier quoted context omitted.

I use TinyBase for the client side store, it can sync with pretty much all the technologies people are talking about here https://tinybase.org/

Seems like that is only Javascript based. I like ElectricSQL and PowerSync because they're on the database layer and are client agnostic.

Yea you can use it client side and sync to PowerSync or electricsql if you aren't using js on the backend

https://tinybase.org/guides/persistence/database-persistence...

Post reply on HN