localfirst.fm

A podcast about local-first software development

Listen

Conference

#2 – Aaron Boodman: From Google Gears to Replicache & Reflect.net

In this episode we talk about Aaron's history in local-first, which goes back to 2008 with the release of Google Gears – the first time sqlite was added to the browser - and his perspective on where we're at now and why local-first is finally happening.


Mentioned in podcast:

Links:

Thank you to Expo and CrabNebula for supporting the podcast.

Transcript

Introduction
00:00the main thing is browsers have storage now, like, they didn't
00:03have storage for the longest time.
00:04I feel like my mission in life is just like I'm shouting from
00:08the mountaintop Hey, did you know browsers have storage now
00:13Welcome to the localfirst.fm podcast.
00:15I'm your host Johannes Schickling, and I'm a web developer, a startup founder, and
00:19love the craft of software engineering.
00:21For the past few years, I've been on a journey to build a modern, high quality
00:25music app using web technologies.
00:28And in doing so, I've been falling down the rabbit hole of local first software.
00:32This podcast is your invitation to join me on that journey.
00:36In this episode, I'm speaking to Aaron Boodman, who's the founder of Rocicorp,
00:41the company behind local first products, such as Replicache and Reflect.net.
00:46This conversation covers a wide range of topics, starting from how his work on
00:50Google Gears has led to Google Chrome.
00:53And many of today's web standards.
00:55Later, we're diving into what Replicache is and how it's implemented.
01:00Also a big thank you to Expo and Crab Nebula for supporting
01:03this podcast and supporting the local first ecosystem as a whole.
01:08And now my interview with Aaron.
01:12Welcome Aaron to the show.
01:14Thank you so much for joining today.
01:16Would you mind briefly introducing yourself?
01:19Yeah, sure.
01:20okay, , My name's Aaron.
01:21I am most recently the founder of Reflect.net which is a hosted service for
01:26multiplayer and And for local first style apps, my company also built Replicache
01:32which is a variation of that product.
01:35And I kind of have a long history in the web.
01:38I've been doing open source on the web for a really long time.
01:40I started in like, I don't know, 2002, 2001.
01:44And yeah that's me.
01:46Awesome.
01:47Thank you so much for making time and coming on the show.
01:50Would you mind sharing a little bit of like your arc of what brought
01:54you to local first software today?
01:57Yeah, sure.
01:57I'll try to give a short history.
02:00You know, I started out my career just doing JavaScript libraries, UI libraries.
02:03Actually, a bunch of my oldest friends and co workers we were a member of this
02:07community online called dhtmlcentral.
02:09com, which was like back in the very dark ages of the web, like before GitHub,
02:13before really open source like hit its stride and we would share JavaScript
02:17on there, and we built UI components and things like that, and we were
02:21just really excited about, you know, pushing this, Tiny, terrible platform
02:27to build, like, real apps with it.
02:29One of my friends built, like, a whole windowing, like, toolkit, like, with
02:33all the window components, like, in JavaScript, like, in 2000, I don't know,
02:37it must have been, like, 2001 in there.
02:39And, you know, over time, you know, the web grew and we found
02:44ourselves at big companies.
02:45I found myself at Google helping them do do their JavaScript products, right?
02:50And, you know, it was always like this huge fight to get
02:54anything in browsers at that time.
02:56Like, like, browsers just would never add any features.
02:58Like, there's no incentive for them to do it.
03:00And so, this opportunity at Google came up to work on this thing called Gears.
03:04Which was this crazy idea to, like, add a plug in to browsers that added APIs.
03:09Like, usually plug ins, they're like a graphical thing, you know.
03:12They like, they add some sort of UI feature.
03:14But this was an idea to add a plug in that had no UI features.
03:17All it did was add web APIs.
03:18So that, like, we could actually build stuff with browsers that
03:21was, like, good, you know?
03:22And and it was just such a cool, like, bold idea.
03:26And so I jumped on that, and the first, one of the very first
03:28things we built was a database.
03:31aNd the reason that we wanted to put a database in browsers was because, at that
03:34time, you know, you could only store five megabytes of data in a browser, you know?
03:39And so, if you think about it, the web is just, like, fundamentally hobbled.
03:44By not having storage.
03:46Like, you think about what makes an app.
03:48You know, we have this constant annoying debate on the web.
03:50SPA, MPA, blah, blah, blah, blah, blah.
03:52Just step back and think to yourself.
03:54Like, what are the ingredients of a native app?
03:56What makes it tick?
03:57What makes it a native app?
03:59And there's not that much to it.
04:00It's processing, memory, network, storage, UI.
04:04You know?
04:05Those are the ingredients.
04:06You know?
04:07The web until recently didn't have storage and that's like
04:10an important ingredient.
04:10If you don't have storage you're doomed to be a dumb app, a dumb client.
04:15completely agree.
04:16So before going a bit more into today's storage mechanisms, what was , back then
04:22for Gears, what was the inspiration, was there any sort of existing database
04:27that you looked at where you said, okay.
04:29It would be great to have something similar to this, but for the web, or
From Google Gears to Chrome
04:36Well, the API that we the actual database that we used was SQLite,
04:39which at that time felt very mature, even then, at that time.
04:43You know, I think,
04:45I'm pretty sure that SQLite started, I want to say, in 2000.
04:48And this was 2007 that we were doing this in.
04:51It was a really, it's kind of an obvious thing.
04:53Already SQLite was in everything at that point, you know?
04:56And, or it felt like it was in everything.
04:58And it's embedded, fast, robust.
05:01But, you know, it wasn't an appropriate API for the web.
05:05The cool thing about working on Gears was like a lot of the people
05:07that were doing the platform design were like JavaScript developers.
05:09And then we had a bunch of like sort of more gnarly C++
05:11people working on the guts.
05:13And we, you know, we wanted to do APIs that fit in the web from both like a
05:18security and a usability point of view.
05:20So we wrapped SQLite in you know, a simple, but what we felt was
05:25like fairly webby abstraction.
05:28So what was the path forward from there?
05:30So I can't say that I've built something on top of Google Gears.
05:34But I, I've, I know of quite a few database-like abstractions for the
05:40web for example, thinking of web SQL, which I also think is built on top of
05:45SQLite was that sort of an evolution of what you built back then, or take
05:51me from back then, from the first steps of bringing SQLite to the web to
05:56the various chapters up until today.
05:58Yeah, absolutely.
06:00Gears had a short and glorious life.
06:04I think it did not last long.
06:06We launched it in I believe.
06:09And it was dead by 2010.
06:11And what happened was It was this very, in retrospect, it was this
06:15very high risk strategy for Google.
06:17We were trying to force change on the web.
06:20Like, Google needed the web to be better, like, in order to do its applications.
06:24And and, what happened when we launched Gears was, like, the other
06:28browser vendors, like, hated it.
06:29And, like, like, legitimately, or all, at that time, Google
06:32did not have a browser, right?
06:33So, the browser vendors hated it.
06:35And, you know, they felt threatened by it, you know?
06:38And I think there were also, Fair and good like standardization arguments,
06:43but I think the reality was like they were the people who made the web
06:47platform and this was like someone coming and trying to like force things
06:50on them sort of against their will.
06:51Whether the will was like fair or not.
06:53And and so there was a lot of backlash.
06:55We Had hoped that we would distribute gears with browsers.
06:59Safari, like, they outright said no I think Firefox said no, and
07:03basically, like, around that same time, Google was starting Chrome.
07:07And there was strategic questions of how the two fit together.
07:10And basically how do we advance the web?
07:12And it just became really clear that the way to do that was to have a browser.
07:16Because like, browser vendors were the ones with a seat at the table.
07:19And it just, it was obvious that we would, as a company, we would have
07:23more leverage doing it that way.
07:24At first, we put Gears in Chrome.
07:26So the first thing was Chrome launched and we put Gears in Chrome.
07:29And then, a little while later, we shut down Gears.
07:32But, even with, like, just the few properties using Gears, it was
07:35obvious that the web needed this.
07:38And there's a guy at Google who was HTML5 spec named Hixie, Ian Hickson and he
07:45just worked right down the hall from me.
07:46And he was like, we have to standardize this.
07:49We have to specify it.
07:50His philosophy was like, The web is what browser vendors ship, you know,
07:55that's just the reality, you know, and Chrome has shipped this and then
07:59shortly thereafter like Safari was working on shipping it and he was
08:02like we have to have a spec for this.
08:04Otherwise, no one's, it's not gonna be interoperable.
08:06So he wrote it down and he designed the web SQL API, web SQL database, which
08:11was a JavaScript API around SQLite.
08:14Which was inspired by Gears.
08:16I helped, like, edit the spec.
08:18And That took us to WebSQL database.
08:20The story actually has this long and sad history Beyond that, because, you
08:24know, of course, WebSQL got killed too.
08:27Yeah, well, as, as many products and great ideas within Google, but looking at the
08:34looking at it as a glass half full, I think each of those has brought new ideas
08:41and started new things that I outlived.
08:44The initial products.
08:45So I think now SQLite is far from being done.
08:50So it's really like a technology of the decades and is still getting better.
08:56And I think we should do entire shows also just on SQLite and local first.
09:01Were there any other ideas that are sort of noteworthy that came
09:05out of the gears project that also made it in today's browsers.
09:10Yeah, absolutely, you know, geolocation.
09:12We shipped geolocation.
09:13We were the first way that you could get access to geolocation programmatically
09:16in web browsers and the API and the guy who designed that API was like on my team
09:21and the API that ended up in browsers is almost like word for word the same API
09:26and Workers so the very first version of Gears had three APIs offline boot, like
09:33the inability to boot a web app offline.
09:35So it had a sort of equivalent, something a little bit like AppCache.
09:38And then it had workers, so that you could do sync processing in the
09:42background without blocking the UI thread.
09:44And it had a database based on SQLite.
09:47And all three of those are the first release, and all three of
09:49those APIs became web standards.
09:51You know, not the exact same API, but they directly influenced, I mean,
09:54basically, Hixie was like, we better write this down, because people
09:57are going to start implementing it.
09:58So.
09:59In that way, Gears definitely had the impact that Google and that, you know,
10:04I hoped it would have, that it did move the web forward a lot, really fast.
10:08That's incredible.
10:09You had like all of those foundational ideas already back then.
10:12And I feel like now, what is it like definitely more than 10 years later,
10:19the web still feels like to just about discover those bigger primitives that
10:24we can actually use storage to build real web apps, that we can use workers
10:29to make things more performant and kind of spare the main thread a bit.
10:33To keep the app more responsive.
10:35So all of those capabilities that you all kept thinking of way, way back,
10:41I feel like step by step that the web is finally waking up to those.
10:45So I think storage is really like the main thing on your mind there.
10:50Yeah, I mean, there's so much to talk about, I'll try not to ramble, , you said
10:5310 years, it's been more than 15 years.
10:55Like, it's 2023, we launched Gears in 2007.
10:59So it is crazy how long these things take.
11:02it hasn't been a, it has not been a straight line it wasn't
11:04Google that , killed WebSQL.
11:06It was actually Firefox kind of, and Microsoft.
11:09Like, basically, the browser vendors wouldn't implement it.
11:11They were afraid that it would not be able to be standardized.
11:14Which I think is not really true.
11:15We could have done that but it would, there was a fear and it,
11:18I think it was a legitimate fear.
11:19But I think ultimately we could have done that.
11:21And so we sort of randomly got IndexedDB out of the deal instead.
11:26And it, you know, the vendors were looking for an alternative
11:30that was standardizable, right?
11:32And so this thing sort of emerged.
11:35And like one of the, one of the like participants in the W3C list or the
11:38H, the WhatWG list proposed this.
11:40And it was like, it fit.
11:43The sort of strategic goals of the other vendors, but, and so it got specified and
11:48implemented really quick, but just one of those things where it wasn't coming from
11:52a place of people actually using it, you know, and wanting to build things with it.
11:56And so it just has this just like always happens when you do that, like,
11:59it just has this really weird API shape and so, you know, IndexedDB like
12:03famously never got used for anything and then we didn't have Web SQL either.
12:07And then meanwhile, the browser vendors kept, well, people kept
12:11trying to put SQLite in the browser because SQLite is so awesome.
12:13It's so useful, , and so people kept looking for a way to do this both inside
12:17browser vendor companies and outside.
12:19Google had this team, a sub team of Chrome, working on this thing
12:22called NaCl, and that was like, you know, an assembly language that
12:25could run in the web, sandboxed.
12:27And the predecessor to WASM.
12:29One of the main, use cases, was we could run SQLite in the browser.
12:33And we wouldn't have to standardize it, right?
12:35Because the standard would be lower level, right?
12:37But nobody wanted to, the other vendors didn't want to implement
12:41Yeah, so then that didn't work.
12:42And then they tried PNaCl, which was like supposed to be like a more portable
12:45version of it, but then that, they, the vendors wouldn't implement that.
12:48And for a little while people were like, Oh, we can just
12:50compile everything to JavaScript.
12:51That was like, you know, asm.
12:53js, and people tried compiling SQLite to that.
12:57And that, I mean, it kind of worked.
12:58But then eventually Mozilla proposed Wasm, which was like basically a
13:02really closely related idea to NaCl.
13:04And and then everyone got behind that.
13:07And so then people started putting SQLite in that.
13:09And then, you know, humorously around the same time Safari killed cross
13:15site caching for privacy reasons.
13:17So, using SQLite this way is like a little bit hobbled because it means like
13:20every app has to cache it themselves.
13:23But yeah, it's been a, it's been a long story and you know,
13:26there's way more to it than that.
13:27Why do the platforms grow so slowly?
13:29There's like technical reasons and there's sort of political reasons and
13:31strategic reasons from the companies, but like, I think also it's like,
13:34There's this economic thing that happens.
13:36I think like humans are sort of lazy and risk averse.
13:39You know, not in a bad way, just like, no one uses storage on the web, right?
13:44And so if you're building a new app on the web, and say you want to build, I
13:48don't know, a new competitor to Google Slides or something like that, right?
13:52Are you going to use storage?
13:53It's like a, it's like a high risk thing, because no one else does
Challenges of the Permissionless Web
14:01So zooming out a little bit the web is not the only platform.
14:04We have native mobile platforms, iOS, Android.
14:08We have also native desktop operating platforms.
14:10So most of those have storage mechanisms since otherwise, if I.
14:16Reopen an app on my iPhone and it has lost all my data that wouldn't be great.
14:21Whereas that is the more common experience on the web.
14:25So why do web apps feel so different compared to native apps?
14:30Yeah.
14:31I mean, this is a question as old as time.
14:33I mean, people have been asking this since I started programming on the web.
14:36And I think it's this like really deep and interesting.
14:39Question.
14:40So why is it hard to put storage in the web platform?
14:42Why has it taken so long?
14:43A, a big part of it is just the web is zero permission.
14:46It's permissionless, right?
14:47That's like the web's superpower.
14:49That's what make, that's why we still have the web and it, you know,
14:52iOS is like a, on a, on technical merits, a superior platform.
14:55You can't deny it, but the web has this one thing that no other
14:59platform has, and that has made it so powerful that it's permissionless.
15:02You can send a link to your friend and they see the picture of your cat, that is
15:06something that doesn't happen on any other platform and it's super, super important.
15:10It's why I started programming for the web and it's why probably many of us did.
15:14It's like when you're a kid and you got notepad.
15:16exe, you know, and you know, an FTP client, you can like write
15:19some, put it on your webpage and share it with your friends.
15:21You don't need anyone's permission.
15:22You don't need an account.
15:23You don't need a credit card, but this superpower is also the source
15:26of all the web's difficulties.
15:28Like the fact that the web is permissionless means that it can't have
15:31any permission that could be dangerous.
15:33That could be a security issue that could be privacy issue that
15:36could hurt you or your computer.
15:38And so it's different than a platform that's more managed and so just
15:41from a platform design perspective, figuring out how to put storage in
15:44browsers has been difficult, right?
15:45Because you, you know, a malicious app, you don't want
15:48it filling up your disk, right?
15:49Making the other apps not work right.
15:51Or like consuming all of the storage quota, right?
15:53And from a privacy perspective, you don't want people using the storage to like,
15:57you know, track you or whatever, right?
15:59Because of the way that the web is permissionless, it has grown
16:02an ecosystem of apps that are like different than native apps, right?
16:05Only recently people have started using the web for like sort of
16:08personal productivity apps like note takers and stuff like that.
16:11You know, like you think about like traditional platforms, they tend to
16:15focus on apps that are single user, you know, like the bread and butter
16:19of iOS is like single user apps.
16:20Right?
16:21All the apps that it's shipped with, right?
16:22Those are all things you use alone, right?
16:25And storage is easy for those kind of apps, right?
16:28Desktop platforms have had storage for a long time, right?
16:31But because the web is permissionless, it has tended to be strong in
16:36collaborative applications, right?
16:38And also apps that are huge, where there's like way more data
16:41that you could possibly fit.
16:42On your device, right?
16:44Google search, Google Maps, Gmail, right?
16:46All of these products are like things where you couldn't actually
16:48run them on your device, right?
16:50Like they need a lot more computers to run.
16:52Even assuming that you have storage, like once we added gears, right?
16:56Once you have that, even using it is hard because you have to figure out how to use
16:59it in a multi user, like, environment.
17:01You have to figure out sync and conflict resolution.
17:04And then because the data can be bigger than can fit on your device,
17:06you have to figure out not just sync, but partial sync, which is
17:09like this whole other harder part.
17:11And then you have to figure out authorization and sync.
17:13Like with iCloud, your own data back and forth, right?
17:15You have permissions to it.
17:17But in, in like a classic web app, you only have permissions
17:19to a tiny subset of the data.
17:20So you have to do partial authorized sync, right?
17:23And then on top of that, the storage isn't reliable because the browsers
17:27have to implement it in such a way that that apps can't abuse it.
17:30That means as an application developer that it can disappear at any moment, which
17:33is also different than a native platform.
17:35So I not only have to build a much more complicated syncing mechanism, I also
17:39have to make that syncing mechanism robust to the fact that the storage
17:42underneath it can just disappear.
17:44I think there are like legitimate technical challenges and then on top
17:47of that, I think there are sort of just natural human challenges to to like doing
17:51something that no one has done before.
Web storage
17:53Right.
17:53So before diving into those let's maybe dig a little bit more
17:57into the technical challenges.
17:59So you've posed them as challenges and given that over the last.
18:0310, 20 years, the web has changed significantly in, in terms of the things
18:09that have been standardized et cetera.
18:11So I think a few of those challenges are always inherently
18:15challenging due to the nature of the web, which is permissionless.
18:20But given some of the technological improvements, I'm wondering which
18:24of those challenges are much more manageable now and why, and what are
18:28those improvements that have been landing and how do they make things easier now?
18:33the main thing is browsers have storage now, like, they didn't
18:36have storage for the longest time.
18:38I feel like my mission in life is just like I'm shouting from
18:41the mountaintop Hey, did you know browsers have storage now?
18:45I feel like largely developers don't know this.
18:47In fact, I was on a tweet thread just yesterday where someone well
18:50known in the web, in the software development community, like, very
18:54respected, was like, wait, browsers have more than 5 megabytes of storage?
18:57Like, yes, they do.
18:59On most devices browsers have like gigabyte of storage.
19:02You know, , the actual quota is complicated.
19:04It's dependent on how much free space you have on your device and what browser
19:07you're using and like how many other apps are using storage and blah, blah, blah.
19:11But I mean, you can assume as a web developer that you have access
19:14to like hundreds of megabytes of storage locally on the device, which
19:18in almost all cases now is SSD.
19:20It's like almost memory.
19:22You know, we have a local cache, persistent cache that can store
19:25hundreds of megabytes of data.
19:26And if you're not using this as a web developer, you are leaving a massive
19:30amount of performance on the table.
19:32We have a whole community of like web developers who are constantly talking
19:35about how much performance matters to them and how performance is the most
19:38important thing and they have this massive cache sitting on the device
19:42that they're not using, so we have the primitive, you can sort data in browsers.
19:46But we now need to develop the patterns and libraries and techniques and
19:51mindshare for people to know that they can use this and how to use it.
19:54I fully agree.
19:55This is exactly where I wanted to go to.
19:58We have the primitives now, we had some cruder primitives in the past.
20:02But I think those primitives are getting a lot better now.
20:05They work more consistently between browsers.
20:08They're getting more performant.
20:09Some restrictions are no longer there, but as you say, now it's a
20:13matter of building the layers on top, building the libraries, building
20:17good tooling, building things like.
20:19Browser dev tools that work with us.
20:22And so I think that's one major part.
20:24And then the other major part is to getting people, like you say, like you
20:29go into mountaintop and shout it down.
20:32This is what needs to happen as well.
20:33Besides building great tools, since otherwise people kind of stick
20:37with the old way of doing things.
20:39But maybe in the context of the storage of the web maybe you want to draw a
20:46quick bridge to what you're working on.
Roci Corp, Replicache and Reflect
20:48Yeah, sure.
20:49So I'm the founder of this company, Roci Corp.
20:51It's basically collection of my friends from Google that worked on Chrome
20:55mostly with me and and we loved the work that we did there and like the
21:00quality of work that we built and we wanted to keep doing it on our own.
21:03So we formed this small company.
21:05We're fully distributed and we have two products around multiplayer and local
21:09first Replicache is client side only so it's a library that you include in your
21:14app and you can think of it sort of as like a wrapper around local storage.
21:18We actually use IndexedDB, not SQLite and I think I think IndexedDB is slept on.
21:22I think like it has a lot of advantages and we're probably going
21:25to continue to use it for a while.
21:27But it's doesn't matter.
21:28There's multiple storage mechanisms now in browsers and they have trade offs.
21:31So anyways, we have Replicache, which is client side only, and it's a
21:34wrapper around local storage that has a synchronization protocol built into it.
21:38A robust, high quality synchronization protocol that can do partial sync,
21:41that can do authorized sync that can store hundreds of megabytes of
21:44data locally is very performant.
21:46That can do 60 frames per second, like responsiveness client side.
21:50And, you know, people build apps out of this, you know, like, one of our
21:53biggest prop proponents, like Dax, is online today, talking about this
21:58crazy app that he has built that's competing with Vercel using Replicache.
22:03And but you know, implementing the backend for a synchronization
22:06system is also challenging.
22:07And so people asked us for a hosted solution for this.
22:11And so we also have Reflect, which is the complete package that
22:15includes the service that syncs.
22:17And it's, basically the same thing as Replicache, but with
22:20but with the backend as well.
22:22Got it.
22:22So can you explain a little bit more the cases when I would be
22:26using Replicache as opposed to when I'd be reaching for reflect?
22:31Yeah so Replicache is like, you want control of everything.
22:35Like, as much as you can have.
22:37Basically Replicache can connect to not any backend
22:40stack, but many backend stacks.
22:41You can implement a Replicache connector for basically any relational database,
22:44for most of the document databases, you know, you can even implement a backend
22:48for, like, your custom distributed system.
22:50So it's more effort, but it's more flexible and adaptable, right?
22:53Reflect is very opinionated.
22:55It's a complete hosted service that's tightly integrated and
22:58it's designed to be very fast.
23:00It leaves some, it's for, like, when you're starting something
23:03new, and you don't have a lot of time, and you just want it to work.
Tabs are challenging
23:06So I'd be curious to learn a little bit more about the challenges that you were
23:10facing building Replicache and building Reflect as it relates to the challenges
23:16you've mentioned before in regards to storage and other challenges we might not
23:20have talked about yet when it comes to building such a technology for the web.
23:24Yeah.
23:26there's a lot of little things that you discover when you set
23:29out to do something new like this.
23:31And a lot of times, you know, in software engineering You know, a lot
23:34of the work comes from like unexpected places, you know, it's not the
23:37algorithm, it's not the core algorithms or the data structures or whatever.
23:39It's like dealing with the practicalities.
23:42Like one thing that is really a quirk of the web that is another one
23:45of the web superpowers, but really makes this challenging is tabs.
23:49Like, the web has tabs and tabs from like a platform software developed,
23:54like a software engineering perspective are weird because they are different
23:57execution environments, right?
23:58It's as if.
24:00You have an application, but it has like, it has many different,
24:03like, places where code can run.
24:05Many, like, it's as if you had a bunch of different processes.
24:07They're not, tabs aren't really different processes, but like, from a software
24:10engineering perspective, they're kind of like processes because they're
24:12different execution environments that can have different code in them, right?
24:15Like, you could have different versions of your app with different
24:18code bases running in each tab.
24:19Like, if the server updated and and one tab updated, but
24:23the other didn't, you know?
24:24But they share storage.
24:26So that is a weird thing.
24:28Usually when platforms have a situation like that, where you have processes
24:31or threads, they also have locks so that you can like protect the
24:34storage and coordinate access to it.
24:36But the web has kind of has like a fledgling web locks API, but
24:40it is very unused and tested.
24:42And there's a lot of edge cases in it.
24:43And we don't really trust it.
24:45Like our company doesn't use it and trust it because we investigated
24:48a bunch of these edge cases and they're sort of like underspecified.
24:52I don't believe that they're consistently implemented across browsers.
24:56And we've even had people like on browser teams like recommend that we don't use it.
24:59You have to figure out a way to deal with the fact that You have
25:02this persistent storage, right?
25:04And one tab can update and the other tab cannot be updated.
25:07And then what happens?
25:09Right?
25:09And There's always a problem with these kind of systems of
25:12like schema migrations, right?
25:13You have to figure out schema migrations, but it's harder on the web because you
25:17have schema migration on the server You have schema migration on the client
25:20But then you have the problem that one tab can update and like want to migrate
25:24the schema forward to like the version of the Storage that it wants, but the
25:28other tab is like still back on the old version, you know, like what does it do?
25:31So these are just like fun practical problems.
25:34So I would actually love to learn a little bit more about either of those.
25:38And so are those challenges that you've been facing and that you can fully take
25:44care of on behalf of an application developer, are you able to like go some
25:49way, but still leave some of the hard.
25:52trade offs to an application developer and there's some path, some like bad
25:57or even worse trade offs someone needs to make as an application developer,
26:01they ultimately have to choose.
26:04So how we're able to work around those?
26:06My view is that in order for storage to be widely used on the web, it
26:11has to be as easy as, easier than like building a normal web app.
26:16It has to be easier than building today's web app, right?
26:18And I think that we can get there and the and the people who need to fill that
26:22gap, who need to make it easier than today's web apps are library developers.
26:26Like, it's not gonna be browser vendors because they move way too slow.
26:29Like, it's gonna be library developers because we have this , awesome
26:32ecosystem of people furiously tr trying different things to figure this out.
26:37So we have completely solved the cross tab thing, and I think our solution
26:40to it is, I'm really proud of it.
26:42Like we put a lot of work into it.
26:44It's for this like tiny moment when your app is updating we put this massive amount
26:47of effort into this, like 10 seconds at worst when your app is updating and
26:52like two tabs have different versions but we made it really like elegant.
26:56And like, you don't have to think about it.
26:58Like basically what happens is as a developer constructor for
27:03Replicache, you specify the version of the database that you want.
27:06And that's an identifier that you choose.
27:08So you say like, I want version seven and you can create as many
27:11different schema versions as you want in Replicache, and they'll each be
27:14isolated from each other, fully isolated.
27:16And when we talk to the server, we send in the request the version of the
27:21schema that we're asking on behalf of.
27:23So the server has to respond with that version or say, I can't serve
27:26that version, you need to reload.
27:27But then internally to deal with that moment when tabs are on different schema
27:32versions, we actually fork the database and we have both running at the same time.
27:37So typically in Replicache, the storage is shared, right?
27:41So you make changes in one tab and you see them instantly in the other
27:44tab whether you're online or not.
27:45But for this moment, when a schema update is happening, they fork.
27:48So the tabs can continue independently and they can continue working.
27:51You know, a concern is like, if you're typing in a, in an input, you don't
27:54want to just reload the app at that moment to get the new code, right?
27:56The user could lose their work or just be frustrated, right?
27:59So you want, you need to allow the app to continue running for a
28:02little while until it thinks that it's the right time to update.
28:06That sounds incredible.
28:07And that sounds like an absolute nightmare.
28:09If like I, as an application developer, it's hard enough to ship the app
28:15version that I have, and then to even like really think about that there
28:19is this point of time where a user has the old version up and running.
28:23And to then just like throw multiple tabs into the mix here as well.
28:28So, I think whatever pain you can take away from my application
28:32developer here is amazing.
28:34So yeah you've been mentioning the various app schema versions and that does at
28:39least locally speaking forks the database.
28:42And I suppose then there's some mechanism how the forks are eventually being.
28:48joined or merged again, or how if the different tabs are still being used,
28:55how did those forks come together again?
28:57Well, what happens is they're both still talking to the same server, right?
29:01So the they're local storage forks but they're still talking
29:04to a shared truth on the server.
29:06And the server and when tab a makes a request to the server, it says like,
29:10hi, I, I want to talk and I'm talking schema version seven and when tab
29:15B sends a request to the server, he says, I'm talking version eight and
29:18the server can choose to speak both versions if it wants, or it can choose
29:22to tell seven, I can't talk to you.
29:23I only know version eight but that doesn't mean that tab seven
29:26has to reload at that moment.
29:27Tab seven can continue working without a server connection, right?
29:30Because it's local first.
29:32And then it can decide to reload when it's ready.
29:34Let's say we have tab a and tab B and they're happily working
29:39in the same version right now.
29:41Is there some communication mechanism between those two tabs that that
29:45doesn't rely on the server alone?
29:48Yeah, under normal circumstances, the storage is shared.
29:51So you make changes in tab.
29:53If you're off totally offline with Replicache or reflect,
29:56and you make changes in tab a, you will see them in tab B.
29:58They share storage, right?
30:00It's just at this moment when an upgrade happens, they fork momentarily.
30:04Just to maintain like integrity of the system, like, so that you don't have.
30:09The schema changing underneath one of the tabs.
30:11And, you know, that is like a little bit of a rough edge in the like, abstraction.
30:17You know?
30:18But, under normal circumstances, you're never going to notice this as a developer.
30:22And it's like, the cleanest solution that we could come up with.
30:24I agree.
30:25I think it's not like that you're rolling out a new release constantly.
30:29I think the, still the majority of the time where the app is being
30:32used, that you're not upgrading.
30:35And so for that little period of time to have a simpler solution to
30:39this very gnarly problem, sounds like a very good move to me.
30:44So in the case where it's not currently upgrading, you mentioned
30:47that those two different tabs.
30:50Share storage.
30:51Does that mean they share the same IndexedDB database or is there even more
30:56sharing, such as like sharing an array buffer between those tabs, or what is
31:01the communication mechanism between those?
31:03Are you listening to changes in IndexedDB, is there sort of like
31:08a broadcast channel between those?
31:10How does the tap interplay work?
31:13I'm so glad you're asking these questions.
31:14Like, I don't know if our listeners will care about these details.
31:17I hope they do.
31:18Because this is like, the fun part, you know?
31:20But Yeah, this gets to another one of the practical challenges that I am proud
31:23of in our implementation that I, that we put a lot of work into, which is
31:26like we, it was very important to us.
31:29And I know important to you too.
31:30And a lot of other people in this space that you have 60 frames per second
31:33interactivity, like at, you know, that we want people to be able to use Replicache
31:38as if it's memory, you know, as if it's your, as if it's your state model, like
31:42one of the benefits that should come out of adopting these tools is that you
31:44don't need complex state management libraries, you know, you have this like
31:48database locally You should be able to use that as your as your state but when
31:52you look at that from like again from like an engineering perspective, it's
31:55actually not so easy because You know storage local storage on SSD is fast.
32:01Sure You know SQLite is fast IDB is not fast, but you can like wrap it and
32:06do things to it to make it fast but it's nowhere near as fast as memory.
32:09It's not 60 frames per second.
32:10It's an order of magnitude slower, right?
32:12So, so how do you bridge that gap, right?
32:15And if you want to have cross tab consistency, if part of the product design
32:19is that you make changes in tab A and they reflect in tab B, then you cannot
32:24use storage alone as your communication mechanism because it's too slow, right?
32:28So you have to have memory inside the tabs at some level, you have to have
32:31memory like that has the state in the tabs because that's the only way it can
32:34be fast enough and then you again have a synchronization problem like a distributed
32:38system problem between the tabs, right?
32:40They're changing independently.
32:41So how do you resolve that?
32:43There's like different, I think there's different legitimate ways to address
32:45this, but the way that we do it, which is that we basically, we use the storage
32:49as like, We, we run in memory, Replicache runs in memory, like in the JavaScript
32:53thread, in the main thread, right?
32:55So it's right there next to your app.
32:57It's crazy fast and it lazily loads and stores to IDB.
33:02And we have a, basically a synchronization protocol between the
33:04tabs which you can kind of think of it roughly as like two Replicache
33:09browsers, like sync via the server and two Replicache tabs sync by IDB.
33:13That's like the basic structure.
33:15And yes, we need to have a way to know when something has changed cross tabs.
33:18And for that, we use broadcast channel.
33:21But like, you know, it's the same if you're familiar at all with
33:23Replicache, the server doesn't send data proactively to the client.
33:27The server only sends a poke that like a tap on the shoulder
33:30that something has changed and the client requests the changes.
33:33And we kind of do the same thing cross tab.
33:35Like we, we use broadcast channel to tell the other tab, Hey, IDB has changed.
33:39And then.
33:40That tab is like running as fast as it can in memory and it has like
33:43a background process to refresh itself from storage periodically.
33:47I'm very curious to learn more about that background process as well.
33:52Are you leveraging workers at all in your implementation here, or is this
33:57mostly running in the main thread?
33:59And this is where given that you have multiple tabs, multiple main
34:02threads is most of Replicache running in the main threads.
34:06We don't use workers as part of the implementation of
34:09Replicache Currently at all.
34:11you know, we, We want people to be able to use Replicache as if it's memory,
34:15it should be as fast as memory and, the only way to do that is to be memory, you
34:19know, you could have something running in another thread, in another worker,
34:22but then you're still gonna have to have state and memory, right, so, What we
34:26landed on was, we have Replicache as a in, like an in memory main thread thing.
34:33It has a background process that syncs with IDB, but that is just like a periodic
34:37task that's running on the main thread.
34:39You can easily run Replicache in a worker, and many people do.
34:42People, like, people do this to do full text search.
34:45They run Replicache in another tab, they do, you know, indexing in that, or they
34:50run it in a worker, they do indexing in that worker, and then they, like,
34:52access that index from the main thread.
34:54And because of the cross tab communication that we have, it works fine across workers
34:58too, workers in the main thread, you know, but where to put workers in your stack is
35:03like a, is a, is an application developer question not a Replicache question
35:09I think it's very possible that we would implement workers.
35:11We would add workers to various parts of the implementation of Replicache,
35:15like as an implementation detail, you know, like there's some background
35:18tasks that we need to do, like cleaning up things, you know, that are heavy.
35:21And it would be useful to have those on a background thread to make sure
35:24they don't interfere with the UI.
35:27The one thing that like people frequently ask, and it has come up over,
35:31over the development of Replicache, whether to use service workers.
35:35and because it, it seems so tempting.
35:39It's like this shared place that you can run code, you know, across tabs.
35:42But man, service workers are like another part of the web platform.
35:45That's just so hard to use.
35:46You know, it's just so gnarly, and I feel like almost nobody
35:49knows how to use them, you know?
35:51And like, there's so few examples of them being used successfully.
35:54And if we use service workers in Replicache, it would have impact
35:57on how people build their apps.
35:58So we just haven't gone there.
36:00Once you're just a little library that you use in your JavaScript app, then
36:05I think that keeps things way simpler since I think very few JavaScript
36:09developers are even aware of the concept of a thread in the context
36:14of building like their React app.
36:16And so a worker is a thread, but once you have a library or technology,
36:20that spans, the main thread that spans workers or service workers, then you
36:25need to conceptually deal with that.
36:27But it also becomes a tooling and a bundling problem.
36:31So this is where I think the best technology that we have for those sorts
36:35of patterns right now would be Vite
36:38and my opinion
36:39so have you had success or not so much success with certain technologies?
36:45We love Vite it's like my default.
36:48It's kind of a funny story, like, when I started RociCorp which was, like I
36:52said now, almost four years ago I wasn't up to date with like the web, like,
36:56and like the popular open source tools.
36:59And my friend was like, you gotta check out Next.
37:02js, it's like, so awesome, like, you guys should figure
37:05out how to integrate with Next.
37:05js, and like, I started, like, working with it, and I was like, oh, this is
37:08like a really cool DX, but like, I'm trying to, like, what is it, like,
37:11what's the core value here, I couldn't put my finger on it, like, it's like,
37:14it's hosting, like, there's the the thing where you have deploys that are
37:18like, like, preview deploys, that's really cool, but like, is that, I'm
37:20trying to think, like, why is this so exciting, and I finally realized, it's
37:24like, the easiest way to set up React.
37:26That's really like the back then, like that's the core of it, you know, that's
37:29how like it's like setting up a react project is just so hard, like, and then
37:34I, you know, I think V has taken the has taken the crown on that front now,
37:39Yeah, I think, so my take is that if you're using Next and typically you
37:43then deploy it on Vercel, I think that's great for like anything that's like
37:48a more on the, if there's a spectrum from website to web app, then I think
37:53this is rather where you start on the website spectrum and make it more,
37:57add more and more app like features.
38:00But I think it becomes increasingly hard if you want to build a
38:04local first app with Next.
38:06js as you want to introduce those capabilities, as you want to introduce
38:10really deep storage mechanisms or once you want to work with workers.
38:14I'm sure it's on their roadmap somewhere.
38:17But I think they, they've just started their journey on one side of the spectrum,
38:21which is, I think, rather to the websites.
38:24And that's great and that works really well.
38:26Server side rendering, React server components is great for this use case.
38:31But I think once you want to build web apps that really feel more, almost like a
38:37native app, I think this is where you need to reach for a different tooling stack.
38:41And I'm currently very happy with Vite as it has support for workers
38:46as a first class citizen, was a bit rough over the last few years.
38:49But it has gotten a lot better with every release and I'm very happy using it.
38:55And I've even seen a few libraries also shipping workers out of the
38:59box that work quite well with Vite
39:02so an example here would be the SQLite WASM built.
39:05That also ships with some workers out of the box, which works pretty well,
39:11yeah we use it often and like it as well.
39:14I don't have as much experience with workers in particular just
39:17because we haven't taken it on as like an implementation detail yet.
39:20But yeah, just overall we have a lot of success with using it for our samples.
39:24And like, you know, when you're building this kind of stuff, you end
39:26up making apps all the time, right?
39:28So speaking of maybe this is a good segue to.
39:32How I would use Replicache or reflect in, in my, let's say in my React app.
39:39So I think you've been mentioning MobX.
39:42Is that a typical technology that you use Replicache with, or does Replicache
39:48completely replace something like MobX?
39:51MobX, Redux, Zustand, all those all those sort of state technologies.
39:56Are they complimentary or are they rather being replaced by Replicache?
40:02I think long, like long term they're being replaced but the reality is
40:06that Replicache isn't there yet.
40:07Like these are, you know, very well developed, like sophisticated tools,
40:11you know, like that people have, Developed, like to do legitimately
40:15hard things, you know, like, you have a fairly large data set in memory and
40:19you're trying to update like little bits of it reactively, you know, that's
40:21like a legitimately hard problem.
40:23And so Replicache has an API like A subscription, API that's memory fast.
40:28And I think it actually competes well with like SQ lite based systems.
40:32In many cases it's faster.
40:34But.
40:35I mean, if you're building something like Dax is building, you know, that
40:38has like a lot of data in it like 30, 000, 50, 000 records, you know, and,
40:43you know, you're trying to do 60 frames per second updates in there, and you
40:46have a lot of, like, computation, like, derived computation chains in memory,
40:50like, we don't have the, we don't have the APIs in Replicache yet that, that can
40:54compete with, like, MobX or, like, Signia from TLDraw, like, things like that.
41:00And the cool thing is like, the design of Replicache is complementary
41:03to putting those things on top.
41:04Like at the bottom of the Replicache abstraction stack, you have a
41:07key value store that's reactive.
41:09You know, so you can like plug those reactive changes, like, into your into
41:12Zustand or whatever, and it'll work great.
41:15It's interesting, like, different people in the space started at different angles.
41:18Like, I think that's something you've been passionate about,
41:19like, from the very beginning.
41:21There's so many exciting things happening in local first.
41:23Like, other people have started focusing there.
41:25We started, like, a lot more on making the synchronization correct and robust.
41:29And making partial sync work, authorized sync work.
41:31You know, making the mass storage, like, really fast.
41:34And we still have to like finish up the libraries legitimately, like the
41:37API layer to make it really nice.
41:39I think that it's going to be competitive with like using those types of
41:42tools, like, you know, next quarter.
41:43Yeah.
41:44I mean, Replicache has been, I think, one of the first solutions really been
41:49on the local first market in that way.
41:53And so, and I think you, you have been quite ahead there in terms of
41:57the work on syncing and just having a.
42:01A fully fledged thing out there that developers can use to build on top of and
42:06that shows I think most most of the local first apps that have been built over the
42:11past one or two years, I think, use your technology and I think that's already.
42:16driving some of the change that I want to see for our apps.
42:20So are there some apps that that you're particularly excited about,
42:25where you say, okay, this is exactly what I wanted to help create
42:29more of or help create more of?
42:31Well, I mean, right now the one that, that I'm like most
42:34excited about probably is sst.
42:36dev, Dax's thing that I've mentioned a few times.
42:39Like just because, I don't know it's an example of like a
42:43data intensive application that is like public that you can try.
42:46A lot of our, a lot of our customers are like, you know, they're private
42:49things that, you know, not easy for people to access outside.
42:52And yeah, we have a lot of.
42:56Customers using Replicache for things that are like in the building industry
42:59or like service industry where like, like we have a customer that is building
43:03like a tool that people who build houses like would use and, you know,
43:08they go out in the field and there's intermittent connectivity and, you
43:11know, actually like building a house is like a super data intensive thing.
43:15You know, there's like thousands of elements on the
43:17checklist to a house, you know?
43:19And like lots of people that have to come through and look at it and then
43:21there's back office things that happen and like, so it's like a perfect use
43:24case, but it's not something that you can like use, you know, that you could
43:28go try and use right now because, you know, it's a private system.
43:31So yeah, I think like sst.
43:32dev is like the best example right now that I'm excited about.
43:36I'm equally excited about the things that I can use myself, as well as the anecdotes
43:41I'm hearing about other technologies being created for other people.
43:46So I think this is what I'm particularly excited about Local First, that it
43:52makes it easier to build technologies for use cases that were just not that
43:58Viable before to, to build technologies with the tools that we had before.
44:02So what you've been sharing about the construction use case here, or
44:07you've been also privately sharing a few other use cases with me,
44:10those sounds, sound incredible.
44:12And this is exactly why I'm excited that local first opens
Replicache and local-first
44:18So if I'm looking on Replicache.
44:21dev or Reflect.net on Replicache.
44:25dev, for example, it says the way to local first.
44:29So I'm curious what local first means for you.
44:32I think there's a whole bunch of terms flying around, whether
44:36it's offline first, local first.
44:38So can you share a little bit more about how Replicache thinks about local first?
44:43Yeah.
44:44Yeah.
44:44So there's obviously, there's a little bit of controversy around, around
44:49naming and like what local first means.
44:51And I think this happens every single time there's like a new catchphrase in tech.
44:55Or really even in anything, like even in music or other domains,
44:58like people get worked up about what qualifies as what term.
45:02PVH.
45:03I don't know what the H stands for.
45:04Harden, Hardenberg?
45:05Yeah, Hardenberg.
45:05Oh, yeah, he lived down the street from me in San Francisco and we
45:09met up in coffee shop all the time and and talked about Local First
45:12and CRDTs and things like that.
45:14And he coined Local First.
45:15I think it was him, or maybe someone on the team, maybe it's wrong to
45:18attribute it to Peter solely, but anyways they list, like, seven
45:22ideals for Local First software.
45:24I think it's seven.
45:24And Replicache, like, does not meet all of those ideals.
45:28Right?
45:28Like, in particular, there's like the long now, I think, which is like,
45:32you know, that you should be able to keep using your client side software.
45:36If the service it depends on disappears like that, that like
45:39replicates doesn't really do that because it's a client server system.
45:42And I think there's some others that kind of point to like PDP, like in
45:45order to implement one of the seven, you would kind of have to be PDP.
45:49And like replicates is a client server system.
45:51It's like designed for, you It's designed for, like, the classic web
45:55services that people, that are 99.
45:5699 percent of the things you use every day.
45:59So, when we built Replicache, we, like, specifically called it
46:02Offline First for the longest time.
46:04And we avoided calling it Local First, you know, out of deference to that team.
46:08Because they coined the term,
46:09but, like, the thing that happened is, like, people kept calling us Local First.
46:12Like, like the users kept calling us local first, you know, and like, at some
46:16point we were just like, forget this, you know, and also like other companies
46:19started calling themselves local first that were like the same design as us.
46:23And it just the market seemed to like consolidate around this term.
46:26And I think it makes sense why it happened because it describes what people
46:31think of as this technology, right?
46:33Local first, you access the local storage first, and then
46:36you fall back to the network.
46:37That is what Replicache does.
46:39That is what ElectricSQL does, that is what all of these systems do, and like,
46:42and so it's like a correct descriptive name, and I think that's why people don't
46:46understand the distinction, and and so we just ended up like, giving in, and
46:50like, deciding that we're local first too.
46:52That, that makes a lot of sense.
46:54Local first is like offline first, but we have an additional capability.
46:58It's not just like an app that only works offline or can then like also work
47:03with a server, but it's fundamentally also giving you collaboration and I
47:08think it's more of a spectrum of, yeah, you've been mentioning the seven ideals.
47:12And if some technologies can give a foundation that adheres to all of those
47:19seven ideals, great, but fundamentally.
47:22The tools we were building and the tools we're using help us to get from
47:26A to B faster and it always depends.
47:30So I think Replicache is striking some very reasonable and attractive trade offs.
47:35And if you don't have that client server architecture,
47:39if you don't have that server.
47:41Then you are also left alone with some very hard problems that you don't
47:46really need for many applications.
47:48So I'm very excited about how you thought about those trade offs.
47:53And I think local first is a big umbrella and I'm excited that, that
47:57replication and reflect is a part of that.
48:00Oh, thanks, man.
48:01That's nice to hear.
48:02Peter invited me to like the local first party in St.
48:05Louis, like at strange loop last year or this year.
48:09And so I was like, Oh I'm in the club.
48:12I got invited to the local first party.
48:14I think this is definitely a goal.
48:15Let's bring as many people in here, particularly like people, like with your
48:20great technology background, I think you've been rooting for those ideals, like
48:25way longer than most people have started to really think so crisply about those,
48:31so before we are wrapping up, do you have anything else that you want to mention?
48:36I mean, I'm going to plug Replicache and Reflect, but before I do that I think that
48:41we're just, it's a really exciting time.
48:42Like, I think that we have been working on these technologies now for so long,
48:47like some of us, you know, and like, there have been so many things to, to solve.
48:52But it really feels like it's turning a corner and I think that more and
48:55more people in 2024 are going to be thinking, you know, I think it's
49:00time to build something local first and or at least play with this.
49:04And there's just a lot of really great options out there right now.
49:07And it's and it seems like it's growing every day.
49:10So yeah, if you're thinking about building something local
49:12first check out Replicache.
49:14dev.
49:15That's the client side only project that we have.
49:17And if you just want to get up and running quick and and not do all the
49:20setup yourself check out Reflect.net.
49:22It's fully managed and hosted service.
49:25That sounds great.
49:26I might just play around with that over the holidays myself.
49:30So yeah, Aaron, thank you so much for taking the time.
49:33We have quite a time zone difference.
49:35I'm here like in Berlin where it's already quite late and you're in beautiful
49:39Hawaii with the very background.
49:42So thank you so much for taking the time and sharing everything.
49:46All right.
49:46Yeah.
49:47I'm really looking forward to hearing the rest of these too.
49:49I'm sure you'll get some really interesting people on here.
49:51Perfect.
49:53Thank you for listening to the Local First FM podcast.
49:56If you've enjoyed this episode and haven't done so already, please subscribe and
50:00leave a review wherever you're listening.
50:03Please also consider telling your friends about it, if you think they
50:06could be interested in Local First.
50:08Thank you again to Expo and Crab Nebula for supporting this podcast.
50:12See you next time.