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

11–20 of 53 posts

Re: A Graph-Based Firebase

#15

Post by stopachka »

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 transaction have the latest value. There's a lot of UX to figure out there, and this would be something to try to avoid in an offline-available setting.

Re: A Graph-Based Firebase

#16

Post by stopachka »

fhur wrote: post #7

Very interesting. I came to many similar conclusions completely independently, even attempted to build a typesafe in memory datalog in typescript. I also came to the conclusion that just exposing datalog triples as a query language would never feel right and tried to expose a graphql like language that generated the datalog triples. IMO react relay offers a great similar offering with their normalized cache. Relay ha…

Thank you for the kind words! Both Joe and I are around if you any feedback. In terms of type-safety, we're thinking of it as an added layer. I'm optimistic, that since InstaQL provides objects as the interface, we could have more idiomatic types down the road.

Re: A Graph-Based Firebase

#17

Post by stopachka »

revskill wrote: post #2

I use Hasura for this purpose. With some hooks, you can achive offline mode, too. You need a bit tricky hacks to use Hasura permission system the way you want, though.

Thanks for taking a look at the essay. As you mentioned, indeed it's possible if you store all commands, and sync with IndexedDB. The edge cases get quite complicated though. We're optimistic that a local layer that handles transactions and sync could makes things a lot easier.

Re: A Graph-Based Firebase

#18

Post by stopachka »

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...

Re: A Graph-Based Firebase

#19

Post by paulgb »

fernandohur wrote: post #8

Another project with similar goals in mind: https://paulbutler.org/2020/the-webassembly-app-gap/ Also backed by YC.

Thanks for the mention!

For some context, that blog post discusses what I saw as missing pieces of the stack circa 2020. The startup I’m building (https://driftingin.space) is roughly the “lambda for websockets” part, whereas Instant is closer to the “generalized CRDT data layer part”.

Post reply on HN