Earlier quoted context omitted.
Meteor certainly inspires us!
What would you say are your biggest differences?
Relations, and less vertical integration
A Graph-Based Firebase
51–53 of 53 posts
Re: A Graph-Based Firebase
#52Are there any plans to open source instant in the future ?
We like the open-core mode. We have definite plans to open-source the client. Still think the best way to do this for the server.
Re: A Graph-Based Firebase
#53Earlier quoted context omitted.
As jitl points out, in multiplayer settings, what you need is some way to commit a series of transactions all-together or not at all. We support this. In the case where you want to read the database inside your transaction, we take inspiration from Datomic. Datomic runs all mutations in one high-memory box. You can provide functions that run in that box. This way, you can guarantee that the reads inside your transact…
Yes exactly this UX issue bothers me a lot, I wouldn't even go there. :D What about migrations? Do you support? That's another thing I need in my offline first project, one of my other project has died because the lack of it. (I need something which plays well with Expo.io)
I'm working on building a database in the same space as InstantDB. Currently, it's an "object/graph database using Protobuf". There's a check to ensure updated Protobuf definitions are backwards-compatible. Of course, this still implicitly relies on using Protobufs correctly (i.e. a missing value is the same as zero/empty/null/nil), even though I'm trying to make it safe by default.
I'm curious what your needs are. Would you mind elaborating on what kind of migrations your project would have needed to not die?