[Tech] Separation of (Local-first) Client vs Server - Jori Lallo

Listen to devtools.fm: https://www.listennotes.com/podcasts/devtoolsfm/jori-lallo-linear-KS_Gn2v3hqV/

Transcript:

So one of the big differences between linear and other product products is that it has a local first approach where, uh, it does a lot of things locally in the app before, like communicating with the backend. Uh, why was this such an important baseline feature for you guys to get in? And how, how did you do it? If you can, uh, comment on that. So yeah, optimistic updates. I don't like, that's that, that's the story. first and offline readiness, or someone, they're almost like, like local first, like for sure. But like offline readiness for example is like a byproduct of like how, just how we build linear and we're able to like plug that in afterwards. So the goal is like build something that's really, really snappy and if you see a spinner or like a loader after your every interaction, um, you know, like, it's like if that's your foundation, like it's extremely hard to like change. So we select, build out the foundation from the get go to, uh, do, do updates locally first and then like likes us, communicate them, uh, distribute them like behind the scenes Um, of course some might fail, but like most of them, uh, they don't, uh, often the question is like, okay, like how do you do conflict resolution? Well, the short answer, like simple answer, like, we kind of like don't have to that often. Uh, so In a tool like Linear, most changes are addition on something that's like already happened. We're we're not a, we're not a Notion or Google Docs. You don't edit the same text block. Uh, of course you can edit like the same, uh, issue description at the same time. But reality is that that rarely, rarely ever happens. So hopefully we can like, solve that at some point. But right now the last update, like last update wins. Uh, so how it like technically happens is a little bit like similar to, for example, like how Dropbox builds their desktop, uh, application. Is that when you first, uh, log into linear, you get a larger dump, what we call a bootstrap, um, of kinda like all of your issues and like, like teams and users and that information. Uh, we load that first in memory, then persist in an index db in the background. Um, if you use the product that's the caching, uh, indicator that like pops up one after you're logged in. And after that, uh, we just do delta, delta syncs or like delta packages distributed through web sockets and those get up, uh, applied on the local, uh, copy of the store that you use. Uh, so we, we maintain a copy of the. Connect the whole, like the database, uh, in memory and then persisted in index db. We first update everything into that, uh, show everything in the client, then send those over. If you get something like those, like Delta packages over the wire, they select it applied like the UI react to those. Um, we use a little bit like, like it's a React application, react with type script. We use mobx under the hood, uh, to do all the updating. But, and like the developer experience for this is, uh, It is, uh, it is, it is different from a lot of like applications where you have to, like, we do all the heavy lifting for you. We do like the mutations and queries and uh, like we don't do queries, but like we do mutations. So whenever you like mutate something, we auto generate mutational mutations out of those and send those to the server. The server, uh, which then again, then creates the Delta packages for other clients. But all of that, uh, is abstracted from US engineers at Linear. So we basically only interact with the, with the store. That's the application state and you reach from it, UI updates, you change things to it. Uh, mutations are created in your background. So while it was like it's an engineering geat, uh, Tomas actually has a YouTube video about it. Uh, I can share it after the fact, but, um, It allows us to move faster while putting this upfront investment in place. Uh, it's, it's not like easy system . That's why we have and couple of other engineers working on it, uh, nowadays more, more or less full-time. Full-time as well. Like scaling this, uh, is, um, you know, like we knew like at first, like our customers were relatively small. They don't have that much data, so we can just read every, all of their information into the client. As we grow, like we know that, like, that's not gonna work out anymore. So then we started like chipping off on doing other more unique things, uh, on top of it to help it scale. Um, so that's a, it's an ongoing, ongoing thing as well. But it's kind like at first, you know, we served like the small startups, now we serve companies like cross stage companies of, you know, Brazil, retool like several hundred, uh, engineers. And then Cash App is also using us and they're, I don't remember like how big they are, but it's a sizeable, sizeable engineering organization. So we've been able to like, Scale, linear asset product? Uh, both like on from the product perspective, but also from the, kinda like the technical foundation perspective. And that's, that's in the end, like our goal, like we want linear to be the, the one tool that you use. Like if you're a small startup, like pick up using it, like don't think about it and it should, uh, get you throughout your, your like, scale IPO and beyond . So Really, I really love this. So it's like this really. Complex technical architecture that's required, but the, the thing that you're going for, the thing that you're pushing for is optimistic updates. You know, I want to do an action and feel like it instantly completed. And it's like, it's a difference between a performance first company and a company who thinks about performance after the fact. Because architecting a system or introducing that type of architecture, post shipping a product is a non-trivial endeavor. And, and it would've taken y'all a long time to get to that point. So it's like, uh, I don't know. That's, that's really cool to, to hear about. And yeah, it's, it's hard. Luckily nowadays there are starting to be some technical solutions for this. For example, repliCash, and I'm sure you you know, like bunch of like and, yeah, bunch of others. When we started four years ago, there's nothing Couch db, which, and Coach DB and Fire Base, but they only really, they didn't work for a, uh, kinda like multi-tenant team tool. It, they work really well. If you're like one user who switches between like different applications and your, your state follows you, your settings follow you. But for, for a tool like linear, like nothing existed, so we kinda like have to. Do the investment. And Tomas really went, went to town with it and I'm, I'm glad he did. Uh, I, I don't personally like have the engineering like capabilities like pull that off, but I'm really fortunate to be working with him and yeah, it's now, it's like one of the, like the defining things of, of linear. It's like the speed and the snappiness. We basically don't have, like, there's a couple of, there's a couple of spinner and like loading states in the application, but, uh, you, you, you can use the product and like try to find them yourself. I won't tell where they are.