[thingortwo]

this is not local/offline first and also seems massively over-engineered for the type of apps that might use it since now you can't use plain sql and need to learn your ZQL domain specific language/library. I mean look at this code from raw sql example:

```

const markAllAsRead = defineMutator( z.object({ userId: z.string() }), async ({tx, args: {userId}}) => { // shared stuff ...

    if (tx.location === 'server') {
      // `tx` is now narrowed to `ServerTransaction`.
      // Do special server-only stuff with raw SQL.
      await tx.dbTransaction.query(
        `
      UPDATE notification
      SET read = true
      WHERE user_id = $1
    `,
        [userId]
      )
    }
  }

)

```

[aboodman]

yeah we specifically decided not to be local/offline-first because these add huge complexity that is not needed for the type of apps we want to support. I spoke about this a bit here if you are interested: https://www.youtube.com/watch?v=86NmEerklTs&t=1764s

As for ZQL:

a) basically all of our customers already use Drizzle/Prisma. So they are very used to custom DSLs, and like them. I know, I was surprised to!

b) You typically use the same code client-side and server-side. There's no branching. The example you pasted is showing an escape hatch for when you want to use custom SQL. The option is there, but it's not the common experience.

This is what a typical mutator looks like:

  ```ts
  // src/mutators.ts
  import {defineMutators, defineMutator} from '@rocicorp/zero'
  import {z} from 'zod'

  export const mutators = defineMutators({
    updateIssue: defineMutator(
      z.object({
        id: z.string(),
        title: z.string()
      }),
      async ({tx, args: {id, title}}) => {
        if (title.length > 100) {
          throw new Error(`Title is too long`)
        }
        await tx.mutate.issue.update({
          id,
          title
        })
      }
    )
  })

```

We are trying to make apps like Notion, Linear, Superhuman easier to create. These apps all uses custom-built sync engines that took their teams many person-years of effort to construct.

Whether this complexity is worth it depends on how badly you want instantaneous response. If you do, you will end up using sync one way or other, and you will end up with something roughly like Zero mutators.

[thingortwo]

Most of the improvement opportunity is in the offline-first the cache or fast reads already have lots of solutions by using zero I lock my self in thinking in your library's design language and not in terms of what I already know that is raw SQL. If your happy/convenient/recommended path is ZQL then of course people will choose it and only later realize it only works for simpler queries like most ORMs I've been burnt by prisma before and now I don't touch any ORMs and simply use raw sql + sqlc (type safety + auto repo layer from your query.sql)

I would use these DSL if they provide 10x improvement but it seems to me like a downgrade in every way I will need to rely on you to keep this thing running 10 years down the road and hope you are still in business. Whereas raw SQL will probably work as is since past performance is usually indicator of future and sqlite/postgres are 25 years old and if I recall correctly you already had this similar project that is now no longer maintained: https://replicache.dev/ so this by default makes me trust this project less since it will touch critical parts of my app.

Also, imo the custom sync engine path is usually better because most of this turns into logical replication unless you are syncing simple notes and then teams already know what they need and a last-write-wins + row_id,table => changes_log tables isn't that hard the issue is usually that the client and server will need to duplicate functionality and I will be a lot more comfortable duplicating those using raw sql queries since you write those ones and use on both sides. Any half-sync or other optimizations usually just end up causing a lot of headaches in a relational db with foreign keys on.

So, I would use something like this only if it is a sidecar process like litestream seamlessly doing it's thing vs becoming a main concern in my app core. But that again is the issue logical replication vs physical replication and how can a sidecar know the intent.

[aboodman]

We do support Replicache: https://i.imgur.com/R1pR58i.png.

But I get it. Unfortunately something like this cannot be a sidecar, or at least I do not know how to make it one. It's central to your app in the way that React is.

Fortunately the category is expanding and there are several sync engines that plug in exactly how Zero does - by replicating your database. You can switch between them easily. So as long as you think you do need a sync engine you aren't that married to Zero specifically.

Here's a demo of that!

https://youtu.be/SNAHZZo21To?si=wgDgxQpbRr-qj-A-&t=1571

[thingortwo]

Which is exactly why I said this problem is better solved by your own custom sync engine which when scoped to your own problem is not as hard to build as you think the most simpler and effective version is just a change_log and replaying or occasional full sync.

My own app uses something like this and I have yet to encounter any issue whereas I did initially look into using electricsql , zero sync , instantdb , triplit but the amount of lock-in or DSL was not my cup of tea and most of these are now doing "AI Agents" marketing instead of their core original problem which further erodes any trust.

[kobieps]

Did you look at PowerSync? It's "just" SQLite on the client. Wound be curious to hear what you think of it in the context of your lock in concerns