Scott you're so likable when you get super excited about something. I'm so excited to use Zero and React Native together. Can wait for Xmas break from work
Wow, Scott. Thank you so much ❤. I didn't expect this! PS: - early on - if you set the repeat rate of your keyboard higher it goes even faster 🙃 - at 9:40, we have an `upsert` method :). - at 10:00, PK doesn't need to be an array in the common case where its a single field
This looks awesome! Very curious about advanced permissions, like hierarchical stuff, and performance at extreme cases. We built our platform using Yjs, and permissions and performance edge cases in prod have always been the trickiest part.
Wow, this sounds amazing. I wanted to try to recreate something like that next week, this is perfect timing, I'll give it a try. The implementation looks amazing, I could see a lot great services wanted to "bind" to Zero (👋 Supabase, I bet they are already working on it). Thank you so much for the discovery. This December is full of nice stuff for us devs. Also, your eyes looked a bit watery, I hope it's just a lighting thing, and that you're healthy. Take care Scott, happy holidays
Going to the Zero docs is not much help either. I am a kind of hobby-level programmer and can understand a few things but I do understand that this is kind of intermediary between the client code and the backend database and it brings in the database to your local machine and only goes back if it has to. BUT this understanding is very shallow and not usable at all, at least for me.
It's a database solution which straddles the gap between the backend and the frontend. Zero maintains a local cache in the client of data received from the backend database, and it also handles the actual requests over the network, as well as syncing. Because it's local-first, offline functionality is easy to achieve and the cache speeds up a lot of redundant data fetching tasks. And because it bridges the gap between the frontend and the backend, your backend API layer can be very lean.
Thanks so much for tthis video. Zero Sync is clearly extremely cool tech and with the possiblilty of self hosting is the win for me as opposed to that of a deal breaker with solutions that do not let you do that. I dont mind paying for services as they cost to run but if you need to develop within regulatory contrains, entirely on someone elses cloud for your data is not always viable. I can't help thinking that this is like a PWA without saying the word PWA or even needing to include a manifest !
Been waiting for this to drop - really hyped by this. Also loving your lead on local first - so great to be talking about exciting things in the web space, rather than the topic being about which framework is better (yawn)
“local first” reminds me of Meteor so this is interesting. I wonder how these websocket based apps would scale for high volume and highly concurrent usecases, even if it’s just reads e.g., 10,000 people looking a single post getting live edited by the author. Seems like 10,000 persistent tcp connections, which I think poses different types of scaling issues (mostly in the network space). For multi tenant, low volume or low concurrency usecases, this seems great.
I'm still trying to figure out if meta-frameworks are dead... with this, they almost look dead to me. I was already comfortable thinking that they would last at least 5 years, but local-first is stronger, clearly. We're back at SPAs, but this time the backend almost evaporates. I'm buying so much pop-corn to watch this unfold...
Big fans of meteor. We’re trying to do meteor but much more composable. You’re not opting into entire meteor ecosystem. Zero works with standard postgres, standard web frameworks, and will work with other dbs in future.
What’s the catch? Is it a library, pricing, all missing from the site. What’s the zero server, missing info, and open source! Hello zero doesn’t seem like it.
I never understand how “local first” is anything other than a toy. Most apps of consequence have business logic. When I add a product that just sold out to a cart, what happens? Call an API to get sales tax info? Etc. I’d love to see a real world demo of this tech.
Look at apps like Linear and Superhuman for successful local first apps. Many of the fastest apps you've used use these local first techniques. For something like product stock, you would def not want to use this
@ both use in house solutions. If you’re not using it for something as basic as product carts, then it sounds like you have a bifurcated data solution where everything is manually stitched. Nightmare. Or at least not worth the trouble.
So if im understanding this correctly the logic for zero is done on the client. And you write queries that get synced to your database. Doesnt this expose a huge security flaw in your application?
So, I did browse the docs, and it's not clear to me what's happening on the server side(?).. .you patch something, and it needs to update the DB, and... is it an ORM that's handling all of the updates to Postgres? I understand the client side DSL and the speed, and that seems great. Explain server side a little?
I haven't used Convex but I know people love it. This does less than Convex in terms of overall features but this has a very novel way of syncing and loading data to be so fast. Zero is something you'd pick if you want to control and work with your own db.
I didn't see any reference to the source How do we validate that even as self hosted with docker, it doesn't dial home. Ive got extremely condifential data app fhat would be great to use this with
I personally didn't used a website that fast in the 90s. You were typically doing a full page reload on every route change. Ajax loading 100 bug issues was never and could never be this fast for the simple fact that there aren't network requests.
Orthogonal. You can use this kind of framework with zero but: a. Zero doesn’t support ssr very well yet. You can do it, but it’s not elegant. b. You may find yourself not wanting many of the features of these frameworks as much - for example you will not need remix or next’s optimistic mutations or caching features because zero provides these in a better way.
I'm skeptical about this abstraction, I don't think it's the right one. Business logic can't be on the frontend, it's too complex, and you can't maintain it for a long time. I think the proper abstraction must be completely hidden for the developer, no schema declaration or any other layer. I imagine tanstack-query implementing that internally, and it will be just a flag to turn "true" to automatically handle all the caching and use of indexDB, same for mutations. I think it's feasible.
The core ideas in tradition frameworks are incompatible with this kind of performance. The reason sync engines are fast is because they proactively sync data to client an enable it to be manipulated locally. This can’t be done on top of traditional apis.
How does this solve the issue which makes Firebase auth difficult to use? If I'm an user then take the jwt from network tab, then try and query your zero service, what's stopping me from request things I shouldn't have access to? e.g. request someone else's personal details?
A few things: 1. Zero permissions use ZQL, a full query language. Firebase's are more a configuration language and a lot more limited. If you've used Postgres RLS, Zero permissions are closer to that than Firebase rules. 2. In some ways this kind of system is _more_ secure, because you think about access at the level of invariants not procedural code. So you don't have to re-implement security in every endpoint, you do it once in a common location. It's also a less common way for devs to think about permissions though, so there is a tradeoff. 3. Zero doesn't currently have column permissions - if a user has access to a row they get the full row. So like if you have `user.address` and user A has access to user B, user A will see user B's address. This is just an alpha thing and will be fixed. And we will default this to closed, so that you have to open each column specifically. 4. The permission system is still in development and we have some new ideas percolating for beta that I think will really improve it.
They aren't competing technologies. Zero isn't an orm as much as it is a local caching and sync system that happens to eliminate the need for server side orms. I typically use Drizzle with Zero.
I get the skepticism, but your app is most assuridly not even close to the speeds this can produce loading data for nothing even Zero related. Storing data locally will always be tremendously faster than anything you can produce over the network even with caching.
No magic, just physics. You cannot load this amount of data remotely anywhere in the same universe as fast as from data stored locally on device. This is not 50ms-650ms loads by a long shot
Scott you're so likable when you get super excited about something. I'm so excited to use Zero and React Native together. Can wait for Xmas break from work
You should check out the “One” framework. It’s Zero + RN and a lot of good stuff.
is that an agents of shield reference in the wild
Thanks Scott! I'd be excited to see more of Zero in conjunction with Sveltekit and Coolify! ;) Thanks again for your great content
Same, the stack of my dreams! With drizzle and a self hostable backend like Supabase. The perfect web app!
Please bring as much content about this as you can. Great video, got me hyped!
Wow, Scott. Thank you so much ❤. I didn't expect this!
PS:
- early on - if you set the repeat rate of your keyboard higher it goes even faster 🙃
- at 9:40, we have an `upsert` method :).
- at 10:00, PK doesn't need to be an array in the common case where its a single field
Hope it gets pinned to the top so other people can see it. 😃
This looks awesome! Very curious about advanced permissions, like hierarchical stuff, and performance at extreme cases. We built our platform using Yjs, and permissions and performance edge cases in prod have always been the trickiest part.
This was great! Please keep the zero / local-first content coming!
Def more coming.
Wow, this sounds amazing. I wanted to try to recreate something like that next week, this is perfect timing, I'll give it a try.
The implementation looks amazing, I could see a lot great services wanted to "bind" to Zero (👋 Supabase, I bet they are already working on it).
Thank you so much for the discovery. This December is full of nice stuff for us devs.
Also, your eyes looked a bit watery, I hope it's just a lighting thing, and that you're healthy. Take care Scott, happy holidays
All good, def healthy, possibly lighting. Thanks for the concern though. 😀
I'm 3 minutes in, and still have no idea wtf this thing even is... I've heard "platform" 100 times, and have no idea what that's meant to mean here.
Going to the Zero docs is not much help either. I am a kind of hobby-level programmer and can understand a few things but I do understand that this is kind of intermediary between the client code and the backend database and it brings in the database to your local machine and only goes back if it has to. BUT this understanding is very shallow and not usable at all, at least for me.
It's a database solution which straddles the gap between the backend and the frontend. Zero maintains a local cache in the client of data received from the backend database, and it also handles the actual requests over the network, as well as syncing.
Because it's local-first, offline functionality is easy to achieve and the cache speeds up a lot of redundant data fetching tasks.
And because it bridges the gap between the frontend and the backend, your backend API layer can be very lean.
Drop-in looks sick, thanks for making zero svelte friendly
I’d love to see more Scott videos with tuts like CJ sometimes does
Thanks so much for tthis video. Zero Sync is clearly extremely cool tech and with the possiblilty of self hosting is the win for me as opposed to that of a deal breaker with solutions that do not let you do that. I dont mind paying for services as they cost to run but if you need to develop within regulatory contrains, entirely on someone elses cloud for your data is not always viable.
I can't help thinking that this is like a PWA without saying the word PWA or even needing to include a manifest !
Would love to see tutorials on this with Svelte. Thanks for your work, this looks amazing.
Hopefully the drizzlezero translation comes soon, would be awesome!
This look super promising, keeping an eye out for zero
Been waiting for this to drop - really hyped by this. Also loving your lead on local first - so great to be talking about exciting things in the web space, rather than the topic being about which framework is better (yawn)
More local first content
“local first” reminds me of Meteor so this is interesting.
I wonder how these websocket based apps would scale for high volume and highly concurrent usecases, even if it’s just reads e.g., 10,000 people looking a single post getting live edited by the author.
Seems like 10,000 persistent tcp connections, which I think poses different types of scaling issues (mostly in the network space).
For multi tenant, low volume or low concurrency usecases, this seems great.
This is awesome, I'm looking forward to the beta release! Thank you for reviewing.
lofi gang taking over '25 and beyond
I'm still trying to figure out if meta-frameworks are dead... with this, they almost look dead to me. I was already comfortable thinking that they would last at least 5 years, but local-first is stronger, clearly. We're back at SPAs, but this time the backend almost evaporates. I'm buying so much pop-corn to watch this unfold...
You still need SSR or static content for good SEO. That's where an SPA falls short and why we ended up in this meta framework situation
Its monday, all webdevs should remember to change their stack...
This is crazy 😲
So they finally released! After having me hyped for months !
Been waiting for this day, just so I could spill the beans on how good it is
Wonderful ! I'm interested by local first video, thanks !
Personally, I'd like to integrate this with Astro using Sveltekit as the fontend, and Supabase as the backend.
Hi Scott and thanks.
Feels like meteorjs all over again
Meteor was mostly just web sockets. This is much more novel than a rehash of real-time.
Big fans of meteor. We’re trying to do meteor but much more composable. You’re not opting into entire meteor ecosystem. Zero works with standard postgres, standard web frameworks, and will work with other dbs in future.
This is really amazing! I am curious how might I integrate this with my astro.
Getting Meteor Mini Mongo vibes here
I tend not work with alpha software but I will definitely be looking into this once it has an official release.
It seems having similar approach to convex platform. I don't know why not covering convex. It's really cool stack.
What’s the catch? Is it a library, pricing, all missing from the site. What’s the zero server, missing info, and open source! Hello zero doesn’t seem like it.
What about window functions like total questions? Or total bugs? Does it have to pull all of them to get it? Also React Native?
Aggregates are coming in beta. No we don’t have to pull all data to client to calculate.
is "Drop In" the name of the product? If not what is it and where is the link?
github.com/stolinski/drop-in Not really a product but a starter I’ve been using for myself. Now that Zero is in alpha I can develop in public
I would like to see a tutorial for Zero Sync
On the way 🫡
I never understand how “local first” is anything other than a toy. Most apps of consequence have business logic. When I add a product that just sold out to a cart, what happens? Call an API to get sales tax info? Etc.
I’d love to see a real world demo of this tech.
Look at apps like Linear and Superhuman for successful local first apps. Many of the fastest apps you've used use these local first techniques. For something like product stock, you would def not want to use this
@ both use in house solutions.
If you’re not using it for something as basic as product carts, then it sounds like you have a bifurcated data solution where everything is manually stitched. Nightmare. Or at least not worth the trouble.
Replicache (our prior product) supports arbitrary business logic. Zero will too, soon.
@ thanks for the reply! I’d love to see a “real world” example combining zero + zero business logic + a backing server when you get there.
So if im understanding this correctly the logic for zero is done on the client. And you write queries that get synced to your database. Doesnt this expose a huge security flaw in your application?
There is a server, it's just being controlled by the sync process. There is a permission and access api to prevent any security issues.
sqlite encrypted local first that sinks to a cf blog automatically. does that exists lol
Reminds me of Meteor
wow
Can I use it to make two way sqlite Postgres sync ?
Please build something with this I will try to replicate the process by myself.
So, I did browse the docs, and it's not clear to me what's happening on the server side(?).. .you patch something, and it needs to update the DB, and... is it an ORM that's handling all of the updates to Postgres? I understand the client side DSL and the speed, and that seems great. Explain server side a little?
Thanks Scott, how this compare to convex (I know the local part and postgres integration)
I haven't used Convex but I know people love it. This does less than Convex in terms of overall features but this has a very novel way of syncing and loading data to be so fast. Zero is something you'd pick if you want to control and work with your own db.
I didn't see any reference to the source
How do we validate that even as self hosted with docker, it doesn't dial home.
Ive got extremely condifential data app fhat would be great to use this with
Repo is here if you want to paw through it. github.com/rocicorp/mono
lol. People are amazed when a software do the basic: be fast (as ALL of them was in the 90's).
I personally didn't used a website that fast in the 90s. You were typically doing a full page reload on every route change. Ajax loading 100 bug issues was never and could never be this fast for the simple fact that there aren't network requests.
what is its relation to framework like remix/next/astro? does it replace them or complements/integrates with them?
Orthogonal. You can use this kind of framework with zero but:
a. Zero doesn’t support ssr very well yet. You can do it, but it’s not elegant.
b. You may find yourself not wanting many of the features of these frameworks as much - for example you will not need remix or next’s optimistic mutations or caching features because zero provides these in a better way.
Louder than the other day, still too quiet. Maybe a compressor/limiter would help?
it's plenty loud for me...
This is compressed and normalized. Should be the appropriate volume.
I'm skeptical about this abstraction, I don't think it's the right one. Business logic can't be on the frontend, it's too complex, and you can't maintain it for a long time.
I think the proper abstraction must be completely hidden for the developer, no schema declaration or any other layer.
I imagine tanstack-query implementing that internally, and it will be just a flag to turn "true" to automatically handle all the caching and use of indexDB, same for mutations. I think it's feasible.
I agree, I would much rather persist it locally via Tanstack query.
The core ideas in tradition frameworks are incompatible with this kind of performance. The reason sync engines are fast is because they proactively sync data to client an enable it to be manipulated locally. This can’t be done on top of traditional apis.
Is that means anyone open dev tool can know my DB scheme? 🤔
I build my offline first apps in a service worker. So, my front end never touches the db. Would this work in a service worker?
Good question.
Yes it will work in sw
How does this solve the issue which makes Firebase auth difficult to use? If I'm an user then take the jwt from network tab, then try and query your zero service, what's stopping me from request things I shouldn't have access to? e.g. request someone else's personal details?
There are “select permissions” zero.rocicorp.dev/docs/permissions#select-permissions that give you control over who can select what.
How is this an issue with Firebase? 🤔 RLS and rules solve this (same for Supabase, etc)
A few things:
1. Zero permissions use ZQL, a full query language. Firebase's are more a configuration language and a lot more limited. If you've used Postgres RLS, Zero permissions are closer to that than Firebase rules.
2. In some ways this kind of system is _more_ secure, because you think about access at the level of invariants not procedural code. So you don't have to re-implement security in every endpoint, you do it once in a common location. It's also a less common way for devs to think about permissions though, so there is a tradeoff.
3. Zero doesn't currently have column permissions - if a user has access to a row they get the full row. So like if you have `user.address` and user A has access to user B, user A will see user B's address. This is just an alpha thing and will be fixed. And we will default this to closed, so that you have to open each column specifically.
4. The permission system is still in development and we have some new ideas percolating for beta that I think will really improve it.
@@AaronBoodman thanks for the detailed explanation.
I just wanted to say it. First comment lol
Swxind to comment 😢
zql looks ugly af. I much prefer "drizzle".
They aren't competing technologies. Zero isn't an orm as much as it is a local caching and sync system that happens to eliminate the need for server side orms.
I typically use Drizzle with Zero.
@ I understand that, but I do not see the benefits of zero. My stack is about the same speed and way more flexible.
I get the skepticism, but your app is most assuridly not even close to the speeds this can produce loading data for nothing even Zero related. Storing data locally will always be tremendously faster than anything you can produce over the network even with caching.
@ 50-650ms response time is definitely no magic.
No magic, just physics. You cannot load this amount of data remotely anywhere in the same universe as fast as from data stored locally on device. This is not 50ms-650ms loads by a long shot
Honestly. I don't like it.