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

A Graph-Based Firebase

stopa.io

Post reply on HN
Print view View original

21–30 of 53 posts

Re: A Graph-Based Firebase

#21

Post by kevmo314 »

stopachka wrote: post #18
kevmo314 wrote: post #5

> These triples say that the Layer with id 1 has a fontSize 20 and backgroundColor blue. Since they are different rows, there’s no conflict. This sounds a lot like Bigtable ( https://cloud.google.com/bigtable ), which also does last-write-wins conflict resolution layer. So this is adding a GraphQL + frontend layer to it?

I'm not as familiar with Bigtable's data model. Afaik they don't use a triple-store like system, but their data model does look interesting. [^1] The concept you have is on point though. You can think that we've moved a graph-database over to the frontend, and introduces a GraphQL-like language for it. [^1]: https://static.googleusercontent.com/media/research.google.c...

Very cool, super exciting to see a clean frontend to it. As a big Firebase fan, I'm looking forward to what you build :)

Re: A Graph-Based Firebase

#22

Post by pezo1919 »

jitl wrote: post #10
pezo1919 wrote: post #9

Are transactions supported in that solution or in the mentioned Datalog related ecosystem? I have built my own similar reactive inmemory triple store with typescripts type safety, but then I realized I still need transactions which are a bit of a pain, because transactions are bundling the otherwise separete triplets, so the atomic, independent logic of triplets and related effects breaks a bit. (I am sure it's solva…

The example code uses a `transact` function. But it really depends on what you mean by “transaction”. We don’t use a triple store at Notion, but we do use an abstraction that ensures a collection of operations either all succeed or all fail. We don’t support “interactive” transaction, where you can read, modify, write as an atomic group. This just isn’t desirable in a multiplayer or offline system - in cases we need…

Cool, thanks! Now a question: how a dev picks up related knowledge? I have a BSc and extra 7 years in development, but this area was totally gray to me. My motivation was only to come up a scalable solution for offline first apps with some kind of automatic persistence support, so at the end of the day my design goals were quite similar. How do you come up with stuff at notion? Are there must have books or just going with gut, experience and existing solutions you are aware about?

Re: A Graph-Based Firebase

#23

Post by stopachka »

antidnan wrote: post #20

Very cool! What're the differences between this and something like Replicache?

I haven't looked too deeply at Replicache, but the two differences as I understand it:

1. Replicache is a layer you add over an existing backend. Instant handles the backend. 2. The expose a key-value store. We expose a graph store.

Both 1&2 have pros and cons each way. I think we're inspired by the same problems, and their docs are really well done.

Re: A Graph-Based Firebase

#24

Post by pezo1919 »

stopachka wrote: post #15
pezo1919 wrote: post #9

Are transactions supported in that solution or in the mentioned Datalog related ecosystem? I have built my own similar reactive inmemory triple store with typescripts type safety, but then I realized I still need transactions which are a bit of a pain, because transactions are bundling the otherwise separete triplets, so the atomic, independent logic of triplets and related effects breaks a bit. (I am sure it's solva…

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)

Re: A Graph-Based Firebase

#25

Post by pezo1919 »

stopachka wrote: post #15
pezo1919 wrote: post #9

Are transactions supported in that solution or in the mentioned Datalog related ecosystem? I have built my own similar reactive inmemory triple store with typescripts type safety, but then I realized I still need transactions which are a bit of a pain, because transactions are bundling the otherwise separete triplets, so the atomic, independent logic of triplets and related effects breaks a bit. (I am sure it's solva…

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…

Oh another thing: do you guys have twitter or something? :) Would love to follow the project and devs too.

Re: A Graph-Based Firebase

#26

Post by stopachka »

pezo1919 wrote: post #25
stopachka wrote: post #15

Earlier 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…

Oh another thing: do you guys have twitter or something? :) Would love to follow the project and devs too.

We don't have a business twitter, but I'm @stopachka, and my cofounder is @JoeAverbukh. Thank you for the kind words :)

Re: A Graph-Based Firebase

#27

Post by pezo1919 »

stopachka wrote: post #26
pezo1919 wrote: post #25

Earlier quoted context omitted.

Oh another thing: do you guys have twitter or something? :) Would love to follow the project and devs too.

We don't have a business twitter, but I'm @stopachka, and my cofounder is @JoeAverbukh. Thank you for the kind words :)

Oh I just realized I have been already following you. :) Is that possible that you've been using cyclejs/xstream at some point? :) Or maybe from Future of Programming slack (or how it is called. :))

Re: A Graph-Based Firebase

#28

Post by stopachka »

pezo1919 wrote: post #27
stopachka wrote: post #26

Earlier quoted context omitted.

We don't have a business twitter, but I'm @stopachka, and my cofounder is @JoeAverbukh. Thank you for the kind words :)

Oh I just realized I have been already following you. :) Is that possible that you've been using cyclejs/xstream at some point? :) Or maybe from Future of Programming slack (or how it is called. :))

I haven't checked these out, but I'm definitely intrigued. Peaked at cyclejs -- I'm a fan of FRP, and more recently structured concurrency.

Re: A Graph-Based Firebase

#29

Post by stopachka »

pezo1919 wrote: post #24
stopachka wrote: post #15

Earlier 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)

Migrations are very tough when you go offline-first. Cambria [^1] is an interesting read. For Instant, we are schemaless and think about offline more like a cache. In our case it's less of a problem.

[^1]: https://www.inkandswitch.com/cambria/

Re: A Graph-Based Firebase

#30

Post by pezo1919 »

stopachka wrote: post #28
pezo1919 wrote: post #27

Earlier quoted context omitted.

Oh I just realized I have been already following you. :) Is that possible that you've been using cyclejs/xstream at some point? :) Or maybe from Future of Programming slack (or how it is called. :))

I haven't checked these out, but I'm definitely intrigued. Peaked at cyclejs -- I'm a fan of FRP, and more recently structured concurrency.

Isn't FRP just naturally superior? :)
Post reply on HN