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

31–40 of 53 posts

Re: A Graph-Based Firebase

#31

Post by pezo1919 »

stopachka wrote: post #29
pezo1919 wrote: post #24

Earlier quoted context omitted.

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/

Thank you! Having one of my projects died to it (lack of migrations, offline-first) I had promised myself I'll first solve that problem before writing a meaningful line of business code in a future project. :)

Re: A Graph-Based Firebase

#32

Post by eurasiantiger »

stopachka wrote: post #16
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.

This comment thread looks like it could benefit from Dgraph, which is an open source GraphQL-layer database built on top of a RDF n-quad store (badger).

Re: A Graph-Based Firebase

#36

Post by habosa »

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 get started with. I’m very excited about this project.

Re: A Graph-Based Firebase

#37

Post by jinjin2 »

Another product that does all this (relations, reactivity, offline, permissions, sync, etc…) really well, is Realm.

It is beyond awesome for building mobile apps, but mobile only. Annoyingly they have never released a web version. No idea why.

I would still look into it for ideas. It is super powerful and a joy to work with. I would love to see something like that working in the browser.

Re: A Graph-Based Firebase

#38

Post by lf-non »

revskill wrote: post #6
alexashka wrote: post #4

Earlier quoted context omitted.

Hasura does not offer syncing. Syncing is hard :)

Aha, yup. My way of offline, is just store all commands offline and sync the command only. Syncing the view is hard.

We used to do this for an app, but moved away from that eventually, because:

1. You need to support old command (and payload schema) indefinitely. Or need migrations for those instead.

2. In highly interactive apps, this needs a lot of chatter. A peer that is offline for a few weeks may need to sync many many commands before they get to the latest version, and people generally don't like waiting on sync to complete. And syncing while users are interacting with the app gets complex pretty fast.

We tried to alleviate 2 using things like compaction and merging of commands, but eventually it ended up being much more complex than syncing the latest ui state which was a much smaller payload for our case.

It also eliminated many of corner case bugs in our command history compaction logic where some clients could end up in an invalid or unexpected states in very specific scenarios which were very hard to reproduce. Doing aggressive compaction while retaining effective order can get tricky if the object model is complex and deeply interlinked.

Not saying it is not a valid approach, but Ymmv.

Re: A Graph-Based Firebase

#39

Post by ar7hur »

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.

Re: A Graph-Based Firebase

#40

Post by tlarkworthy »

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 seems like a decent compromise between SQL and no-SQL that could actually work out! Awesome idea!

Post reply on HN