Replies: 1 comment 7 replies
-
Yeah. Not gonna lie:
I get that this is compelling. It's outside of our current vision and I don't know if/how there is a future there for us. It's hard to get all these features in the same box. Buttery smooth multiplayer just wants different architecture than a distributed database, for example. I would really like to find ways to draw lines around smaller primitives and let people compose things, rather than having to do/be everything. For example it's perfectly reasonable to write an old fashioned query on top of a Replicache backend. Postgres can index JSON. You can marry this to local queries quite readily, just requires some glue. Especially if you only need this for a few cases, it's easy enough. Getting to your question, I think there are three parts to it:
2 and 3 are easy: (2): the way you do today. (3) sure but you have to do it manually. Perhaps patterns will emerge over time and those patterns might turn into features, but we don't have enough experience yet to say. === For (1) there is no reason we can't build a Firebase-style query API on top of Replicache. We have considered this. I think we will probably do it eventually. But a lot of developers are comfortable and like the "state management" model instead, like Jotai, Zustand, etc. This covers many of the same use cases and is less work for us to implement. @ingar is working on adapting Repliear to use Jotai to demonstrate the pattern, then we will look at it and decide if the dx is there or if we want to do anything more first-class in Replicache right now. |
Beta Was this translation helpful? Give feedback.
-
The shift, in web development, to local-first data, zero-latency UI and realtime multiplayer, seems pretty much inevitable at this point. This is especially true given that, with the right supporting ideas such as those in Replicache, you actually end up with an easier programming model compared to the old client/server model of the typical Rails/PHP app.
But one piece of the stack that was central to the old way might be lost - the database's query engine. Sometimes we wrote raw SQL, sometimes via an abstraction such as Rails' ActiveRecord, but we always wrote queries.
As far as I understand, part of the argument for this being OK might be that everything is in memory. We can get the same results with plain old JavaScript: map, filter, helper functions...
But there's two distinct downsides compared to a proper query engine. One is expressivity - a good query language gives you tons of power to express complex rules and constraints succinctly. The other is indexing: the ability to just declare what I'd like indexed, and have the query engine figure out how to efficiently use those indexes to optimise my queries, is another huge productivity boost.
I'm aware of two serious ideas to solve this problem, and bring powerful queries to the local-first/zero-latency/multiplayer party.
One is Instant (https://www.instantdb.com) which aims at a similar value-prop to Replicache but will also, they say, bring datalog to javascript. Datalog in the browser already exists in fact, in DataScript, but ClojureScript remains very niche.
The other is more of a general idea that I saw crop up in a HN thread the other day. Supposedly extensions to the browser filesystem API are coming that will allow sufficiently high performance read/write that compile-to-web-assembly "real" databases will be coming. i.e. SQLite or even Postgres running inside the browser sandbox. As I understand this is all possible already but without the improved file APIs the results are not really practical.
So I'm wondering what the Replicache story is going to be here. Given that Replicache wants to own the low-level client side storage, it would seem it will have to get involved in the query business.
There's one more idea here which I think is going to become extremely important. This is the idea of the "vast key-space" that the app "windows" in to. (See https://roamresearch.com/#/app/aboodman/page/X3mhH5OCs from @aboodman). Obviously, if you're building Twitter, you're not going to sync the entire thing to everyone's browser, and there are no obvious boundaries to chunk things up into spaces. This can all be solved in Replicache because of BYOB, but I'm sure in the future this will become the responsibility of the platform, not something I have to implement myself. Having queries be part of the platform seems to me the right way to do this. If I can execute a single query and get back results from my local cache, if they are there, and from the server if they are not, and if the platform then understands that the results of that query are now part of my window, that would be something.
This was the subject of an essay that got a lot of interest in the Clojure community, by the DataScript guy:
https://tonsky.me/blog/the-web-after-tomorrow/
Someone is going to take a stab at something like this soon enough. The Instant guys seem well placed to go this way and I'd bet they have plans.
With Reflect, Replicache is taking a step towards being the "whole data platform" as opposed to just a client library. How might this develop?
Beta Was this translation helpful? Give feedback.
All reactions