Live data from Hacker News

A Graph-Based Firebase

stopa.io

41–50 of 53 posts

Re: A Graph-Based Firebase

#41
The basic intuitions they have are correct, but if feels like there is a serious lack of or disregard for the theoretical background needed to talk about this stuff properly.

> (pull db '[* {:team/task [* {:task/owner [*]}]}] team-id)

That's not Datalog. It's kind of a mix between a conjunctive query and a regular path query.

Datalog isn't even really a query language. It's a class of query languages with a specific expressive power.

Whereas SQL is essentially conjunctive queries with non-stratified Negation, Datalog is recursive conjunctive queries with no or only stratified negation.

Datalog also has nothing to do with triples, they are two completely orthogonal concepts.

I've been slaving away in this very space for years and this post heavily reminds my of my initial hubris. Building something truly foundational that can be universally implemented and perform in all potential target languages from Javascript, to WASM via e.g. Zig and Rust, while at the same time being both conceptually simple, and easy to implement, is really really really difficult with a lot of pain lurking in the details.

Re: A Graph-Based Firebase

#42
post #41

The basic intuitions they have are correct, but if feels like there is a serious lack of or disregard for the theoretical background needed to talk about this stuff properly. > (pull db '[* {:team/task [* {:task/owner [*]}]}] team-id) That's not Datalog. It's kind of a mix between a conjunctive query and a regular path query. Datalog isn't even really a query language. It's a class of query languages with a specific…

do you write about your findings and ideas? i would be interested to read more.

Re: A Graph-Based Firebase

#43
post #41

The basic intuitions they have are correct, but if feels like there is a serious lack of or disregard for the theoretical background needed to talk about this stuff properly. > (pull db '[* {:team/task [* {:task/owner [*]}]}] team-id) That's not Datalog. It's kind of a mix between a conjunctive query and a regular path query. Datalog isn't even really a query language. It's a class of query languages with a specific…

do you write about your findings and ideas? i would be interested to read more.

I regularly regret not writing a blog...

But if you want to talk about some ideas feel free to drop by at discord.gg/tribles

Re: A Graph-Based Firebase

#44
One possible solution to the "sync" layer (how do you sync the local db shard with the global consensus) looks like this: https://www.researchgate.net/publication/359578461_Continuou... (2022)

also need to fit whole view updates into 16ms frame budget (not just one query but every query on the page that is impacted by a change as well as downstream reactive views). At some tipping point it can be faster to move relational queries to the cloud (sacrificing local first), and treat local first as an edge case (not all page components need to be live in offline mode - depending on the app, you may just need document edits not relations)

Re: A Graph-Based Firebase

#45
post #41

The basic intuitions they have are correct, but if feels like there is a serious lack of or disregard for the theoretical background needed to talk about this stuff properly. > (pull db '[* {:team/task [* {:task/owner [*]}]}] team-id) That's not Datalog. It's kind of a mix between a conjunctive query and a regular path query. Datalog isn't even really a query language. It's a class of query languages with a specific…

[deleted]

Re: A Graph-Based Firebase

#46

One possible solution to the "sync" layer (how do you sync the local db shard with the global consensus) looks like this: https://www.researchgate.net/publication/359578461_Continuou... (2022) also need to fit whole view updates into 16ms frame budget (not just one query but every query on the page that is impacted by a change as well as downstream reactive views). At some tipping point it can be faster to move relat…

The research paper looks intriguing. I'll look into it. I am not as convinced about moving queries to the cloud, when it comes to the north stars of Figma / Linear / Notion. It would be hard to get the same kind of UX.

Re: A Graph-Based Firebase

#47
post #36

I used to work on Firebase. I also use Firebase heavily in my work and personal projects. I am normally quite skeptical of “Firebase but X” projects because they often seem to be running head first into the issues that the Firebase team so skillfully avoided. This isn’t one of those projects. The author of this essay clearly gets what you need to actually build a backend for a modern app that’s also simple enough to…

Thank you for the kind words.

Re: A Graph-Based Firebase

#48

At Firebase we sometimes pondered the feasibility of a SQL version, but the semantics of SQL seem littered with semantic footguns that don't lend themselves to offline, secure, scalable and event driven distributed applications. We know everybody wanted better query expressivity but delivering that in a mobile friendly, clienside, secure package was very difficult to see the path to. tripletstore/datalog actually see…

I'm encouraged reading this. Thank you.

Re: A Graph-Based Firebase

#49
post #39

I would really use this for many of my projects! For project A, I used Firebase which was great initially but eventually ran into the limitations well described in Stopa's essay. For project B, I decided to write everything from scratch but the amount of work it required is crazy, and of course the result in quite brittle.

Thrilled to hear this, thank you :).

Re: A Graph-Based Firebase

#50

Does Instant have any plans for iOS and Android SDKs? One of the biggest wins with Firebase is that it's really easy to integrate across platforms.

Yes! Right now one of our users implemented an RN integration. We'd love to support iOS and Android soon.
Post reply on HN