menu close

Aaron Boodman on Building Zero, Local-First, and Living in Hawaii

/ 01:16:10/E126
Dax:

Did Adam just leave?

Aaron:

Yeah. He waved.

Dax:

Did he say it to go?

Aaron:

He waved.

Dax:

Did he message me? Okay. I guess Adam had to drop off. Aaron was telling me about how, so he lives in Hawaii.

Aaron:

I don't

Dax:

know if you're aware. You can probably hear the birds and the nice things outside.

Adam:

That's amazing. That's why you're so tan. You got that nice complexion. Hawaii.

Aaron:

I was try at the last minute, I realized, oh, I should really do this from, like, an outdoor location that looks like, really Hawaii. But but my my own backyard, it looks it it has this one corner that looks like super Hawaii. Yeah. But the problem is I can't predict when the gardeners are gonna come. So there's, like, a 10% chance.

Dax:

Your your indoors looks Hawaii, though, too. Like, I can, like, tell you're in Hawaii. Look at this background. Uh-huh. Yeah.

Dax:

So it's not bad. My I feel like my backyard can kinda look like it's Hawaii because all the trees in Miami are imported from, like, Asia. Yeah. It has, like, that that tropical vibe. But he was telling me that he went to go

Aaron:

get that mic, and you can't next day order anything in Hawaii.

Adam:

Oh, that makes sense.

Dax:

So he's at Best Buy. And I was talking to me and Jay. We're having this conversation two days ago of, like, okay. If we would, like, radically move somewhere, you know, like, where in the world would we consider moving?

Adam:

Yeah.

Dax:

And I was, like, trying to come up with criteria to ask, an LOM being, like, here's my criteria. What makes sense? One of the things I came up with was, if a new MacBook drops, how fast can I get it? Not because I literally want MacBooks right away.

Aaron:

Yeah.

Dax:

But I thought it was a really good proxy to figure out, oh, where in the world is, like, really plugged in, you know, logistically. And, one of the interesting answers I got was Singapore, which, you know, has it has, like, the stereotype of being, like, a really high-tech city. But on top of that, it's like the logistics hub for that whole part of the world. Mhmm. So anything there, you just can get immediately.

Dax:

Like, there's no delays on anything. But, yeah, Hawaii was not not on that list.

Adam:

In Miami, you can get, like, same day stuff. Right? I don't get that in The Ozarks. Like, same day with Amazon or

Dax:

This is, like, such a what's the word? What's the word? Like, problems when it's, like, a rich person problem?

Adam:

First world first world problem.

Dax:

Yeah. First world problem. But, yeah, we we've just gotten crazy spoiled with the whole Amazon thing because in any major city, it's absurd. Like, before, it was like, oh, you pay extra, then you get, like, the faster shipping. Now by default, they just deliver it to your door, like, several hours later.

Dax:

Or if you order in the evening, it's there at, like, 3AM. So we've gotten very, spoiled by all that.

Aaron:

Yeah. I don't get that. And then I guess Hawaii is even worse. That sucks. Yeah.

Aaron:

I didn't think about that.

Adam:

But I guess if you're in if you're in Hawaii, like, who cares? Who needs stuff? Right?

Dax:

Is there an adjustment? Are you used to it?

Aaron:

Yeah. I mean, it only comes up randomly, like, when, you know, some you know, it's unlikely that it's uncommon that I feel like I need it. But it it's funny, you know, Hawaii has one of the highest bounce rates in the world of of people who move here and move back.

Dax:

Oh, really?

Aaron:

Yeah. Yeah. And so a lot of times, like, during COVID, I had a lot of people, like, from the Bay Area that were, like, I'm gonna move out to Hawaii. And I'm, like, okay. You know?

Aaron:

Like, but just beware that, like, 80% of the people bounce, you know? And a lot of it a lot of it is this. It's like people get here and they realize, what? I can't get, like, whatever my heart desires, like, the instant of it.

Dax:

Yeah. You

Aaron:

wanna rock? Did did you realize you wanna rock 4,000 miles?

Dax:

This is like the curse of islands. It's like an island is always the best place to live, but the definition of the island is, like, it's on its own and everything else you need is outside of the island. So, yeah, it's, it's tough. But you've been there for how long now?

Adam:

Six years. Nice. Didn't bounce. I don't know what the technical, like, definition of bouncing is. I don't know how long you have to stay, but six years seems like not bouncing.

Aaron:

Yeah. Yeah. We love it here. Yeah.

Adam:

What what island?

Aaron:

Yeah. I live on Oahu, which is, like, the gettowest of the Hawaiian Islands. I guess, it's the how how you measure. But it also has schools and hospitals and stuff. So

Adam:

Very important. Yeah.

Dax:

What is, what is life like? Like, what's like a day in the life of for you that's different than what other people would experience?

Aaron:

I mean, a lot of it's like little stuff. Right? Like, one one of the the most minor things and I mean, you have this where where you live, Dax, but like one of the most minor things that I love that's like super important to me is like I wake up every morning, I take my dog for a walk in shorts and slippers. Like it's a minor thing but I I love it. You know, like like, and there's beautiful mountains behind me and the clouds kind of like wrap around the mountains and I just

Dax:

It's

Aaron:

I mean, I live in a neighborhood, like a suburban neighborhood. So in some ways it's just like every day, you know, like it's just everyday life. But in the other But, you know, I used to live in San Francisco and I grew up in Southern California where it's warm. And the whole time I was in San Francisco, I freaking hated it. I hated the weather.

Aaron:

I just couldn't Because I grew up with like sun every day, you know, and so it never felt comfortable. And after twelve years living in the city with the weather, being out, be able to go out every morning in shorts is like a huge luxury.

Dax:

Mhmm. But I

Aaron:

guess like other sort of like, you know, everyday things like yesterday, yesterday was like a really calm Wednesday, which is like where we live, we don't care. Like the weather is always kind of the same, but the but the winds vary a lot. And the winds matter for like water sports. So we really look forward to calm wind days and yesterday was a dead winds day and, Abby, my daughter and I went out for a paddle on a one man canoe. That's what she does like for her sport, for her school sport.

Dax:

Mhmm.

Aaron:

And we have like local offshore islands that are like a mile offshore that are small like islets. And we paddled out to those and we looked at the fish and we like, you know, we practiced. I made the canoe like especially hard for her to paddle by sitting on the back.

Dax:

Oh, I see.

Aaron:

So I mean, like those are like everyday tends to involve like outdoor, like water stuff, for us anyways. That's different from what it listens.

Dax:

The the reason Adam and I were both laughing at the beginning when you were like, you take your dog out for a walk in your shorts, that's almost that's very similar to how I describe my day to day, except juxtaposed the way you describe it, I sound like a total crazy person because what I do every morning is I also love the sun. I love going out, getting the sun right away, except I'm, like, basically, it's in my boxers, nothing else. And I don't I don't walk my dog. I blow bubbles for him in the backyard, and he just sprints back and forth for ten minutes. So, you know, same.

Dax:

I totally get it. We basically do the same thing.

Adam:

I put clothes on. I wear clothes when I wake up. Max's goal is how long in

Aaron:

the day can he go without putting on clothes? That's what I

Dax:

Remember how annoying I was when it was cold for two weeks and I had to, like, put on

Adam:

I do remember.

Dax:

Like, a sweater before going outside? Yeah. That does sound nice, though, the water. I think what I what's cool about, different places is, like, the hobbies, like, orient around, like, the physical environment. And I really should get into water sports stuff.

Dax:

I've been here for a while. I've just been too busy to, like, develop a hobby, but I really want to pick up something that involves that. Because you can't do that in most places, you know?

Aaron:

Yeah. Yeah. I mean, I talk about that a lot with my kids, you know, is like, and with other people who visit us is like that, that I also find that really interesting how the lifestyle, like, you know, I mean, I guess it shouldn't be surprising. But I think that in, you know, like hyper connected, like online world, people just sort of assume that, you know, every place would be in some ways they have this, like, deep assumption that life will be the same. But there's these, like, ways that it's different and it has to do with, like, the physical environment, you know?

Aaron:

Like culture, culture like adapts to the physical environment and like, you know, Hawaii is like famous for surfing and blah blah blah. But where we live in Hawaii, it's always onshore winds, because of the trade winds. So like three hundred days out of a year, it's onshore winds, which is bad for surfing. Oh, I see. People don't surf here on this part of the island and what is the hobby instead is this, either like kiteboarding, is really popular here.

Aaron:

Those sort of like wind sports or,

Dax:

That's what I want to get into. Yeah. Yeah, it's pretty big here too.

Aaron:

Or like canoeing, paddling. And so I always like laughed at these like old men who are into paddling. When I moved here, I'm like, I'm never going to do that. I'm going to surf, you know, blah, blah, blah. And like, you know, I did try to, but then it involved, like, driving thirty minutes every day.

Aaron:

And then I, like, tried the canoe one day and I was like, oh, this is pretty fun, you know? And it's, like, unsurprising. People do it because it's fun, you know? Yeah.

Dax:

Also, there's people like, I I follow a bunch of people that are, like, kinda in the fitness space. A lot of them are older. They are so ripped, and all they do is paddle. It's, like, such

Aaron:

a good workout for your whole body.

Adam:

Oh, that's

Dax:

a workout.

Aaron:

Yeah. Yeah.

Adam:

We go to the gym, and we try to simulate it. Right? Like, we're gonna pretend like we're yeah. Like we're in a boat canoeing. Yeah.

Aaron:

Yeah. I mean, it's a workout. You're out on the water. It's beautiful. You know, it's I think it's like the same reason that people like, you know, like backcountry skiing, you know, which involves a lot of walking and stuff.

Aaron:

And, you know, mostly you're out in nature and then there's like every so often there's a little bit of adventure too, you know.

Dax:

Yeah. Nice.

Adam:

Guys are making when we wanna go outside. I just we've spent the whole winter in the Ozarks inside. It's just depressing. Can't wait to do something outside. Yeah.

Adam:

Basically.

Dax:

Let's do a quick little intro now now that we're we're, like, you know, fifteen minutes in. So this is Aaron. Aaron's the founder of is it Rossi Corp or is it Rossi Corp? I remember you were you were posted yesterday, like, laughing at people struggling to pronounce it and I'd be thinking about it.

Aaron:

I I say Rossi Corp, but but Rossi Corp is also correct. It's it's named after the Ralstononte, which is, Don Quixote's horse in that book, but it's also the name of, the ship in The Expanse, the science fiction novel and

Dax:

Oh, interesting.

Aaron:

Television series. And that that works Is

Adam:

it a good series?

Dax:

Is that

Adam:

a Oh, yeah. Yeah. It's very into sci fi lately. So, I need new ones. Expanse?

Adam:

Yeah. Okay.

Aaron:

Yeah. The Expanse, the series is I mean, it's an investment. You know, those books are are big, and there's, like, eight of them or something like that.

Adam:

Oh, jeez. Okay.

Dax:

Yeah. Yeah. It's pretty cool. It's like, they explore it's like a future where Mars is colonized, and then there's, like, a third entity, which is all, like, the mining operations in the asteroid belt. And it's, like, a crazy political tie between Earth and Mars and then, like, these Belters, I guess, I forgot they were called.

Dax:

It's pretty good.

Adam:

Okay. I gotta write it down.

Dax:

Keep going. Sorry. I interrupted you so badly. People probably don't recognize that name, but they might recognize I mean, they'll definitely recognize as I talk about it incessantly. So your company makes, initially made Replicash.

Dax:

That's how I met all of you. And then more lately working on on Xero, which has been really fun. We've got it into production past couple weeks. Adam just sitting there, like, wishing he could he had something.

Adam:

I can't wait to learn so many things on this call. I don't want to be annoying, but, like, I have so many questions, and this is the thing I've hovered around just being close to you, Dax, for so long. And I need I need to just take the time to get up to speed. And I feel like a lot of people listening probably do too because there's a lot of people that probably are like, local first. Yeah.

Adam:

I've heard all this. Like, I just never done anything with it, and, like, we all know we should.

Dax:

Yeah. It's well, it's this funny tight little circle because the other day, I I posted because I wanted to talk to bunch of bunch of AI companies using SST. At one, I thought I would get, like, five responses. We ended up getting, like, 30 companies that reached out, and a bunch of them were like, oh, yeah. We're doing AI with SST, and also we're using Xero.

Dax:

And I'm like, this is such a funny little little circle?

Adam:

Bubble. Yeah.

Dax:

Yeah. But, yeah, I mean, the reason I was mentioning that is I think the reason we got in this call was someone asked you a question about some of the previous things you guys have worked on prior to this, which I hadn't known

Aaron:

Yeah.

Dax:

Much about. So we're kinda talking about, like, you telling a little bit about that story.

Aaron:

I never it's it's a long story, so I don't I never know, like, where to start

Dax:

or how No. Just go. We can we'll

Adam:

definitely We had DHH on, and he talked for, like, ninety minutes straight, and we never said a word. So you can really

Dax:

do anything. It doesn't matter. See it in the audio. The audio Yeah. Bars in our editor, it was just him talking and then me and Adam just completely empty.

Adam:

So you won't do that, so you're fine. Do whatever you want. Yeah.

Aaron:

I mean, so, one story I always tell is that, you know, I worked at I worked at Google for ten years.

Dax:

I'm actually gonna interrupt you already because I I wanna say one thing before you start. So I actually technically intersected with Aaron when I was, like, 15 years old, because I was a GreaseMonkey user, and I was using it to steal gift cards from this site that didn't protect their URLs for properly. So I, like, didn't know that there's probably a better way to do it, but I have I was, like, messing with Grease Monkey, and I wrote some kind of script that just kinda iterated through every combination of URL. And I and I got I think I I stole enough for, like, a hundred $10 worth of $5 gift cards, and I bought an Xbox hard drive. And then I got really scared, and I stopped doing it.

Dax:

Yeah. So that that was Aaron's work.

Aaron:

Making the world a better place. Love it.

Dax:

Yeah. Yeah.

Aaron:

So I I after after Grease Monkey, I actually kind of got me the job at Google. And I didn't work I worked on Blogger for, like, a very short time. I got thrown off that project, like, within months. And, like, funny story about that. But, but I found myself on this project on this this, like, group that was, like, had people that were supporting Firefox.

Aaron:

So we at the time, Firefox was, like, not the biggest browser, but, like, a growing important browser. And it was really important to Google that there be, like, an alternative browser and that the web succeed, and so they were, like, putting money into supporting Firefox. They had they were paying people to work on Firefox, and they were also paying people to build extensions and stuff like that. So that that's how I ended up on that project. And one of the very first things we built, the very first thing I built on that team, this was literally like four months into my Google career, was we were, like, brainstorming ideas for extensions and ways that we could, like, ways that we could, you know, support Firefox.

Aaron:

And we came up with the idea of syncing bookmarks in history. So we wrote this extension for, for Firefox, to sync your bookmarks in history between different Firefox instances, which is now, like, a major feature that, like, a lot of browsers have. And, my friend, one of my best friends at the time, that worked at Google, made this side joke to me one day. He's like, you know, we're going to be working on sync for the rest of our careers, right? The foreshadowing.

Adam:

That's really funny.

Aaron:

The funny thing is that, like, he was more of, like, you know, right on the edge of, like, designer and engineer. You know these types?

Dax:

Mhmm.

Aaron:

And he became the lead designer of Chrome and then went on to become the lead designer of Android. Wow. So we've got, like, you know, did really, really well. No longer works at all. Forget about the rest of his career.

Aaron:

Never worked on sync again after that. So he he learned his lesson. But Yeah. So I mean, I guess, like yeah. So I worked on that that little sync engine.

Aaron:

And then, at Google, I worked on Gears, which was a way that we were trying to add sync to browsers as an extension, so that we could build off on Gmail. And then, you know, I sort of came back to sync on and off throughout my career. And, like, after I left Google, I had this friend that I worked closely with at Google, and we were really inspired by, Git, the version control system and how it worked internally. Like, if any of you if anyone list if you've ever, like, looked at how Git works, like, the the UI, the is a disaster. The CLI is a disaster, like, a famously terrible disaster.

Dax:

Mhmm.

Aaron:

The internal design of Git is just beautiful. You know? Like, if you're into software, it's just a completely inspired idea.

Adam:

This is

Aaron:

one of these one of these, like, things that I feel like is, like, discovered, not not, like, invented. You know? Right. And especially if probably a lot of people listening to this have no familiarity with source control before Git. But, like, it was just this horrifically complicated thing, you know, that didn't work at all.

Aaron:

That was, like, really slow. And so we were really inspired by this and having worked on sync, like, multiple times throughout our career and knowing how complicated it was. Like, we had this intuition. Like, what if, you know, what if you could have something that worked, like, using the same principles as Git, but it worked for, like, application data. You know?

Aaron:

And so you could have sync, you know, that that worked really well. So me and my friend, Raf, we started Attic Labs sort of on this on this idea. And we built Noms, which was a a new database, basically, that used sync that was very similar to Git's internal design.

Dax:

Mhmm.

Aaron:

But pretty quickly after we started the project, we got scared off the original idea of doing, like, application level sync because of conflict resolution. Because Git doesn't do conflict resolution. Git just, like, you know Makes

Dax:

it easy to deal with it. Yeah.

Aaron:

And and when we started looking at that, we, like, didn't have any great ideas and we're like, well, maybe, you know, just the core idea of, like, you know, syncing structured data without conflict resolution is, like, useful enough by itself. And this useful enough is, like, a theme I feel like I hope that we'll come back to, like, in this in this call. And it's something that I've I've, like, learned my lesson on. And I feel like I I've learned a lot from you, actually, Dax, about this. And so, but but, anyways, I think that was a mistake that we made early on with with Noms, and we we sort of, like we're, like, what what can we get away with?

Aaron:

You know? Rather than, like, what's what do people actually need? You know? Mhmm. And so we we started trying to take this idea and making, like, a a a synchronizing application database for it and sort of, like, searching for a problem, you know, that this could solve.

Aaron:

And we build Noms and it's, like, really cool tech, and we couldn't figure out, like, how to market it because we didn't start with a problem. We started with, like, a thing. You know? And after, like, four years, like, we built this really cool database and, the team was getting tired, some of the team. And so we decided to sell the company, and we sold it to Salesforce.

Dax:

So just just to understand a little bit better, like, this database, like, how did it fit in to someone? Like, is it, like, ends up being the primary database for your application?

Aaron:

We didn't we didn't know. You know?

Adam:

Like, we're

Aaron:

we're, like, we're, like I mean, this sounds so stupid in retrospect, you know, and so and so cliche. But, like, you

Adam:

know, we I

Dax:

mean, we've all we've all been in that exact situation, so it's very relatable. It just sounds so stupid when you explain it ten years later when you're a lot smarter.

Aaron:

Yeah. So, like, you know, we we we were like we are like, okay. What if you take, you know, the way that that Git works, but you store structured data instead of files? You know? Mhmm.

Aaron:

Internally, Git has a data structure that looks very similar to a b tree. You know, but it's not a b tree. And and databases use b trees to be fast. So we're like, what if you combine these things? You know?

Aaron:

Uh-huh. What happens? You know? It was it was a go like, basically, what Noms is is it's like an embedded database, kinda like SQLite, written in written in Go. And it has this sort of weird data model that's not relational.

Aaron:

It's it's it's more like a graph database, I guess.

Dax:

Mhmm. And

Aaron:

that was kind of like custom designed again because we weren't really I don't know why we would we just have it that way. We had some ideas that I'm we did have some ideas of how it would be used and that cost us to build this unique data model. But also, I think we were kind of scared off by the relational thing, you know?

Dax:

Mhmm.

Aaron:

And again, we were like, what can we get away with? I feel really embarrassed admitting this now, but, you know, it was my first startup.

Dax:

If that was your first startup, like

Adam:

That acquired by Salesforce. Yeah. You're doing okay.

Dax:

That's that's pretty good. You should have seen okay. It wasn't until, like, my fourth startup where I started to sound, like, somewhat competent. So

Aaron:

It's this embedded database written in Go, and it the sort of key innovation is this data structure called a poly tree, that we invented, which is like a mashup of a b tree and, and and gets, like, internal content addressing system. And you can like, I don't know, you can use it like SQLite except for the differences that you can like really efficiently replicate it to someplace else. You know? So Right. So think of like think of like Lightstream, you know?

Aaron:

Mhmm.

Dax:

You know,

Aaron:

you can kinda do that but it's like built on these like git data structures. We had a bunch of ideas for how to use this. And I think, you know, if we would have kept going, we could have, like, found something. But, but the interesting story is that, like, aft we open sourced it. So, like, after we sold the company, which was really just like a acquihire, But after we sold the company, there was this other company called Dulp that came along and they actually had an idea for how to, like, commercialize this.

Aaron:

And they took

Dax:

Oh, interesting.

Aaron:

And they made, like, a successful, like, startup out of it. So they they they took Noms and they made it into a relational database, like a MySQL compatible relational database. So they built this thing called Dulp that looks on the wire exactly like MySQL. You can use all the MySQL tools with it. You can, like, you know, you can literally store MySQL data in it and program against it like it was MySQL.

Aaron:

But it can also but it also has this really efficient, like, one way sync built into it.

Dax:

Nice. But what is this powers? Powers like regular applications? Or was there, like, a specific type of

Aaron:

thing that particularly you Dolt started out wanting to use it for like sharing datasets. Like their idea their idea was that like, you know, we have like GitHub for sharing code and like at the time like AI wasn't really going but like with like like, data science was, like, really popular. And, and they were, like, you know, you need a place to share, like, public datasets. So they created this thing called DoltHub, and, and and they tried to, like, bootstrap an environment, like, an ecosystem of people sharing public datasets on there. Like, a big part of data science, I I under my understanding is that is, like, cleaning and, like

Dax:

Yeah.

Aaron:

It's not like the actual, like, science part.

Dax:

Yeah. It's not glamorous. Yeah.

Aaron:

It's it's like removing mistakes from data, like, manually. You know? Mhmm. So there is kind of a I guess there is kind of a need for, like, a place where you can share these datasets. But then it also turned out that a lot of people wanted to use it, like, as part of workflows.

Aaron:

Like, they wanted an application database that, like, supported branching, basically. Mhmm. So, like, I I my understanding is that people it's it's popular with, like, biotech, you know, because they're, like, working on these big, like, genome datasets and they wanna support, like, branching internally, on these datasets. And it's also popular, my understanding, with, like, game developers for the same reason. It's, like, they have these huge, like, asset, you know, stores.

Aaron:

That team has been going now for, I think, like, four years. And they they have this, like, crazy slog. Right? They're trying to implement MySQL compatibility, you know, on a different database. It's just, like, it's just an insane amount of features, you know, to just, like, crank out, you know, and, like, bug for bug compatibility.

Aaron:

And that was another team that I was really inspired by when I went back Mhmm. To do another startup. It was just, like, watching, like, how dogged they were at just, like, pursuing this vision, you know? And, like, and how slowly it took for it to get traction, you know? Because, like, you know, initially, like, just nobody cared what they were doing, you know?

Aaron:

Yeah. And they, you know, and they just kept at it, like, month after month after year after year, you know, and it built little by little. And I, you know, I realized, like, okay. Like, these things, you know, they take time. You know?

Aaron:

Like, people can't just drop what they're doing and use your thing, you know, like, the day they hear about it. You know?

Dax:

Yeah. Yeah. Yeah. Especially in especially in dev tools. Like, even if they love your thing, how often are they starting a new project?

Dax:

It's like, at best, maybe a year from now, they might have the opportunity. So, yeah, patience is is huge. But, yeah, I mean, it's just funny. So you were inspired by that. I kinda similar thing with, very similar mindset to you because be and I think this was just kinda how startups were framed and maybe are so framed.

Dax:

It's all about, like, ship the the smallest thing possible and, like, you know, it doesn't matter if it's great. Like, you know, you try to get traction right away. If it doesn't work, give up a bun. Next thing, that was, like, the vibe, especially, like, in the in that time. That's that's, like, kinda how I thought about everything.

Dax:

And it wasn't until I saw Bun, that this click for me where I was like, his task is so clear. There's no mystery to it. It's like, you just need to achieve a % no just compatibility. That's a task. Very straightforward.

Dax:

It's just gonna take a lot of brutal effort to incrementally get there. And I just saw how, like, something about that simplicity is nice. And then two, I saw the clarity of, like, oh, yeah. Like, if something can be created within a month, it it nearly only has one month of value. It takes four years to make BUN somewhat usable.

Dax:

That clearly is more valuable. So just as a good fundamental level, like, that kinda clicked for me. And a lot of people talk about this. Like, Paul Graham has something about, just do things that are hard because it drags your competitors over the same path. So this this idea has been around for a while, but, yeah, it also took me a while to not shy away from stuff that looked too big and instead feel the opposite.

Dax:

Like, now I get more excited when it looks like it's really difficult. Yeah. Because the easy things are never actually they're never actually easy. You know? It seems easy.

Dax:

You go and do it, and it turns out, you know, it's not really gonna hit the way you hoped it would or, like, there's, like, a bunch of other people also doing it.

Aaron:

Yeah. I mean, it depends on it depends on what you mean by hard too. Right? Like, my my cofounder, Ralph, at Attic, you know, he he had I remember this day where we were looking at some some problem inside the data structure blah blah blah. And it, you know, I think we were we were gonna try to scale up Noms to, like, run on s three.

Aaron:

We actually had this idea of backing Noms by, like, s three that which is now a thing that people are doing. Anyway, we were looking at that and he and we realized it was gonna be really hard. And he was like, well, that's great. You know? Like, because, like, hard we can do, you know?

Aaron:

And and but there's and and that was true. But, like, there's also this other kind of hard. This, like, really boring, like like, frustrating hard where, you know, there's just, like, a million like, you're talking about with fun, you know? Yeah. Or, like, we encounter this a lot at, Rassy Corp with, like, making, like, stuff work with every stupid, like, tool in the JavaScript ecosystem.

Dax:

Yeah. Yeah. Exactly.

Aaron:

Like, oh, darn. Yeah. Like

Dax:

For for me, it's Prisma. Prisma has been that they've been killing me. Prisma plus the Lambda has cost me so many hours. Like, I've been more productive trying to, like, dethrone Prisma than, like, trying to get Prisma to, like, work right. Yeah.

Dax:

I

Aaron:

mean, like like, I mean, these tools are are are popular because they they do something useful. So it's like, I don't wanna I don't wanna, like, crap on, you know, the these tools. And, like, I don't know what it is about the JavaScript ecosystem in particular that inspires, like, seven different ways to do every single thing. You know? But it's just the reality.

Aaron:

Right? Like Yeah.

Dax:

So you just gotta get to work. You know? It doesn't matter what opinion you have. Like, if you're not gonna just make everything work, your thing is just not gonna grow. And that's another lesson I feel like I had to, like, flip my instincts on.

Aaron:

Yeah. Yeah. Yeah. So anyways, that was that was that was Noms. And so we sold that to Salesforce.

Aaron:

And, I think, like, some of the team is still there. And but, like, I I stayed for a little while, not not too long, and then and then left. And I experimented with a few other, like, companies, but I think I, like, still, like, really in my heart wanna do my own thing. And I started tinkering with sync again.

Dax:

I'm addicted to sync.

Aaron:

Well, I mean, there's worth it's worth talking about that too. I mean, the the reason why is because it makes really good UI, you know? Yeah. And, like, I started my career as a UI developer, you know? And I like making things, I like making UI, you know, and and making things really fast.

Aaron:

And, unfortunately, you know, just the reality is that, like, all software today is client server. You know? So, like, when I started out doing UI development, I was making all these JavaScript widgets and stuff like that. And you can make those widgets really fast, but it doesn't really matter because they have to talk to the server. You know?

Aaron:

So you can make the menu drop down really fast, but then they click on something in the menu, it has to wait for the server to you know? Right. It's just, like, fundamental thing. And if you wanna make really good UI, you need the data local. You know?

Aaron:

And so that's that's why I keep coming back to sync, and I think that's why, like, the industry keeps, like, coming back and looking at sync every so often. Yeah. So I was, like, thinking about it again, thinking about noms and, like and I stumbled across this, this paper. I think the the there was, like, a research paper called Calvin. I can't remember the whole title of the paper, but it introduced this idea of how to do a distributed database.

Aaron:

It was, like, a competitor to Spanner, Google's, distributed database. It was, like, a totally different domain, but it had this idea in it that was new to me. And that idea, I realized, like, could be used to solve the conflict resolution problem that we had in Noms. Like, if we had that, we could add it to Noms. And then Noms could have been used to build something like zero's used for today.

Aaron:

And that turned into Replicash. So Replicash at a very high level conceptually is basically NOMS plus this conflict resolution mechanism. Like, internally actually, like, Replicash doesn't use a PolyTree anymore, but when we started out, it used the PolyTree. It's this immutable b tree, that allows you to, like, rewind it and fork and stuff like that efficiently. So, like, internally, Replicash is forking and that's what makes the conflict part of what makes the conflict resolution mechanism work.

Aaron:

And then the other part of it is, like, replaying functions on this fork. And that replaying functions idea, that was the idea I got from Calvin. Mhmm. Yeah. So we started building replicash on top of Noms, but, like, Noms was written in Go.

Aaron:

And that was completely impractical for web applications, because you can theoretically compile Go into, like, WASM or whatever, but the smallest binary is, like, five minutes.

Dax:

Massive. Yeah. Yeah.

Aaron:

So we rewrote it in JavaScript. Or do we agree? No, I think we wrote it in Rust first. I can't remember. Yeah.

Aaron:

I can't remember what JavaScript.

Dax:

You have you have to take that detour. It's that it's a little bit Prisma is doing. Prisma did that, and now they're going back to at the JavaScript.

Aaron:

That was a that was a nightmare. So that yeah. Anyways, we rewrote it. And then a little while later, we ripped out the Polytrees because they weren't really we have this simpler immutable data structure internally now.

Dax:

Mhmm.

Aaron:

And, yeah, we built Replicash, and it was, like, you know, a lot more popular than anything we had done before, like, my startup journey, like, it was okay. So people are using this. You know? What what value out of it? You know?

Aaron:

And, you know, I mean, it became, like, fairly popular. You know? Like, I think, like, I I I should have had the number number originally, but I wanna say, like, tens of thousands of, like, individual developers using it. Like, millions of end users, you have used Replicash, like, without knowing, you know, as part of the applications that they're using. And, you know, it last we we built we worked on that for, like, four years.

Aaron:

You know, it's, like, fairly successful. Our biggest customer is Vercel. So and they're still using it. And, you know, like, even despite it being kind of, like, at odds with their, you know, marketing, like, they they get a lot

Dax:

of knowledge on it. It's it's for their, their that the common system on the previews. Is that what the powers? Yeah. That makes sense.

Aaron:

You know, I feel a little bit weird, like, saying this, but, like, you know, people often tell me that they, you know, that they consider Replicash, like, one of the leaders or, like, the leader in this, like, fledgling, like, sync industry. And, so, like, that's cool. And we we could have, like, kept going with that. But, like, you know, we we just got this, like, continual, like, complaints and and, like, struggles with Replicash, like, from from all of our users who were serious about it. We received the same sorts of problems.

Aaron:

And they were basically like, well, what do I do as my application gets more popular and there's more data in it? Like, the Replicash is kind of assuming this model of syncing all the data to the client. And there are what is ways in Replicash to sync less than all the data, but they're really hard to use. And so the best the easiest way to use Replicash is to sync all the data. And what do I do if my data isn't like if there's complex granular permissions in my data, where, like, even syncing the right subset of data that users have permission to isn't even, like, easy to isn't even easy to do.

Aaron:

You know?

Dax:

And

Aaron:

we just kept hitting this problem. And and along this time, like, the local first movement was, like, gaining steam. And so a lot of people were, like, hearing about local first and, like, thinking, oh, I could use this for my client server application to, like, make it fast. You know? They weren't really interested in, like, the the, like, data ownership part.

Aaron:

They were interested in, like, making my application fast part. You know? Yeah. And and so local first started gaining steam, and we were like you know, at some point, we were just like again, like, this design of Replicash, it was like we we purposely you know, we we we we consciously tried to, like, narrow the problem. Like, I at the time, I wouldn't have described it as, like, what can we get away with?

Aaron:

But, like, really, you know, if I'm honest with myself, you know, that that would that's it. You know? Like, you know, just trying to, like, avoid the really hard problem. You know? And so we, like, designed it in this way that was, like, you know, like a smaller, like, subset trying to lop off the majority of the problem, you know, which was just, like, partial sync, you know, and permissions.

Aaron:

And so with Xero, I think, like, around, like, a year and a half ago, you know, I I started getting, like, really frustrated with receiving this question over and over again, and seeing, like, the local first movement grow and seeing, like, the energy and excitement about using these tools. And, like, I also there were other people in the space, like, who had interesting ideas, like this idea of replicating from Postgres using the wall. It was, like, a really cool idea. And I realized that we could put some of those ideas together and, like, really go after this problem and solve it. And maybe do something, like, really general, you know, and bring this, like, this experience.

Aaron:

You know, at the end of the day, bring this kind of UI experience and this developer experience to, like, the vast majority of software. You know? Like, we can make something general purpose like the way that REST APIs are general purpose today. You know? Yeah.

Aaron:

And that was a really long story. So

Dax:

No. No. That that was great. It's it's just I didn't realize I didn't really put it together how long you've really technically been thinking about this. In my head, I was just like, oh, Aaron's like the browser guy.

Dax:

Like, he likes to do stuff with, browser features, but it's actually way more specific than that. I think what's also really interesting and, like, I love making this point. You were like, yeah. I'm a UI engineer. I wanted to make UI faster.

Dax:

And you ended up having to dig into, like, distribute systems, like, the way, like, data is stored in, like, literal files, like, you know, all that stuff to make the UI faster. And people nowadays, it's so easy to just carve out this I'm a front end engineer identity. But, like, you're yeah. You're you're effectively a front end engineer through this whole thing, but you have to do so many different things that, you know, technically don't fall under that bubble. So I think it's cool to, like, really see that in action over over years.

Aaron:

Yeah. I mean, there's I mean, there's it's it's actually a really common story in the sync and local first space. Like, I would say the majority of people who I really respect in the space are doing really interesting work sort of come from this background of, like, you know, being people who work with the pixels, you know. And and you're like, this is so frustrating. Like, why can't it be faster?

Aaron:

You know? And then they they hear about, you know, they hear about sync or they hear about Local First and they start looking into it and they get really inspired and they become distributed systems engineers, like, Yeah. To solve this problem.

Dax:

Yeah. It's funny because I had the I had the opposite experience, which leads me in a funny place. So I'll explain what that is. So I, did a bunch of distributions of some systems of work. And in that, I ended up building something that did that was kind of similar to solving this problem.

Dax:

It wasn't for web. It was for native. So we would we had data model in our system, any mutations to it would get synced to iOS and Android Android apps. And it kind of was very productive for our team. Didn't handle a lot of things well, but it was kind of my first introduction to that idea.

Dax:

And then I wanted to keep using that pattern because, just to speed. I mean, it's funny because we did we talk about this stuff like it's new, but native engineers are kind of more used to this pattern of, like, keeping the data locally, Probably mostly because they have to deal with offline a little bit more. But like you're used to native apps, like keeping your data around and like being able to access it right away. But I shifted back into web and then I wanted to keep using it. So I started to explore, alright, how do I possibly achieve this with, like, everything that's out there?

Dax:

And I went on this, like, really crazy journey from, discovering Orbit, which I probably come across, which is a, like, a front end tool. And if your back end is a JSON API, it does some, like, kind of smart caching with the objects and kinda understand your schema. Tried to use that, got to a certain place, hit a wall. Then I was like, okay. Let me somewhere around this time, I did come across Replicash, and I remember going to the website, and I I was like, no idea what this is.

Dax:

I don't get it. And then I moved on. I moved on to try to make GraphQL do what I needed to do. I ended up using Urkel a bunch that also had some, like, caching functionality.

Adam:

I remember Urkel.

Dax:

Yeah. Yeah. Hit a wall with that. Then I was like, let me go look at the replica cache thing again. I was like, oh, wait.

Dax:

This is what I'm looking for. Ended up using replica cache. And then now I'm using zero. As a with replica cache, you know, I hit the same walls where, like, the windowing, I temped myself and, like, some of the permission stuff and the error stuff. So, again, I'm really focused on solving those problems.

Dax:

And now we have Xero, and I'm like, oh, okay. All the problems I've been seat looking for for the past four years are now solved, which means the remaining problems for me are, hey. Like, making sure, like, the hover animation, like, looks right, which I which is just not where I came from. So I I I finally achieved what I wanna achieve, but then I'm bottlenecked by, like, my my, like, just front end detail stuff. So it's down to just CSS now.

Dax:

That's, like, my that's what's limiting me to get to where I want. Yeah.

Aaron:

We we joke about that, like, sometimes with Z bugs, you know. As part of building Xero, early on, we decided that we should have a dog food app that we are building, like, that's driving the development of Xero, for, like, a lot of reasons. Like, one of the one of the reasons is just, like, it it seemed, like, poetic to me. Like, like, I like I like the elegance of it. Like, that like, all of these, like, local first and sync tools, they all make a linear demo.

Aaron:

Because, like, linear is this famous app that uses sync that has this really great UX. And we made a Linear demo with Replicash. Right? But it's a demo. Like, we knew when we built it that it was a demo.

Aaron:

And, like, with that word demo, there's, like, so much loaded you know, there's always when you when if you're a developer and you see a demo of something, you should just take that to to to imply. There is, like, some dragons hidden in this. Like, you don't know which ones you don't get to know which ones they are. You know? Yeah.

Aaron:

But, you know, but there's some dragons that, like, the developer skipped over because it's a demo. Like, and for us, like, you know, with Replicash, you know, like, the some of those dragons were, like, fine grain permissions, partial sync, and, like, you know, a bunch of other ones like like like deployment, you know. And and, so we wanted to, like, make sure with Xero that we were not skipping over the hard problems, that we were not making that same mistake. I wanted to make sure that we weren't making that mistake again. And, like, that we were really building something that you could use to build real software.

Aaron:

So, like, the best way to do that is to, like, build something real, You know? And then the other thing was, like, we knew that zero was gonna be open source, and so we needed a bug tracker. And that meant, like, our only option was basically GitHub, you know, or or GitLab. You know? And and and, like, I just cannot deal with the fact that, like, here we are trying to build, like, a sync engine for building things like linear, and we're using, like, GitHub.

Aaron:

This just Yeah.

Dax:

It's awful.

Aaron:

You know, like Yeah.

Dax:

I I literally sync my GitHub issues into linear and just use linear as a front end for GitHub. That's how that's how bad it is.

Aaron:

Yeah. We kinda we kinda considered something like that. But

Dax:

No. Having your own thing makes total sense for the dog food.

Aaron:

There has to be, like, an it's it's an open source project. Right? So there has to be, like, a public

Dax:

Public yeah.

Aaron:

Yeah. You and people need to build file bugs and, you know and that's kinda interesting too because like like linear I don't I don't know I don't know if linear linear doesn't support fine grained permissions within a repo. So you you can't create, to my knowledge, sorry if I'm wrong linear folks, I've looked at this like multiple times. To my knowledge in linear.

Dax:

Create a private issue now.

Aaron:

Yeah. Like, within yeah. Like and so and also there's no such thing as public issues. Like, you can't create an issue that's world readable. And I assume this has to do with, like, design of the sync engine.

Aaron:

I don't I don't know if that's true. But but, like, we we really needed this for z bugs. Right? Because, like, it's an open source project. You need to be able to see the see the bugs publicly, comment on them.

Aaron:

Right? And because the the bugs need to be visible publicly, that means they need to boot up fast. You know, like, you can't wait ten minute or, you know, five minutes for the thing to sync. You know, that means you need partial sync. You know?

Aaron:

So this is really interesting to, like, build a real app because it brings up these questions that real users have. Like, when when we were using rep when we were doing Replicash, people would always ask us, like, well, what do I do if I have, like, a public page that people need to visit without being logged in? And we're like, well, you can, like, you know you know, but if we're building it for ourselves, right, we're not gonna do any we're not gonna do any of those weird hacks that that we were maybe suggesting that people do, you know? Like, we we're gonna be like, no. Let's just, like, fix the infrastructure to work the right way, you know, so that we can do this.

Dax:

Yeah. It it's funny just having worked in, you know, building stuff for developers. I've had this experience so many times where someone mentions a problem to me, and I'm just like, oh, yeah. It's annoying. But then I don't think that much of it.

Dax:

Then I run into it, and all of a sudden, it's like the number one priority, and we gotta get it fixed right away. So it's just yeah. Like, it's a like, that's just the reality of it. Like, until you hit it, you don't really understand how important it is to fix.

Aaron:

I guess I guess, like, you know, part of it is, like, we just develop you know, all of us just develop a skill for for focus. Right? So it's like, you know, there's lots and lot of things that you can work on. There's lots of problems. Right?

Aaron:

And you naturally develop an ability to, like, focus on the one that you're working on. You know?

Dax:

Yeah. That's how you you need some mechanism because, like, there's always a thousand tasks and you just need some mechanism that orders it for you. And having your own product is a very good way to do that because, you know, at least you're not making up, like, working on fake stuff, which as stupid as that sounds, like, that's, like, the biggest challenge. Like, you end up spending a lot of time working on fake made up stuff, and having your own thing kinda really focuses you. The the posting demos thing, it's it's funny because I I've always felt this way where I'm like, if I'm gonna post a demo showing something off, like, it needs to be a thing that's in production and, no idea, like, even even making money.

Dax:

So I can be like, this is, like, not just me, you know, messing around. And I remember once I posted a demo of our search, and it was powered by Replicash. And I was searching through, like, 50,000 patients, and it was it was all instant. And I was, of course, in my usual tone, I was very annoying about it and made fun of everyone for their stuff not being this good. And so many people got really pissed off, and they started making these demos of being like, this is not even hard.

Dax:

Look what I can do. And every single one was just someone wiring an on key down to, like, a query to a server that hits Postgres and, like, round trips. And, yeah, like, when you just do that on a demo when everything's running locally, you can guarantee that the end user is, like, not too far away from your back, like, all those different variables. Of course, you can achieve that.

Aaron:

These are videos of Postgres running locally? Yeah.

Dax:

Yeah. It was all it was all local hosts. Well, what first, people accuse my video of being all in local host, which is a which is a great compliment. I get this all the time whenever I show off local first stuff. They're like, oh, yeah.

Dax:

Like, now I tried to play into production, and I'm like, bitch, check the URL. That does not say local her first. That's local host. Yeah. But, yeah, a lot of people were just posting these, like, stupid local host ones.

Dax:

Some people did ones that were actually deployed, but, again, like, under perfect conditions, very hard to make something that looks similar. But an actual app with real world constraints. Like, we had all sorts of weird problems of, like, okay. The this this business have 50,000 patients to look through. You can't sync the whole patient because that's way too much data.

Dax:

You have to sync, like, a partial of it. And then when they click into it, you have to load the full thing in and then keep track of which patients they're interested in. Like, all those just things that come up when you build and polish a real world real thing. So I I really like I really try to post stuff that's real world, and I expect people to recognize the difference, but people often don't. They just think it's, like, the same as any other demo.

Aaron:

Yeah. Well, this this this goes to, like, something that also you and I have talked about, you know, in in DM about, like, marketing. You know? It's it's this is another thing that I've learned a lot about, like, over my my startup journey quest. Like, I mean, it's not really people's fault that they don't see the, like, you know, the the URL is production or they don't, like, imply that, like, oh, this means it's real or whatever.

Aaron:

That they don't get the message that you're sending them. I mean Mhmm.

Dax:

You

Aaron:

know, I mean, people receive, like, thousands of messages every day, right, trying to convince them of something, you know, and and, like, you know, and they and they are looking at it with, like, 10% of their brain, you know, like, it's it's it's just really hard to, like, get a message through, you know. It's not really anyone's fault. You know? Like, it's it's just it's just the way the way the world is. You know?

Aaron:

Like, so so, like, you know, a big part of marketing I, like, realized there's, like, something actually you know, I mean, I grew up as, like, a skater in, like, you know, in in Southern California. So I grew up, like, very, like, anti marketing, you know, like, anti advertising. But I realized there's actually something kind of, like there's actually kind of a craft to it that is really interesting, you know, of, like, if you have a product that's good and you know that it's good and you know that it can help people, you know, marketing is just, like, finding a way to get them to know that, you know, like finding a way to message to them, you know, like and and there's a lot of interesting craft to that, you know? Yeah. So I mean, it's like if if they don't receive your message, like, it's not it it it's not like something has gone wrong.

Aaron:

That's like the expected case. You know?

Dax:

Yeah. Yeah. That was true. And to be fair, like, it's always a vocal minority. Like, that post had a crazy amount of likes on it, and then maybe, like, you know, one or two dozen people that replied in a way that I found annoying.

Dax:

But, like, it's always like it always ends up working that way. But the whole marketing thing is is super interesting too. Like, I I'm similar in that I just had this, you know, in hindsight, naive view of things of being like, well, if the product is good enough, the marketing doesn't matter. Then you go to do something real and your numbers are flat, and you're like, shit. There are all my deals.

Dax:

So it's totally tested by reality, and it turns out, like, I'm just wrong. So, again, my brain just slipped on that as well, and I was like, I just need to do this marketing thing because it's not this negative thing that's tricking people into something. It's, like, this totally other thing that, the reality is you just can't you just can't operate without. It's been funny getting into all that stuff.

Aaron:

But I think there is, like, a a sort of, like, a subtle twist on it, which is, like, if the product is good enough, then the marketing will work. That that's Yes.

Dax:

The marketing will work. Yep.

Aaron:

You know? And and and, you know, you have the opportunity to do at least I I I like you know, you have the opportunity to do, like, really interesting, like, creative marketing. You know? Yeah. Because you're, like, sort of riding on top of this, like, foundation of a good product.

Aaron:

Yeah. You know?

Dax:

Yeah. It's funny because people come to me, a lot being like, oh, can you give me, like, parking advice for this thing? And the thing that I always have trouble telling them is, like, I don't like your product. Like, I don't think it's good. So, like, I can't really come

Adam:

up with Dax, do you have a hard time telling somebody that their stuff is bad? That's hard for you?

Dax:

To your face directly when they're coming to me with such hope in their eyes? Like, yeah. You know? But just like, I if I don't like the product, I just can't the creative part of my brain isn't isn't activated. You know?

Dax:

It has to align properly. And that, yeah, it just won't work. You can copy paste what someone else did that worked. And if your product isn't getting, it's just not, yeah, it's not going to work. It's not it's not two things within a day.

Dax:

Product and marketing, it's it's all just one thing. Like, you pick the products that work well, that can be marketed well. So your marketing message can work well.

Aaron:

That's like that's like it reminds me of this, like, other this other sort of, like, phrase that I keep in my head. Like, is that, like, with with marketing, like, novelty is, like, is, like, half the battle. You know?

Dax:

Mhmm.

Aaron:

Like, you know, again, it's like you you have to, like, you have to get through to people. You know? So, like, you know, actually copying what somebody else has done is, like, the opposite of, like, what you should do for marketing, which is, like, which is, like, a little bit counterintuitive. Like, you you like, people get really good at noticing patterns. And what they're I think what they're really tuning into is, like, noticing low effort, you know.

Dax:

Yep. Yep.

Aaron:

Which goes to back to what we were what we were talking about. Right? Like, as humans, we're, like, we were, like, bombarded with messages all the time. Right? We're trying to filter them out and we develop patterns for, like, which messages are likely to be useful.

Aaron:

And, like, one of those heuristics is, like, the effort that went into sending the message. You know? Yeah. You know? And if and if and if the message is just like a copy of something that's been done over and over again, that's like that's like a really easy that detect pattern that is low effort.

Aaron:

Right?

Dax:

We can probably all if we just didn't think about it, we can actually probably all observe observe something ourselves because I've been around long enough where I've seen things that the first time I looked at it, it looked incredible. And then very quickly, I started looking at it and literally looked ugly to me. So more recent example is AI generated images. There was a time where we were like, wow, this is insane. And now it's been, like, maybe, like, a year of us seeing it.

Dax:

We, like, can instantly tell it's AI generated and our brains just think it's ugly. But there's, like, no objective truth to, like, what looks good or what doesn't. It's just like whether you've seen it enough times already, which is, like, kinda mind blowing.

Aaron:

Say, like, monitoring websites. You know? Mhmm. Like

Dax:

Yeah. Well, my first thought was actually the linear website where I'm like when I first saw that, I was like, wow. It's good. And now when I see one of those things, it's like a insane negative reaction I get. Yeah.

Dax:

And sometimes it's not even low effort. It's there was a recent case where I think they even posted. They spent, like, a hundred thousand dollars on his landing page and, like, looks so like that, like, crazy, like, nightclub, flashy, glossy, reflective thing going on everywhere, but just looked like a variation of linear, and it looked bad to my eyes. So Yeah.

Aaron:

You know, it can be it can cost money and still be low effort. You know?

Dax:

Like That's true. They just hired someone to copy the thing. Yeah.

Adam:

I've just been listening to you guys, and I I just want, like, the people who can nerd out about this stuff to, like, enjoy the content. But I have so many, like, super dumb questions, and it might be helpful for the people

Dax:

like me. Yeah. Yeah. Let's go.

Adam:

So I am a front end engineer who did not go further in life and didn't I didn't live up to my potential. I don't know what a Beatrix is. So I can start there. What is a Beatrix? But that's probably not very interesting.

Adam:

I wanna know, like, zero, what part of because I'm not I'm I'm not using it. DAX is still plugged into this stuff. What part of my stack? Like, it's a library I I install into my front end application. Yep.

Adam:

And it replaces my API. It replaces my database? What how does it all fit?

Aaron:

Yeah. Yeah. It's it Xero and and in more general, all sync engines, they they take over the network communication, between the client and the server. You know? So like 100% of people who are listening to this are building a client server web app.

Aaron:

Right?

Dax:

You

Aaron:

got code on the client, which is, you know, it's not that bad.

Dax:

You know?

Aaron:

You got code on the server. Right? And the data is on the server and the UI is on the client. And you need some way for them to talk to each other. And the sort of classic way to do this all the way back to the nineties is, like, the three tier architecture, right, with, like, APIs, HTTP APIs that connect them.

Aaron:

Right? And we've gone through a few variations of HTTP APIs. There was, like I don't know. If you're really old like me, you've got, like, soap.

Dax:

Soap. Yeah. Oh, yeah. Wow. I like soap.

Dax:

I liked it. Because it integrated nicely into Visual Studio, and you could just, like, click it and see everything.

Adam:

Never heard anyone say they like Soap. Sorry.

Aaron:

I've never heard that either. I'm reevaluating, like, as we speak. Things are like, They're like, oh.

Adam:

He acts like soap, and he likes zero. That's a bad sign.

Aaron:

Soap. Yeah. So then, you know, we had a shoot, what was the one? There was a short lived one, after that. And then and then, you know, we had REST, which which lasted a really long time and still going strong.

Aaron:

And we also had, like, GraphQL, right, which was another variation on this idea.

Dax:

Don't know.

Aaron:

I guess you could say, like, tRPC is another version. Right? There's a there's a lot of smaller ones. Right? But they're all sort of, like, based on this idea at the bottom of, like, HTTP APIs.

Aaron:

You know? So the the client makes a at the end of the day, it makes a fetch request and send some data to the server and get the response. Right?

Dax:

Mhmm.

Aaron:

And sort of the fundamental problem is, like, you know, if you want the UI to do something, the user presses something. And in order to do that, it needs data from the server. It has to wait for that request to go to the server and send the data back. And, like, sort of at a minimum, you're bounded by speed of light, which is kinda cool. We're, like, you know, we're building things where we we care about speed of light.

Aaron:

You know? But, like, you know, for a lot of practical reasons, databases usually have to be centralized. There's a lot of people that are have been hopeful about, like, distributing databases, but there's really hard technical problems to distributing databases. And there's also really hard, like, political problems to distributing databases.

Dax:

Right.

Aaron:

And so for a lot of reasons, databases just end up often being centralized. Usually. Yep. Usually, they're centralized. So that just means, like, by definition, there's gonna be people the majority of people on Earth are gonna be far from your database, and the speed of their UI is going to be limited by the speed of light.

Aaron:

But that's just the beginning. Like, if really if really we were limited by speed of light, like, that'd be great, You know? Like like like the the the the distance like, I think the maximum distance from, like, any two points, like, on Earth round trip is, I don't know, maybe a 300 or four hundred milliseconds, something like that. You know? It's not great.

Aaron:

It's not great. It's not instant, but, you know, that would be fantastic if our UIs were maximally four hundred milliseconds late. But that is not what we experience. What we experience is UIs that are two seconds late. And, like, why is that?

Aaron:

It's because, like, the database the the application server, when it finally receives this request, is doing a bunch of work, and that work takes time. It's because often the UI is doing many requests to get data. Right? It's not doing one. You know, it's like you click on something in the UI and then like 10 requests happen.

Aaron:

You know, one after the next. And so like in order to make this better, in order to make these UI better, like, we like, it's kind of funny, but we have to get the data to the client before the user needs it. You know? And that's that's what sync is about. That's what sync engines are about is they're about continually pushing data from the server to the client ahead of time.

Aaron:

So that the data is there on the client when the client needs it. And they can just read it locally from SSD, which is instant. And so this is all a very long way of answering your question, which is it takes over GraphQL and REST. And so we have a library in your client that you talk to directly that provides an interface that looks like a database. You've got queries.

Aaron:

You can do full arbitrary queries with, like, joins and sub selects and filters and soon, someday, aggregations and everything.

Dax:

Woah.

Aaron:

But that database is like an illusion. There is data locally, but, like, it's continually being updated, by the server, who's pushing data to the client so that it's there when you need it.

Adam:

And so you have, like, a package that you also run and install on your server,

Dax:

Yes.

Adam:

Presumably to run, like, a Xero server or not?

Dax:

What I what I'm super into about Xero is to me, it almost feels like something in the same level as Redis where, like, everyone knows that they have a database and an application server front end. And, like, maybe they add in Redis to, like, provide caching in front of the database when, you know, there there's too much load. This is kinda like so zero is a standalone server. That's kinda like Redis in that it's like a cache for your database, but it's entirely optimized for the client to be front ends. So you can deploy these servers around your database.

Dax:

And what I'm really excited by is even in other regions. Right? So you can have your main database in US East 1, and you can have a zero replica in US East 2 just serving the users there. It's it's like taking over the responsibility of a read replica, but it's a read replica optimized for the sync engine engine purpose. So I can see how this just becomes a default thing that everyone just deploys around their database.

Dax:

Mhmm.

Aaron:

Yeah. So you you you have the client. You have this server that we call zero cache, that is basically a read replica, like a very fancy read replica.

Adam:

Of your database.

Aaron:

Of your database. Yeah. Like a read replica, it replicates your data into its own storage. But unlike a read replica, like Redis is a cache. There's, like, a difference between a cache and a replica.

Aaron:

The the words are used interchangeably, but they're not the same thing. Like Yeah. You know, like a replica has, like, a correct snapshot of the database, you know, at any point in time.

Dax:

Mhmm.

Aaron:

The cache just has some random subset of it that's been request. Right? So it's a, zero cache is a replica. It sits in front of your database, but it also

Adam:

Sorry. Any kind of database, or, like, you guys support certain databases?

Aaron:

Currently only Postgres, but the way that zero cache has been has been designed, it can work with other databases.

Dax:

Mhmm.

Aaron:

And, like, in fact, we have, like, an experimental version of Mongo up and running. Right?

Dax:

It it just requires any database with a change stream so it can consume updates in real time and say up to date. Yeah.

Aaron:

Which, like, most databases have something like this for read replicas, you know, because they they need. Right? You have a zero cache, and the zero cache also replicates data to the client. So you so Mhmm. You've got your primary database.

Aaron:

You've got zero cache, which is a replica in the server. And then and that and then you have a subset of that data that gets pushed to the client and actually replicated to the Client so that you have a consistent snapshot on the Client. And then you read against that partial subset that you have on the Client. You render instantly. And since you're continuously replicating to the Client, whenever any data changes on the server for any reason, it gets pushed to the client, and the client reactively updates.

Adam:

It sounds nice.

Aaron:

You get real time out of it for free, and you get instant speed UI. And then as a little flourish on top, we also allow mutability to the local data. So you can change the we have an API where you can change the local data.

Dax:

Mhmm.

Aaron:

And those changes get pushed to the server, and they use Replicache's conflict resolution that we talked about earlier Mhmm. To resolve conflicts. The end result is, like, you can you have an API that looks like a database on the client, and you can do arbitrary queries to it. And those queries are usually instantaneous. We'll get back to the usually maybe in a second.

Aaron:

But, like, the vast majority of the time, those queries are instantaneous. The queries update reactively, when data on the change of service, and you can change the data locally. All the queries that are open on the client, they update automatically when you instantly, when you

Adam:

Mhmm. Create the change. Kinda like that's like a React query kinda feeling kinda experience. Does that make sense? Like, if you it's like invalidating the the local data whenever you change it.

Dax:

Yeah. Yeah. Exactly. It it yeah. It achieves the same thing except, you get to just give it normal queries.

Dax:

You're like Yeah.

Adam:

You're just interacting with the database.

Dax:

Select from users where time created is within the last week, and that's just a view. And any changes that gets updated, any mutations that would would have affected that query, it updated optimistically. Yep. It makes your front end so stupid. Like

Adam:

Yeah. Sounds amazing.

Dax:

The front end side of it is just, like, is it's so dumb. It's like you barely need a framework at this point.

Aaron:

Also, you don't you don't need to use optimistic. Like, you don't need an you don't need to write, like, an optimistic version.

Adam:

Everything is optimistic. But I mean, it's just the nature of

Dax:

because it understands the exact thing that's being mutated.

Adam:

Yeah. Yeah. Does that answer your question about, like No. It does. It sounds no.

Adam:

It sounds very nice. So that that zero cache, the server part, you can put those anywhere, and they're sort of, like, mitigating the issue of the distance between your users and your database because they're constantly being updated from the database.

Dax:

So e e even if you don't do that, it's probably fine. Like, right now, we just have those zero

Adam:

cache. Really matter because you send the data to the client ahead of time. Yeah.

Dax:

But if you really wanna push things

Aaron:

and you wanna say, like, you know, I want

Dax:

it to be even faster across the world, like, yeah, you can have zero cache deployed. So it's the same logic you would put a read replica in another region. I think for me now, I'm just like, yeah. My issue with read replicas is, like, they're still very annoying to deal with. Like, you can do a re replica of Postgres, but then, like, now you need an API server there.

Dax:

But then, like, rights still have to go to, like, the primary date. Like, all that stuff is just a a lot. Whereas with this Yeah.

Aaron:

I realize that's not the that's not the

Adam:

thing I really care about. I mean, I'm I'm, like, getting into stuff. Like, what I do care about, I guess, questions I would have is, like well, the the first one would be if you have a lot of data. And, yeah, I think you said you can partially send down data so you can choose for, like, given pages, I guess, or routes. You can choose to, like, only send certain data down.

Adam:

Is that the idea?

Aaron:

Oh, this is the part that I,

Adam:

like, I love the most. I'm so Yeah.

Aaron:

I mean, so it's query based. You know? At the end of the day, you you have a query API on the client. You do you do a query. And and so, the the data that backs that query is what gets synced to the client.

Aaron:

Like, we take that we take that query and we send it to the server, and the data that's needed to answer that query is the data that gets synced to the client. And then you do another query, and that data gets synced to the client. And that's just how it works. Like, all the queries that you have opened are the data that's getting synced. So you control what data gets synced by what queries you make.

Aaron:

You know? You're you're in complete control, and you have the full power of a query language to to do that. You know? When you

Adam:

say when you say query language, is it SQL?

Dax:

It looks SQL esque. Yeah.

Adam:

It looks yeah.

Dax:

Yeah. Yeah. And it's on the front end. This is all the front end that you're writing these.

Aaron:

It's inspired the design was inspired by Kiesly, if you're familiar with that.

Adam:

Oh, yeah.

Dax:

Sure. The thing that's really cool is the way this actually maps down all, like, component based frameworks because, like, a component based framework is you just have, like, nested things. Right? Like, when you land on a page, the outermost component loads. So any queries you put there will get loaded right away.

Dax:

But then when you click into stuff, like, the inside changes. Right? So let's say you land on the page and you have, like, a header with, like, the user info. So, of course, the user info is gonna be synced right away. But then if you navigate to a deeper component, there might be queries in that component.

Dax:

Right? Mhmm. That won't sync right away, but once you've navigated in there, then it'll start syncing. Mhmm. So it, like, very elegantly maps back to, you don't sync stuff until the user has shown interest in it.

Dax:

Yeah. Because unless they clicked in there, like, that query would not have loaded and would would not have started being tracked. And the reason we switched so we didn't plan on switching the SC console over to zero, because we have it working on replicash. It's fine. But then we had a situation, a feature where we wanted to show you the diffs of every single SC deploy that's ever happened.

Dax:

Syncing all of that ahead of time is, way too much data, but it fits naturally with, let's just wait till you go into a specific deploy to look at it to then sync it. And that's kind of what forced our transition to moving to Xero because implementing all that on top of replicas manually, it would've been a subbar equivalent to what Xero can can already do. So now we're, like, really excited to move everything over because now that part of our app is, like, really nice, and the rest of it now looks forced by comparison. But,

Adam:

Well, I I'm gonna dig in. My my main job like, my primary day job, we use Postgres, so I could actually start poking around.

Dax:

Yeah. I mean, it's kinda interesting for you because I don't I don't, like, immediately know if there's a good use case. Yeah.

Adam:

So the time use use case is, like, very, like, antithetical to local first, I feel like. But then I think about, like, you just it's when you talk about it that actually you should do both things. Like, I feel like you should probably still use it for any of the interactivity stuff. There's just, like, our experience is slow, and it could be fast. So it's kind of like you gotta figure out how to do both things.

Adam:

We have to serve a million clicks from Google every day, but we also need to figure out how to make the people who stick around and use our app a lot make it fast. Like, we kinda just have to do both, I feel like.

Dax:

Yeah. There's no there's no downside. There's no downside with having a page that's entirely public powered by zero. Like, this it it it'll still work. That's what's nice about this model.

Dax:

Well,

Aaron:

there could be there could be, like, cost downsides for, like, for, like I don't know. I I don't know what you what your day job is, Adam, actually. But, like, you know, the the server is, like, more expensive to run than, like, you know, I don't

Adam:

know. Like, the Like a normal web server.

Dax:

Yeah. If you go look at if you go look at his Aurora bill, you're gonna be like, never mind. Because what whatever they're paying for Aurora is

Adam:

Yeah. I'm not too worried about the compute, I guess.

Dax:

So Adam's the founder of Statmuse, which if you're not familiar with, it's, like, the sports statistics source for, like, all sports or not all sports, but, like, most of the sports. And they get, like, a crazy amount of traffic. And it's mostly public mostly public traffic, but they also have, like, power users that are Yeah.

Adam:

Mostly, like, search engine yeah.

Dax:

That are, like, logged in and doing more intense stuff.

Aaron:

I mean, I'd like to, like, dig into it. I mean, the the sort of, like been trying to think about how to talk about this. I I actually need to do a blog post about this or something like that. Yeah, we launched Xero Alpha right at the right before Christmas. So now it's been just about two months that it's been public, and so we've got a lot a lot of interesting feedback.

Aaron:

People are already starting to use it in production. Thanks, Dax. And and I think, like, you know, we're we we decided, you know, as we talked about a little bit ago, to take on this really hard problem. You know, like, some of the stuff we're doing is, like, you know, like, kind of, like, leading edge, like, software engineering. You know?

Aaron:

Yeah. And Beatrice. Behind. And and, you know, we're it's like we didn't talk about this at all, but, like, what makes zero possible is this new query engine that we wrote. We wrote our own query engine from scratch.

Aaron:

Like, like so it's it the API is Keisley, like, inspired, but it doesn't bottom out at SQL. Like, we have our own query engine that runs

Dax:

this stuff.

Aaron:

And we had to do that in order to make this work, in order to make this efficient. This is why we didn't do this way back with Replicash. And this is all built on this, like, theory of databases called IBM incremental view maintenance, which is, like, pretty bleeding edge stuff. So this is all to say, like, we're going after, like, this really big problem here. You know?

Aaron:

I think I think what Bun is doing is is, is really inspiring too. I would kind of put us in that in that category of people who are who are tackling a really hard problem, and it's gonna be a lot of work. And, like, initially, like, today, you know, like, zero is a good choice if you are willing to run your own servers, if you're willing to run Dockerized servers and AWS, and you have enough skill and energy and need to deal with all the configuration crap of running AWS or if you want to use SST. And it's fairly expensive to run. I have to put together estimates of what the minimal deployment looks like.

Aaron:

And there's sharp edges, both in API, in bugs, in costs, all kinds of stuff. That's the reality. But the value, I think, it's already valuable for a surprising amount of applications. It's already a really useful tool for all kinds of products. We have we probably got a dozen people running in production now.

Aaron:

And we get feedback all the time about how amazing the experience is and people who are excited about the vision. So I have to find a way to talk about right now so people can, like, understand, like, whether it's the right time for them to jump in or not. You know?

Dax:

Yeah. Sure. Yeah. I mean, I think just seeing how much work it is is also kind of interesting. That kinda communicates a value.

Dax:

Like, I mean, even just stuff that I'm aware of, which is just relate to it's like a subset of all your problems, because the ones that I've run into. But, yeah, like, eventually, like, you know, this cache needs to be sharded. Yeah. The the the sharding plus, like, you know, this idea of can each zero cache only replicate as upsell the data? What does it look like when there's, like, terabytes of data in your database?

Dax:

I'm also very surprised. I think I just I'm I'm not gonna infinitely be surprised by this, but like you said, like, right now, it's the bar of being able to actually use it is definitely higher than where it will be. I'm shocked how many people still do it anyway. Like, I'm surprised by how many people I see in there, like, figuring out all this container stuff and, like, you know, actually feel like this is worth my time to, you know, figure all this stuff out given how bleeding edge it is. Like, I I'm, like, working on deployment stuff.

Dax:

So I'd, like, spend all my time with this stuff. And even then, I'm, like, running into stuff I don't know. But, yeah, it's, like, it's, like, incredible, and people already wanna do that.

Aaron:

You know, I have this problem as, like, the the creator of the thing. Right? Whenever anybody hits, like, a problem, I'm, like, deeply embarrassed. You know? Like, oh my god.

Aaron:

I can't believe, you know, this is we have this public this way. You know? Like, like and and but then I come back to, like, we built, like, a bug tracker. You know? Like, we built we built a linear with this thing.

Dax:

That's true. Yeah. We

Aaron:

have, like, all every last feature that linear has, but it is a good it is a good, you know, partial subset of the features of linear. And in particular, like, the core feature of linear, its performance. You know?

Dax:

Yeah.

Aaron:

And and not only that, it has some features that linear doesn't have. It has public bugs. It has fine grain permissions. It loads fast, you know, when you enter a detail page. And, yeah, you know, z bugs z bugs has, like, a thousand bugs and, like, a total of, like, maybe 15,000 comments.

Aaron:

You know? So it's not like the world's most massive, like, bug tracker. You know? But that is the shape the rough shape of a lot of real applications. You know?

Aaron:

Like Mhmm. And and so I think, you know, what you're seeing, the reason why there's a lot of people in there fighting to figure this stuff out and and and in early is because when you step back and you think about that, like, wow, you know, like, you can build, like, you know, a subset of linear with, like, a few people in a in, like, few months with this technology, you know, that's, like, a pretty, you know, like, that's a really hard thing to build otherwise, a really hard thing. And Yeah. So, you so a lot of people want to build something like that. That describes a wide variety of SaaS applications.

Aaron:

If you look at that and you say, wow, this is already able to do this and these guys worked on Replicash before and they're in it for the long term and this is going to keep getting better and better. You know, like for a lot of for a lot of companies that are starting something new that is roughly like a SaaS shaped thing that needs to be fast, you know, it it looks like a good time to get in.

Dax:

I generally don't have much motivation to convince people to use a certain technology because, yeah, it just what does it matter to me? But the thing with this category is I just want, as a user, to have better software that I can use. So I'm like obsessed with getting more people into this because they're going to build stuff that I can use and really enjoy. It's like once you've used enough of these things, you just start hating like the thing you were saying about GitHub issues, like it feels 10 times more painful when you're aware of what it can be like. So I'm really looking forward to even just this cohort of applications, like, graduating and becoming real products.

Dax:

And, like, the more that get added on over the next couple of years, I just feel like there's gonna be this generation of products that just feel finally so good on the web. Like, we've been chasing the native feeling for so long, and it feels like I I can see that happening within Vue.

Aaron:

Yeah. Yeah. I mean, when when one of my cofounders at at, Addict and, Rossi Corp is this guy, Eric Arvidsson. He's not has hasn't had a presence on Twitter, but we've been working together ever since I was in college. Like, and and he worked with I I recruited him to Google.

Aaron:

He's one of my old oldest friends and collaborators. And when we started doing JavaScript way back in the day doing those UI widgets, you know, what we were doing was, like, drop down menus, window scroll bars, stuff like this. We were making UI registry because we wanted to make the web work like real native apps, be as good as real native apps. And I think there was something way back there really interesting and deep that we didn't totally recognize, which is that web software is client server software. And those native apps that have that feel that you love, that when people why can't web apps be like Winamp?

Aaron:

That was like a we were always saying Winamp is amazing. And part of that is all all the stuff about JavaScript. We can solve all that. But part of it is that the web Winamp is Spotify. It's client server software.

Aaron:

It's not local software.

Dax:

Right.

Aaron:

You know? The data is is is remote. And so part people people always bitch about how bad web software is and part of it is is legit, you know. And part of it is solvable, but a big part of it is like networking, you know. Yeah.

Dax:

It's the architecture of it. Yeah.

Aaron:

Yeah. Yeah. And and a big part of the value of web software, the reason we're using it is because it's client server, You know? And so solving that, making that part as good as native software is really deep and and fun problem and, like, you know, something that I feel like I I didn't really, like, I didn't really go after, like, fully, you know

Dax:

Mhmm.

Aaron:

Before. But, like, we're we're doing with Xero, and, and I'm, like, I'm I'm I'm, like, stoked to finally be be going for it. And I think like a lot of other people, it's funny, like, when you really go for something, like, when we announce Xero, like, the amount of just, like, encouragement from the community was, like, it was just completely inspiring. And, like, the deep like, it felt so good. Like, people who are competitors were, like, wow.

Aaron:

You know, this is epic. Like, you know, like, I'm I'm, like, so glad that you guys are going for this. And we've got a lot of people involved just just, like, for that reason.

Dax:

Yeah. Yeah. Yeah. It's it's, it's super exciting. And like I said, for me, it's been just I don't know.

Dax:

I think I started down this path in 2020, I think. It's been five years. So it's been it's been a very long time. And just to see even just the transition from me talking about this and then it just me talking to no one is, like, kind of going out the wind and nobody even, like, knew what I was talking about. Everyone was kind of focused somewhere else.

Dax:

To now, like, everyone gets it, and it was kind of on everyone's radar. And, yeah, it's cool to be able to actually, like, witness that transition because I never felt like I had been early to anything. I always felt like I arrived just a little too late. But then with this, it feels like, okay. I, like, actually was able to see something and and follow it through.

Dax:

Yeah. Yeah. It's always fun. Anything else you wanted to chat about?

Aaron:

No. I mean, you know, thanks for having me on. I really appreciate like you pushing us. Like, I've I've said this before, but actually like you are a big reason we did zero. Like pushing on Replicash and like really getting us to think about like solving this problem for real.

Aaron:

But yeah, this has been super fun. Thanks for having me on.

Dax:

Yeah. Always a good time. Thanks, Aaron. Alright.

Creators and Guests

Adam Elmore
Host
Adam Elmore
AWS DevTools Hero and co-founder @statmuse. Husband. Father. Brother. Sister?? Pet?!?
X Website Link
Dax Raad
Host
Dax Raad
building @SST_dev and @withbumi
X Website Link
Aaron Boodman
Guest
Aaron Boodman
CEO Rocicorp. Building Zero and Replicache.
X Website Link
Chris Enns
Editor
Chris Enns
I edit podcasts so you don't have to.
X LinkedIn Mastodon Threads Instagram Bluesky YouTube Website Link
Aaron Boodman on Building Zero, Local-First, and Living in Hawaii

headphones Listen Anywhere

More Options »
Broadcast by