1 00:00:00,000 --> 00:00:05,950 My perspective on localf-first is that, I think ideally every developer would 2 00:00:06,040 --> 00:00:10,760 love to be able to interact with their APIs as if they were localf-first. 3 00:00:11,336 --> 00:00:15,440 and then I say that not necessarily meaning like offline, but just , I 4 00:00:15,440 --> 00:00:17,930 synchronously did this thing and I can trust that it's going to 5 00:00:17,930 --> 00:00:21,620 be persisted where it needs to be persisted and then move on. 6 00:00:22,056 --> 00:00:24,066 and just kind of feel like everything gets instantaneous. 7 00:00:24,066 --> 00:00:28,600 So, I have no doubts that that is what everybody wants. 8 00:00:28,790 --> 00:00:30,230 It can be difficult to get there. 9 00:00:30,686 --> 00:00:34,106 and if you try and get there too quickly, I know you can get into some 10 00:00:34,106 --> 00:00:38,266 trouble and there's really smart people who are slowly trying to carve out 11 00:00:38,266 --> 00:00:40,336 this space and make that a reality. 12 00:00:40,567 --> 00:00:42,727 Welcome to the localfirst.fm podcast. 13 00:00:42,937 --> 00:00:46,837 I'm your host, Johannes Shickling, and I'm a web developer, a startup founder, and 14 00:00:46,837 --> 00:00:48,697 love the craft of software engineering. 15 00:00:49,297 --> 00:00:52,837 For the past few years, I've been on a journey to build a modern, high quality 16 00:00:52,837 --> 00:00:56,917 music app using web technologies, and in doing so, I've been falling down the 17 00:00:56,917 --> 00:00:58,777 rabbit hole of local first software. 18 00:00:59,347 --> 00:01:02,317 This podcast is your invitation to join me on that journey. 19 00:01:03,172 --> 00:01:07,112 In this episode, I'm speaking to Tanner Linsley, creator of the TanStack 20 00:01:07,132 --> 00:01:11,482 Ecosystem, including projects such as React Query and TanStack Router. 21 00:01:11,872 --> 00:01:16,342 In this episode, we talk about the newest Project TanStack DB and explore 22 00:01:16,342 --> 00:01:20,422 the problems it's trying to solve and how it works before getting started. 23 00:01:20,572 --> 00:01:24,442 Also, a big thank you to Jazz for supporting this podcast, and 24 00:01:24,442 --> 00:01:26,092 now my interview with Tanner. 25 00:01:26,547 --> 00:01:29,157 Hey Tanner, it is so awesome to have you on the podcast. 26 00:01:29,157 --> 00:01:29,817 How are you doing? 27 00:01:30,327 --> 00:01:31,107 I'm doing great. 28 00:01:31,227 --> 00:01:32,007 Thanks for having me. 29 00:01:32,757 --> 00:01:34,287 I'm very excited to have you. 30 00:01:34,605 --> 00:01:38,655 so most of the audience I'm certain are familiar with your work, are 31 00:01:38,655 --> 00:01:42,465 probably using a lot of your tools, but would you mind introducing yourself? 32 00:01:43,065 --> 00:01:43,515 Sure. 33 00:01:44,038 --> 00:01:49,228 my name's Tanner Linsley and I've been building open source software 34 00:01:49,228 --> 00:01:51,548 for, I don't know, almost 10 years. 35 00:01:52,011 --> 00:01:56,621 been involved in some startups, one of them for about a decade where 36 00:01:56,621 --> 00:02:02,478 we were building a, a SaaS product for SEO Marketing Analytics, which 37 00:02:02,478 --> 00:02:04,458 was pretty intense, a lot of fun. 38 00:02:05,388 --> 00:02:10,778 And, yeah, now I mostly work full-time on TanStack, which is kind of the 39 00:02:10,778 --> 00:02:16,481 umbrella of all the tools that that I've built or have helped build in 40 00:02:16,481 --> 00:02:18,625 the last, eight to 10 years, so. 41 00:02:19,280 --> 00:02:20,780 That's, that's what I do. 42 00:02:21,470 --> 00:02:22,370 That is awesome. 43 00:02:22,430 --> 00:02:26,420 I think it's safe to say that everyone who's listening has at the very least 44 00:02:26,420 --> 00:02:30,590 used a product that is using one of your tools, but I'm also pretty certain that 45 00:02:30,590 --> 00:02:36,370 almost everyone is also directly using one of your tools and libraries in some 46 00:02:36,370 --> 00:02:38,905 package days, dependencies, me included. 47 00:02:39,235 --> 00:02:44,095 I'm a huge fan of your work and you and I actually had the chance to catch 48 00:02:44,095 --> 00:02:49,465 up in person again at last year's next JSConf in, very sunny San Francisco. 49 00:02:49,855 --> 00:02:53,515 And this is where I got the chance to show you what I've been working on 50 00:02:53,515 --> 00:02:58,065 over the last few years with Live Store and generally chat about localf-first. 51 00:02:58,435 --> 00:03:01,645 And I think this was probably not your first touch point 52 00:03:01,885 --> 00:03:03,688 with, localf-first as such. 53 00:03:03,688 --> 00:03:05,548 I think that goes way back further. 54 00:03:05,788 --> 00:03:11,078 But maybe you can share a little bit of like your relationship to localf-first. 55 00:03:11,098 --> 00:03:17,278 As I understand it, you are not yet fully in the center, you're aware 56 00:03:17,278 --> 00:03:20,998 of it, but you also are developing your own perspective on it. 57 00:03:20,998 --> 00:03:22,108 So maybe you wanna share that. 58 00:03:22,438 --> 00:03:26,788 When we met at Nex Conf and what you showed me was impressive. 59 00:03:26,818 --> 00:03:27,568 It was crazy. 60 00:03:28,178 --> 00:03:30,848 and the stuff you had been showing me before and after 61 00:03:30,848 --> 00:03:32,078 that is just mind boggling. 62 00:03:32,108 --> 00:03:36,911 I think the furthest back I can go for like a localf-first, or at least what's 63 00:03:36,911 --> 00:03:42,191 aspiring to be localf-first experience was like back with Meteor and PouchDB. 64 00:03:42,633 --> 00:03:46,205 I remember playing with those extensively just thinking like, wow, this is so cool. 65 00:03:46,235 --> 00:03:50,885 'cause, and back then it was like, there was a, a big push to have 66 00:03:50,885 --> 00:03:54,721 everything be offline, you know, first, and then, sync when it can. 67 00:03:55,134 --> 00:04:01,331 obviously, the syntax and the tools, the tooling and everything around local-first 68 00:04:01,351 --> 00:04:03,481 like evolved drastically since then. 69 00:04:03,940 --> 00:04:05,091 it doesn't even look the same. 70 00:04:05,485 --> 00:04:10,125 but that was kind of my first experience with the feeling of localf-first 71 00:04:10,145 --> 00:04:13,868 that you get where you kind of just, you can interact with your data. 72 00:04:14,135 --> 00:04:17,555 Pretty much as if it's synchronous and then just kind of forget about it. 73 00:04:18,155 --> 00:04:22,625 And that, I think PouchDB was probably the first one that I felt that with and 74 00:04:22,625 --> 00:04:24,515 I was like, wow, this is really magical. 75 00:04:25,001 --> 00:04:29,231 you know, it's definitely far from perfect and there's a reason that, you know, not 76 00:04:29,231 --> 00:04:35,685 everybody's using PouchDB anymore, or even were using PouchDB, yeah, I think, in 77 00:04:35,685 --> 00:04:41,135 the more modern, tool chains, everything you've been working on has been kind 78 00:04:41,135 --> 00:04:46,283 of the most eye-opening along with some of the other stuff from like, Convex. 79 00:04:46,403 --> 00:04:48,953 Convex is a TanStack partner, and they. 80 00:04:49,743 --> 00:04:55,161 Kind of like that server-first, localf-first experience as well, 81 00:04:55,548 --> 00:05:00,021 and they have really direct ties with TanStack Query, which is why 82 00:05:00,021 --> 00:05:02,031 I've experienced a lot of that. 83 00:05:02,301 --> 00:05:09,241 so yeah, my perspective on localf-first is that, I think ideally every developer 84 00:05:09,241 --> 00:05:14,321 would love to be able to interact with their APIs as if they were localf-first. 85 00:05:14,898 --> 00:05:18,958 and then I say that not necessarily meaning like offline, but just in a 86 00:05:18,958 --> 00:05:22,785 very synchronous, I synchronously did this thing and I can trust that it's 87 00:05:22,785 --> 00:05:26,775 going to be persisted where it needs to be persisted and then move on. 88 00:05:27,211 --> 00:05:29,221 and just kind of feel like everything gets instantaneous. 89 00:05:29,221 --> 00:05:33,755 So, I have no doubts that that is what everybody wants. 90 00:05:34,113 --> 00:05:38,165 But obviously, as I'm sure we're going to discuss here over the next few minutes, 91 00:05:38,165 --> 00:05:40,598 is that it can be difficult to get there. 92 00:05:41,055 --> 00:05:44,475 and if you try and get there too quickly, I know you can get into some 93 00:05:44,475 --> 00:05:48,845 trouble and there's really smart people like you and many others who are, or 94 00:05:48,845 --> 00:05:53,375 who are slowly trying to carve out this space and make that a reality. 95 00:05:53,375 --> 00:06:00,875 So I am very anxiously and excitedly watching and also trying, we're trying 96 00:06:00,875 --> 00:06:05,495 to take part in that journey where it makes sense for TanStack to take part. 97 00:06:05,883 --> 00:06:06,573 That is awesome. 98 00:06:06,573 --> 00:06:09,553 Well, first of all, thank you so much for the kind words. 99 00:06:10,043 --> 00:06:14,423 I'm a huge fan of just like overall the way, also how you approach your 100 00:06:14,423 --> 00:06:18,653 projects, that you get to work on those projects in a sustainable way. 101 00:06:18,893 --> 00:06:23,223 And I think this is really why so many people trust your projects. 102 00:06:23,243 --> 00:06:25,353 So just wanted to mention that. 103 00:06:25,763 --> 00:06:30,106 And there's like many different ways how to reach and go after that 104 00:06:30,106 --> 00:06:34,366 goal that you've motivated, that you get instantaneous data, you get the 105 00:06:34,366 --> 00:06:37,036 simplicity coming from synchronous data. 106 00:06:37,640 --> 00:06:42,398 and I've certainly taken probably a more radical approach on that over 107 00:06:42,398 --> 00:06:46,858 the last couple of years where really like, I had the luxury of working on a 108 00:06:46,858 --> 00:06:52,018 greenfield project, so I was not burdened with everything that was there before. 109 00:06:52,018 --> 00:06:54,668 So I could make much more. 110 00:06:55,033 --> 00:06:57,433 radical and free design decisions. 111 00:06:57,583 --> 00:07:01,363 So in the case of LiveStore is why I've embraced event sourcing. 112 00:07:01,663 --> 00:07:05,473 But I think you are a bit more on the other side of the spectrum with 113 00:07:05,503 --> 00:07:11,446 a technology like React Query, which, at acknowledged the reality that in 114 00:07:11,446 --> 00:07:16,906 most projects there is already an API data source somewhere, and that 115 00:07:16,906 --> 00:07:18,886 makes it so much easier to adopt. 116 00:07:18,886 --> 00:07:23,159 And that shows in the download numbers and usage of, TanStack 117 00:07:23,176 --> 00:07:25,186 Query, formerly React Query. 118 00:07:25,721 --> 00:07:31,158 I think this is what most people really find themselves using on a daily basis, 119 00:07:31,158 --> 00:07:36,858 but as they aspire to make their app faster, to load more quickly, reload more 120 00:07:36,858 --> 00:07:43,245 quickly, then they also try maybe even make their app work in a offline scenario. 121 00:07:43,575 --> 00:07:45,825 Then they try to get there step by step. 122 00:07:46,125 --> 00:07:50,685 So maybe you can share some anecdotes of people doing that with 123 00:07:50,685 --> 00:07:54,948 TanStack Query where they reach for optimistic mutations, et cetera. 124 00:07:55,395 --> 00:07:56,685 Yeah, that happens all the time. 125 00:07:57,141 --> 00:07:59,751 I think that's one of the reasons why it took off, is because it's very 126 00:07:59,751 --> 00:08:04,915 pragmatic, for the slop that most people are working with every day. 127 00:08:04,915 --> 00:08:08,511 Whether that's your own slop, hopefully you've been in your job 128 00:08:08,511 --> 00:08:12,728 long enough to have to deal with your own slop, or it's slop from before, 129 00:08:13,208 --> 00:08:14,648 or you're just moving so fast that. 130 00:08:15,328 --> 00:08:16,318 That's just what it is. 131 00:08:16,933 --> 00:08:21,081 But, but the reality is that, you know, things are just messy, when 132 00:08:21,081 --> 00:08:24,231 you're shipping real products to real people as fast as possible. 133 00:08:24,815 --> 00:08:31,331 and I built React Query 'cause I needed a way to make the experience better for, for 134 00:08:31,336 --> 00:08:37,915 developers and users without needing to get in the middle of the entire process. 135 00:08:38,088 --> 00:08:41,868 like Meteor was trying to do, or like GraphQL was trying to do 136 00:08:42,348 --> 00:08:46,101 or Apollo, you know, I needed as little buy-in as possible with 137 00:08:46,191 --> 00:08:47,978 the maximum amount of, effect. 138 00:08:48,308 --> 00:08:53,298 And, that's what it came to be and I think it's very natural. 139 00:08:53,418 --> 00:08:58,191 when you start playing with Query, you start to realize that it is 140 00:08:58,761 --> 00:09:00,801 in a way, a sync engine, right? 141 00:09:00,801 --> 00:09:03,141 You have defined these declarative. 142 00:09:03,468 --> 00:09:07,805 subscriptions to your data, it's very manual, right? 143 00:09:08,195 --> 00:09:12,968 Very, course brain manual timings of like, how often do I want 144 00:09:12,968 --> 00:09:14,228 to go and get this thing right? 145 00:09:14,228 --> 00:09:19,778 So it's in the middle of like a one-off, API call and a sync engine. 146 00:09:19,858 --> 00:09:26,471 but it is living and breathing and, the life cycle of that life 147 00:09:26,651 --> 00:09:30,780 in this, Query cycle still takes some effort from users, you know? 148 00:09:30,780 --> 00:09:35,907 So when you change something, you need to let Query know, that you've 149 00:09:35,907 --> 00:09:37,587 changed something at the very least. 150 00:09:37,617 --> 00:09:39,567 And we call that this invalidation, right? 151 00:09:39,797 --> 00:09:44,062 And this is kind of like the bare minimum for What I would call 152 00:09:44,205 --> 00:09:49,125 probably the worst sync engine you could want is just like, I've changed 153 00:09:49,125 --> 00:09:53,355 something, invalidate everything and just re-sync everything, right? 154 00:09:53,355 --> 00:09:54,345 It's, it's very manual. 155 00:09:54,345 --> 00:09:56,655 You are the one deciding when to re-sync. 156 00:09:57,112 --> 00:09:59,782 And it turns out that a lot of developers just weren't 157 00:09:59,782 --> 00:10:01,192 doing that in the first place. 158 00:10:01,545 --> 00:10:07,562 so it's crazy to think that just teaching, giving people a good tool, like Query 159 00:10:07,562 --> 00:10:10,892 and then telling them, Hey, when you change something, you need to just 160 00:10:10,892 --> 00:10:14,072 mark everything as dirty and re-sync. 161 00:10:14,072 --> 00:10:14,312 It. 162 00:10:14,822 --> 00:10:19,742 Just, that has improved everybody's apps a ton. 163 00:10:20,042 --> 00:10:23,462 And user apps, you know, it's like, oh, data is up to date. 164 00:10:24,302 --> 00:10:28,142 You know, it's not super efficient, it's not automatic or whatever, but it is. 165 00:10:28,632 --> 00:10:31,882 so I think that's, the bare minimum, and that's the reality where a lot 166 00:10:31,882 --> 00:10:37,747 of developers are today is they're probably still coming, they may even 167 00:10:37,747 --> 00:10:44,017 be coming from .net or, you know, some monolithic backend shop into front 168 00:10:44,017 --> 00:10:49,567 end, and they've never done any front end syncing, data syncing at all. 169 00:10:49,837 --> 00:10:52,597 And they might just think, well, I'm just gonna call my API and display the data. 170 00:10:52,657 --> 00:10:52,957 Right? 171 00:10:53,557 --> 00:10:56,737 So I think that that's the reality for most developers. 172 00:10:57,007 --> 00:11:02,389 Most, successful companies are not running the latest and greatest, and many of 173 00:11:02,389 --> 00:11:06,269 them probably don't even know, you know, the first thing about designing a sync 174 00:11:06,289 --> 00:11:08,705 engine, I barely know anything about them. 175 00:11:09,095 --> 00:11:13,190 So I, I wouldn't expect many, you know, many of your run of the mill 176 00:11:13,190 --> 00:11:15,725 developers to know a lot about it either. 177 00:11:15,755 --> 00:11:18,245 So, but I think that's the first step. 178 00:11:18,275 --> 00:11:21,841 And I, I think personally that once you taste that, it's addicting. 179 00:11:22,516 --> 00:11:25,756 You want more of that and you naturally start to say, okay, 180 00:11:26,056 --> 00:11:27,226 how can I make this faster? 181 00:11:27,226 --> 00:11:27,586 Right? 182 00:11:27,736 --> 00:11:30,736 And that's on the read's end, which is kind of like the bare minimum. 183 00:11:30,736 --> 00:11:33,676 It's like, I wanna read my data and make sure it's up to date. 184 00:11:34,276 --> 00:11:36,826 And then you start thinking about the writes and you're like, oh, well you know 185 00:11:36,826 --> 00:11:42,196 what would be cool is if when I click this button it just showed that it's done, 186 00:11:42,736 --> 00:11:47,626 even though we know it takes, you know, a hot second for it to go and be done. 187 00:11:47,626 --> 00:11:50,356 And then to resync all the data, it'd be cool if it was 188 00:11:50,356 --> 00:11:52,006 just looked like it was done. 189 00:11:52,066 --> 00:11:55,156 And so we call that an optimistic update, right? 190 00:11:55,216 --> 00:11:59,853 Like optimistic, data manipulation and Query has that built in. 191 00:11:59,853 --> 00:12:01,083 Again, it's very manual. 192 00:12:01,250 --> 00:12:06,496 you have to manipulate the cache that's in your browser, in the Query client 193 00:12:07,096 --> 00:12:09,916 to represent that new state manually. 194 00:12:10,223 --> 00:12:13,100 and you fire off the mutation or, the change that's going 195 00:12:13,100 --> 00:12:14,240 to result in that state. 196 00:12:14,240 --> 00:12:15,650 And then you just kind of cross your fingers. 197 00:12:16,550 --> 00:12:19,310 That when you invalidate your data, when it's done and that new 198 00:12:19,310 --> 00:12:22,790 data comes in, it matches what you optimistically put in there. 199 00:12:23,413 --> 00:12:29,020 Again, this is like from my perspective, if you can implement optimistic 200 00:12:29,020 --> 00:12:33,893 mutations with something like Query, you're already so much further ahead 201 00:12:33,923 --> 00:12:37,763 than what the standard has been for a very, very, very long time. 202 00:12:38,473 --> 00:12:40,543 but like I said, it's very addicting. 203 00:12:41,023 --> 00:12:45,626 So then after that, you know, you start to think, okay, this 204 00:12:45,626 --> 00:12:50,276 mutation thing that I'm doing, these optimistic updates, those are tedious. 205 00:12:50,336 --> 00:12:54,026 You know, it's like, well, I have to, I have to make those perform, like make 206 00:12:54,026 --> 00:12:58,826 those optimizations myself and manipulate the cache and it feels dirty, right? 207 00:12:59,096 --> 00:13:03,596 And so that's when it starts to get a little more intense with like, 208 00:13:03,626 --> 00:13:09,626 okay, how could we make it so that when I say I clicked this button. 209 00:13:10,151 --> 00:13:16,841 I should like this post somewhere that I don't have to go in and manually 210 00:13:16,871 --> 00:13:23,381 kind of do the optimistic update that my mutation can just know what it's 211 00:13:23,381 --> 00:13:29,171 going to affect, make the update, send it to wherever it needs to go, and 212 00:13:29,171 --> 00:13:30,611 then it will sync when it needs to. 213 00:13:31,031 --> 00:13:35,655 And then we can just carry on, not just as like a user interface to click 214 00:13:35,655 --> 00:13:39,765 something and be able to carry on immediately, but also as a developer 215 00:13:39,765 --> 00:13:43,305 to be able to say, this is what's changing, and then just move on. 216 00:13:43,425 --> 00:13:47,245 You know, not have to worry about optimistic updates and cache 217 00:13:47,245 --> 00:13:48,385 and validations and whatnot. 218 00:13:48,445 --> 00:13:54,475 So this is where I think, at least for me, where things start to get really, 219 00:13:54,475 --> 00:13:56,635 really fun and really, really scary. 220 00:13:56,725 --> 00:13:59,875 Mostly because it's just, it's a new space, right? 221 00:14:01,390 --> 00:14:05,690 And, you know, to, give you my perspective on it, I haven't gone 222 00:14:05,690 --> 00:14:10,713 too far down that rabbit hole to be honest, because it involves a 223 00:14:10,713 --> 00:14:12,453 lot of knowledge about a system. 224 00:14:12,646 --> 00:14:18,256 usually involves knowing about schema or, creating schema in some way. 225 00:14:18,633 --> 00:14:23,253 there's different implications for where that data is being synced, whether it's 226 00:14:23,823 --> 00:14:27,903 local like offline or on a server or through web sockets or REST or whatever. 227 00:14:28,256 --> 00:14:33,356 so there's just a lot that comes with that and that has been intimidating 228 00:14:33,356 --> 00:14:37,076 for me because it's difficult for me to generalize where like, React 229 00:14:37,076 --> 00:14:39,146 Query was easy to generalize. 230 00:14:39,681 --> 00:14:42,066 but it doesn't mean that we're not thinking about it. 231 00:14:42,456 --> 00:14:42,786 You know? 232 00:14:43,225 --> 00:14:48,244 this was a, perfect tour from the beginnings of the motivations that led 233 00:14:48,244 --> 00:14:53,197 to React Query and now TanStack Query, the benefit it provides and like how 234 00:14:53,197 --> 00:14:56,872 far it gets you, but also like to the point where it brings you where things 235 00:14:56,872 --> 00:15:01,162 are already working pretty well, but maybe you face some new challenges 236 00:15:01,402 --> 00:15:06,142 and you would like things to work even more automatically in the right way. 237 00:15:06,937 --> 00:15:09,157 You now need to better understand that. 238 00:15:09,157 --> 00:15:13,987 And this is also like nicely reflects, like a lot of my thinking over the 239 00:15:13,987 --> 00:15:18,451 last decade where I've been wrestling with the same ideas and the same 240 00:15:18,451 --> 00:15:24,765 challenges and a few points always like bubbled up to me again as like those 241 00:15:24,765 --> 00:15:27,439 can't be ignored in a generalized way. 242 00:15:27,529 --> 00:15:31,363 And I think this is really the, key point to underscore here, like looking 243 00:15:31,363 --> 00:15:35,323 for a generalized solution and like at least I don't want to be the bearer of 244 00:15:35,323 --> 00:15:40,993 bad news, but I don't think for data there is a generalizable solution because 245 00:15:40,993 --> 00:15:44,143 data is like the ultimate as it depends. 246 00:15:44,473 --> 00:15:48,883 And I think this is where a technology like React as like 247 00:15:48,883 --> 00:15:50,578 the first of its kind in a way. 248 00:15:50,958 --> 00:15:57,631 showed us a, like close to generalizable solution that applied so perfectly 249 00:15:57,631 --> 00:16:02,311 to so many different situations and use cases, and unfortunately I don't 250 00:16:02,311 --> 00:16:04,881 think that is realistic for data. 251 00:16:04,931 --> 00:16:08,411 Just because for data you have just different trade-offs. 252 00:16:08,591 --> 00:16:12,251 Let's say you're building a banking app, this is where you really want to be 253 00:16:12,251 --> 00:16:15,011 certain has that wire gone out or not. 254 00:16:15,461 --> 00:16:19,961 But if you're building, let's say, a note taking app, it is actually more 255 00:16:19,961 --> 00:16:24,495 important that you can just carry on writing down your thoughts, then 256 00:16:24,525 --> 00:16:29,055 that you perfectly know that it's also already arrived on the server. 257 00:16:29,565 --> 00:16:33,315 And so it's just different trade-offs and those different trade-offs 258 00:16:33,585 --> 00:16:38,385 need or could be productized and systematized into something. 259 00:16:38,655 --> 00:16:44,475 And this again, is where I think React Query has been just so phenomenal in 260 00:16:44,475 --> 00:16:49,275 striking those trade-offs it meets people, where most of them are, where 261 00:16:49,275 --> 00:16:51,465 they don't need the perfect thing. 262 00:16:51,465 --> 00:16:54,495 Something good is already better than nothing. 263 00:16:54,495 --> 00:16:57,915 And then just like calling, fetch themselves and then, 264 00:16:58,281 --> 00:16:59,691 dealing with that somehow. 265 00:17:00,416 --> 00:17:04,706 But for people who wanna now go further for a more specialized path, 266 00:17:05,156 --> 00:17:10,136 I think this is where now there's like a, tree of potential new approaches 267 00:17:10,136 --> 00:17:11,606 and potential new technologies. 268 00:17:11,606 --> 00:17:14,216 And some of them you've been investigating. 269 00:17:14,246 --> 00:17:19,966 And I think, one particular like hairy topic here to investigate further is 270 00:17:19,966 --> 00:17:24,223 like, how do you get for the writes that you're doing for the optimistic 271 00:17:24,253 --> 00:17:26,378 updates or the updates more generally. 272 00:17:26,948 --> 00:17:31,808 What happens when you're updating data, like most directly, you're 273 00:17:31,808 --> 00:17:37,928 updating data in like a local variable somewhere, somehow running in your, 274 00:17:37,958 --> 00:17:43,718 let's say, React app, but then you're also maybe posting to an API endpoint, 275 00:17:43,958 --> 00:17:47,918 and now it's already, the universes are already potentially splitting. 276 00:17:48,308 --> 00:17:52,261 So you've updated your variable, maybe your API request. 277 00:17:52,466 --> 00:17:53,426 Goes through. 278 00:17:53,576 --> 00:17:58,016 And as that API request is being propagated further, fail 279 00:17:58,016 --> 00:18:01,556 somewhere there and now you need to unwind the entire thing. 280 00:18:01,886 --> 00:18:04,946 But let's say maybe you do two API requests, one goes through 281 00:18:04,946 --> 00:18:06,146 the other, doesn't go through. 282 00:18:06,506 --> 00:18:08,996 Now you're like in the split brain situation. 283 00:18:09,356 --> 00:18:13,796 And so now you need to, should you wind it back, should you partially wind it back? 284 00:18:14,246 --> 00:18:18,776 And now you need to handle that on your API server as well as on your client. 285 00:18:19,256 --> 00:18:22,766 And on the client, maybe you just say like, you know what, if we hit this 286 00:18:22,766 --> 00:18:26,486 case, it's so rare we just show an error message and say the user like 287 00:18:26,486 --> 00:18:28,976 reload, but maybe it's not so rare. 288 00:18:28,976 --> 00:18:32,066 And then you need to think about it in a more principled way. 289 00:18:32,456 --> 00:18:36,326 And this is where another kind of manifestation of that is cash 290 00:18:36,356 --> 00:18:41,731 inconsistency and There is a really great blog post, that goes 291 00:18:41,731 --> 00:18:44,977 along the lines of like, your app shouldn't become a database. 292 00:18:45,395 --> 00:18:46,849 we'll link it in the description. 293 00:18:47,359 --> 00:18:52,696 But, I think that is like a very nice and provocative post that shows the 294 00:18:52,696 --> 00:18:57,616 reality of most ambitious apps that as you pull more on that thread, your 295 00:18:57,616 --> 00:19:03,346 app becomes a database with all the hard things about a database, and it 296 00:19:03,346 --> 00:19:05,296 needs to be transactionally consistent. 297 00:19:05,296 --> 00:19:08,656 So if you click that button, maybe it should reflect in 298 00:19:08,836 --> 00:19:10,756 instead over here and over there. 299 00:19:11,236 --> 00:19:15,586 And if it doesn't, your app feels broken or things might actually like 300 00:19:15,911 --> 00:19:20,219 you get the dreaded, undefined is not a function because like some, like 301 00:19:20,219 --> 00:19:22,739 array index is not there, et cetera. 302 00:19:23,099 --> 00:19:26,159 And the more you pull on that, the more you want kind of like a 303 00:19:26,399 --> 00:19:31,284 React-like foundation that you can just trust that is maybe a bit more 304 00:19:31,284 --> 00:19:35,994 specialized to your use case, but you can actually trust and it just works. 305 00:19:36,114 --> 00:19:38,591 And this is where I hope things are going. 306 00:19:38,891 --> 00:19:43,421 Like, basically a tree of different possibilities for, mature and well 307 00:19:43,481 --> 00:19:49,644 designed data systems that, match the corresponding set of trade-offs. 308 00:19:49,944 --> 00:19:55,524 And it's now our role as educators to educate developers which trade-offs 309 00:19:55,524 --> 00:20:00,954 work well for their apps and what are good, solutions and systems for those. 310 00:20:01,374 --> 00:20:06,324 And I think that something like React Query has been an excellent catch 311 00:20:06,324 --> 00:20:08,354 all that already lifts people up. 312 00:20:08,954 --> 00:20:11,294 So I'm curious whether, that makes sense to you. 313 00:20:11,866 --> 00:20:15,886 I think that makes total sense and, you know, the way that I have always looked 314 00:20:16,156 --> 00:20:21,751 at like trying to solve these kinds of problems is: i'm always looking for like 315 00:20:21,751 --> 00:20:23,611 the least common denominator, right? 316 00:20:24,361 --> 00:20:27,751 And you can never find something that's perfect, but you can 317 00:20:27,751 --> 00:20:29,161 find something that's 90%. 318 00:20:29,971 --> 00:20:33,331 And then once you have tackled that problem, you can kind of move 319 00:20:33,391 --> 00:20:38,114 down the spectrum to, the use cases that might be more important or 320 00:20:38,114 --> 00:20:41,354 more intense, but you know, are not the least common denominator. 321 00:20:41,889 --> 00:20:44,409 and I think that's where React Query sits for me. 322 00:20:44,469 --> 00:20:48,862 You know, it's not the tool for all of the really, really specific 323 00:20:48,892 --> 00:20:53,422 difficult use cases, but 90% of the time it's the right choice. 324 00:20:53,850 --> 00:20:58,020 and then we can also, if you can build something where you can build 325 00:20:58,020 --> 00:21:01,440 on top of it to get to those other use cases, then that's even better. 326 00:21:01,916 --> 00:21:06,731 in this scenario, I personally am opening up more to the idea where 327 00:21:06,731 --> 00:21:12,272 there, you know, there could be this, general like solution, right? 328 00:21:12,562 --> 00:21:13,912 I don't know exactly how that looks. 329 00:21:13,912 --> 00:21:16,822 Like you said, I mean React kind of just happened and it was like, 330 00:21:16,852 --> 00:21:19,552 oh wow, this is a great solution for the problem components. 331 00:21:19,675 --> 00:21:25,742 I don't know if I've seen the component solution for like data 332 00:21:25,832 --> 00:21:29,732 yet, you know, 'cause there's so many different trade-offs. 333 00:21:29,732 --> 00:21:34,922 Like you said, I'm so interested in, see in synchronous data management 334 00:21:34,922 --> 00:21:36,302 through things like signals. 335 00:21:36,752 --> 00:21:40,922 Like I talk with Ryan Carniato all the time about, he's working on all 336 00:21:40,922 --> 00:21:45,812 this new Signals stuff and I just love it and I'm like, wow, this in terms 337 00:21:45,812 --> 00:21:48,122 of like reactivity, this is amazing. 338 00:21:48,122 --> 00:21:50,312 You know, this is something to keep your eye on. 339 00:21:50,832 --> 00:21:57,372 but a lot of the Signals stuff that we see also isn't crossing 340 00:21:57,372 --> 00:21:59,352 the network gap all the time. 341 00:21:59,614 --> 00:22:03,422 and so that gets weird into like, well, how do you then roll things 342 00:22:03,422 --> 00:22:05,462 back or how do you do transactions? 343 00:22:06,182 --> 00:22:11,202 And so there's this split world, like you said, between lots of 344 00:22:11,202 --> 00:22:13,212 effort going into both of these. 345 00:22:13,602 --> 00:22:15,672 and I don't necessarily think that's a bad thing. 346 00:22:16,012 --> 00:22:19,672 so I'll fill you in a little bit on something that we have been working on. 347 00:22:20,249 --> 00:22:24,869 a little while ago we teased a library called TanStack Optimistic. 348 00:22:25,319 --> 00:22:30,269 And the idea around TanStack Optimistic came from Kyle Matthews, and he's actually 349 00:22:30,269 --> 00:22:31,679 the one who's been spearheading it. 350 00:22:32,189 --> 00:22:37,949 and which is a crazy full circle because if you go back six or seven years, Kyle 351 00:22:37,949 --> 00:22:42,359 and I were actually competing at one point building static site generation software. 352 00:22:43,289 --> 00:22:45,779 I was building React Static, and he was working on Gatsby. 353 00:22:46,964 --> 00:22:50,114 Next Js was getting into static site gen, and it was cool. 354 00:22:50,251 --> 00:22:53,237 he went and raised money and turned Gatsby into this awesome thing. 355 00:22:53,237 --> 00:22:57,707 And I was like, well, I have a company already, so I'm gonna fold. 356 00:22:59,014 --> 00:23:00,964 I said, I'll have to do this later. 357 00:23:00,994 --> 00:23:02,004 And what do you know? 358 00:23:02,461 --> 00:23:07,511 now he's working on a new, on at a company doing ElectricSQL 359 00:23:07,531 --> 00:23:08,701 and really cool stuff there. 360 00:23:08,821 --> 00:23:10,531 And now I'm the one building the framework. 361 00:23:10,951 --> 00:23:14,461 So the, the roles feel reversed, but we're working together on some things 362 00:23:14,461 --> 00:23:19,527 right now because Kyle at ElectricSQL, they've become very interested in, 363 00:23:19,974 --> 00:23:24,474 this exact kind of general toolkit that we have kind of been alluding to. 364 00:23:25,031 --> 00:23:29,081 and one of the first problems that they ran into with ElectricSQL and, and 365 00:23:29,081 --> 00:23:34,691 React Query and all this was that, they needed those optimistic updates to work. 366 00:23:35,147 --> 00:23:37,187 but in a way that was kind of compatible. 367 00:23:37,742 --> 00:23:41,402 Not just ElectricSQL, but just kind of in general, like what's this general 368 00:23:42,062 --> 00:23:44,852 kind of optimistic transactional layer? 369 00:23:45,242 --> 00:23:47,912 And that's what TanStack optimistic started out as. 370 00:23:48,209 --> 00:23:49,826 and I mean, it worked, it was functional. 371 00:23:49,959 --> 00:23:53,739 it still works today, right now, but it's, it's already evolving. 372 00:23:53,799 --> 00:23:56,649 So that was just, you know, a couple months ago that we were 373 00:23:56,649 --> 00:23:58,089 talking about TanStack optimistic. 374 00:23:58,869 --> 00:24:02,169 So problem number one, TanStack optimistic is a bad name. 375 00:24:02,659 --> 00:24:05,929 because we already have optimistic updates in React Query, TanStack Query. 376 00:24:05,929 --> 00:24:08,809 So it's like, well, does this have something to do with Query? 377 00:24:09,326 --> 00:24:14,832 so it was confusing, the second problem was that, we wanted to figure out, you 378 00:24:14,832 --> 00:24:18,552 know, does this overlap with Query or not? 379 00:24:18,999 --> 00:24:22,972 and could it, should it utilize Query or is it something completely different? 380 00:24:23,062 --> 00:24:23,422 Right. 381 00:24:24,292 --> 00:24:24,862 And. 382 00:24:25,118 --> 00:24:29,731 So it turns out that, part of this layer we believe up to this point 383 00:24:30,061 --> 00:24:34,801 is that, like you said, if you start pulling on this thread long 384 00:24:34,801 --> 00:24:37,681 enough, it becomes a database, right? 385 00:24:37,967 --> 00:24:41,827 And I don't really think that's a bad thing because a 386 00:24:42,151 --> 00:24:43,741 database is a very loose term. 387 00:24:43,801 --> 00:24:47,581 If you look at React Query, there's a Query cache inside of 388 00:24:48,106 --> 00:24:52,126 query, and that's a database, you know, it's a key value store. 389 00:24:52,526 --> 00:24:56,036 it's not relational, it's not, you know, sophisticated in any way. 390 00:24:56,036 --> 00:24:56,936 I should clarify. 391 00:24:57,039 --> 00:25:01,149 like the application should not become a database, typically, it 392 00:25:01,149 --> 00:25:03,189 accidentally becomes a database. 393 00:25:03,189 --> 00:25:03,969 And that's the point. 394 00:25:04,149 --> 00:25:07,659 The app shouldn't be the database, but an underlying technology that 395 00:25:07,749 --> 00:25:12,609 you use that goes above and beyond to be a database to do all the hard 396 00:25:12,609 --> 00:25:14,439 work that it takes to be a database. 397 00:25:14,619 --> 00:25:15,879 That should be the database. 398 00:25:15,879 --> 00:25:17,649 And I think that's exactly what you're saying. 399 00:25:17,919 --> 00:25:18,709 Totally agree. 400 00:25:18,809 --> 00:25:19,199 Yes. 401 00:25:19,789 --> 00:25:23,169 And that's, I think that's the most interesting thing, is that the database 402 00:25:23,169 --> 00:25:28,909 is gonna be there no matter what, whether it's a, a replication, a cache, 403 00:25:29,309 --> 00:25:32,589 a lens, whatever you wanna call it, all these different terms, right. 404 00:25:33,095 --> 00:25:34,938 But that's, the direction we're headed. 405 00:25:34,998 --> 00:25:39,738 So we, we've actually renamed TanStack, optimistic to TanStack DB. 406 00:25:40,272 --> 00:25:46,492 And we're only working on a small part of it right now, which is the optimistic 407 00:25:46,492 --> 00:25:49,782 parts and the collections part. 408 00:25:49,942 --> 00:25:51,802 So let me get into that a little bit. 409 00:25:51,832 --> 00:25:54,922 We don't need to go too far into this because I'll be honest, Kyle 410 00:25:54,922 --> 00:25:57,592 knows 100% more about this than I do. 411 00:25:58,102 --> 00:25:59,632 I know 1%. 412 00:26:00,045 --> 00:26:04,005 we're just kind of consulting together just to make sure that like we can 413 00:26:04,005 --> 00:26:06,315 build on top of each other's things. 414 00:26:06,682 --> 00:26:11,458 what I understand at this point is that, you know, optimistic updates with 415 00:26:11,458 --> 00:26:13,468 something like Query only get you so far. 416 00:26:13,918 --> 00:26:17,118 And at some point you need that schema, like I was saying, you 417 00:26:17,118 --> 00:26:18,838 need some kind of structure. 418 00:26:19,378 --> 00:26:22,948 and you need some way to declaratively kind of build up these 419 00:26:22,948 --> 00:26:24,928 relationships between your data. 420 00:26:25,852 --> 00:26:31,938 of your data and that you're pulling from somewhere and your, mutations and, the 421 00:26:31,938 --> 00:26:34,218 actions you're taking against your data. 422 00:26:34,998 --> 00:26:40,420 And just having consistent actions against your data solves a lot of the problems 423 00:26:40,420 --> 00:26:44,920 around, well, if it was just signals and we're just kind of firing reactivity 424 00:26:44,920 --> 00:26:48,614 events off all over the place, how do you transaction those things together? 425 00:26:48,614 --> 00:26:49,604 How do you roll things back? 426 00:26:49,604 --> 00:26:50,834 I mean, there's ways to do that. 427 00:26:51,114 --> 00:26:55,621 but it, we found that if we formalize things into mutations still, which 428 00:26:55,621 --> 00:26:58,974 is very common across a lot of different database, implementations 429 00:26:58,974 --> 00:27:02,767 that, that you can transact on those much easier and roll things back. 430 00:27:02,767 --> 00:27:06,337 I mean, it's the same way with Convex, you know, in LiveStore too. 431 00:27:06,514 --> 00:27:12,484 so we want a layer that is purely for the front end, it's purely 432 00:27:12,484 --> 00:27:19,414 for the client where we can define these collections and define these 433 00:27:19,414 --> 00:27:22,984 mutations that are going to happen and the relationships between those. 434 00:27:23,354 --> 00:27:31,551 and then those can be fulfilled by syn So for instance, you can make a collection 435 00:27:31,551 --> 00:27:34,131 to say, you know, here's all my users. 436 00:27:34,624 --> 00:27:36,904 here's my filters on those users. 437 00:27:37,284 --> 00:27:40,344 here's pagination, or here's just all the things that kind of create the 438 00:27:40,344 --> 00:27:44,424 lens into this data source that I have. 439 00:27:44,814 --> 00:27:48,804 And it's formalized contract, formalized schema on how you get that. 440 00:27:49,344 --> 00:27:53,634 And then you have mutations that say, you know, I'm mutating this thing. 441 00:27:54,087 --> 00:27:58,257 and this thing is a formalized structure within my application, and it has schema. 442 00:27:58,544 --> 00:27:59,294 And then. 443 00:27:59,661 --> 00:28:04,671 Behind that layer, you have an adapter to say, okay, now that we 444 00:28:04,671 --> 00:28:08,181 have this formalized structure, we can wire this up to whatever we want. 445 00:28:08,571 --> 00:28:15,231 We could read using a rest API, and kind of we could say, well, we want to pull 446 00:28:15,231 --> 00:28:20,961 it, or we want to use invalidation, or we want to use SSE or something like that. 447 00:28:21,411 --> 00:28:24,231 Or you could set it up to work with web sockets, or you could set it 448 00:28:24,231 --> 00:28:26,661 up to work with SQLite or whatever. 449 00:28:27,191 --> 00:28:28,661 it just needs to be fulfilled. 450 00:28:28,911 --> 00:28:35,331 so in a similar way to React Query, saying, a promise is all you need, right? 451 00:28:35,821 --> 00:28:41,911 for TanStack db, the loose vision right now is that you need something 452 00:28:42,361 --> 00:28:46,811 that can satisfy the interface or not even the interface, but 453 00:28:47,171 --> 00:28:49,241 the lifecycle of a sync engine. 454 00:28:50,047 --> 00:28:56,407 That might be super drop in, like ElectricSQL or whatever, or it 455 00:28:56,407 --> 00:29:00,037 might be more manual, which is what I'm really excited about to say. 456 00:29:00,624 --> 00:29:03,414 I already have a rest, API, I'm already using React Query. 457 00:29:03,714 --> 00:29:08,664 We can't upgrade into web sockets or like do a bunch of crazy infrastructure 458 00:29:08,664 --> 00:29:10,524 stuff right now on the backend. 459 00:29:11,064 --> 00:29:15,774 But if we could kind of upgrade the lifecycle into this 460 00:29:15,774 --> 00:29:19,044 contract of sync engine, right? 461 00:29:19,584 --> 00:29:21,384 What does it mean to be a sync engine for the front end? 462 00:29:22,044 --> 00:29:28,404 Then you could technically upgrade your front end data reading and writing 463 00:29:28,404 --> 00:29:33,827 experience to what feels like a sync engine, but behind the scenes, It 464 00:29:33,827 --> 00:29:38,534 could just be going out and kind of using the same APIs that existed in 465 00:29:38,534 --> 00:29:40,274 your company a year ago or whatever. 466 00:29:40,904 --> 00:29:45,707 So I think that's the vision and to me that sounds like a least common 467 00:29:45,707 --> 00:29:51,394 denominator approach to it to say, data could get here somehow, and we're gonna 468 00:29:51,394 --> 00:29:55,744 send data out somehow and we're gonna build formalized contracts around that. 469 00:29:56,217 --> 00:30:02,811 and then hopefully, we see adoption around adapters and patterns and utilities. 470 00:30:03,211 --> 00:30:08,144 and possibly even around things like TanStack Query where maybe you 471 00:30:08,144 --> 00:30:14,414 don't have web sockets or service and events or sync engine happening. 472 00:30:14,684 --> 00:30:21,184 So maybe, maybe TanStack Query is the fulfiller of this contract, I think 473 00:30:21,184 --> 00:30:22,851 that starts to look very interesting. 474 00:30:22,851 --> 00:30:26,934 to be very blunt, that's kind of the, the envelope that's the bleeding edge of my 475 00:30:27,024 --> 00:30:29,204 opinions and my knowledge on the topic. 476 00:30:29,608 --> 00:30:34,498 everything honestly, from here forward is probably gonna be more, nuanced opinion 477 00:30:35,688 --> 00:30:36,588 That is awesome. 478 00:30:36,588 --> 00:30:38,808 And I think that really nicely closed the loop. 479 00:30:38,808 --> 00:30:43,188 Something that stuck with me that you said, the beginning of our conversation is 480 00:30:43,188 --> 00:30:49,478 that if you squint, React Query is already kind of like a mini sync engine is, the, 481 00:30:49,478 --> 00:30:51,878 the benefit is it works with everything. 482 00:30:52,148 --> 00:30:57,278 The downside is it only goes so far and doesn't handle all of those edge 483 00:30:57,278 --> 00:30:59,141 cases in the most resilient way. 484 00:30:59,141 --> 00:30:59,231 Right? 485 00:30:59,531 --> 00:31:03,731 But with like Pareto principle style, like you do 20% of the 486 00:31:03,731 --> 00:31:06,491 effort, you get 80%, of the outcome. 487 00:31:06,941 --> 00:31:12,558 And now you're connecting this to, a variation of it where what React Query 488 00:31:12,618 --> 00:31:14,958 already does is like, it's a Query part. 489 00:31:15,048 --> 00:31:16,368 So what do you Query? 490 00:31:16,368 --> 00:31:20,718 You Query from like something where data comes from and now you 491 00:31:20,718 --> 00:31:22,998 basically say, actually that is. 492 00:31:23,298 --> 00:31:24,978 Already very useful. 493 00:31:25,218 --> 00:31:28,278 But where we are getting the data from, there's sort of like this 494 00:31:28,278 --> 00:31:33,558 in-between stage where typically you resolve a Query to a database. 495 00:31:34,008 --> 00:31:37,968 And so we only have that, we don't really acknowledge that there is a 496 00:31:37,968 --> 00:31:41,748 database in the middle, but yet there is a database in the middle, right? 497 00:31:41,808 --> 00:31:44,928 And once we have that, and once we acknowledge it and build all 498 00:31:44,928 --> 00:31:48,528 the things around it, we can actually Query much more, much 499 00:31:48,528 --> 00:31:50,778 better, much faster, much safer. 500 00:31:51,001 --> 00:31:53,161 we get like super fast filtering. 501 00:31:53,161 --> 00:31:57,211 We these updates, optimistic updates become simpler, et cetera. 502 00:31:57,691 --> 00:31:59,161 Sort of like embracing that 503 00:31:59,881 --> 00:32:05,344 when you, when you sprinkle schema into things, a lot of dev tools get better. 504 00:32:05,738 --> 00:32:09,548 So, you know, the dev tools for Query are awesome, don't get me wrong. 505 00:32:09,698 --> 00:32:11,348 They, I think they're, I think they're great. 506 00:32:11,708 --> 00:32:13,058 But when you have schema. 507 00:32:13,703 --> 00:32:19,679 And formalized interfaces on top of your data dev tooling 508 00:32:19,679 --> 00:32:22,109 can get way more sophisticated. 509 00:32:22,706 --> 00:32:26,393 in fact, I'm remembering all of the awesome stuff that I've seen 510 00:32:26,393 --> 00:32:29,423 from LiveStore, you know, out, out of dev tooling that's like, 511 00:32:30,049 --> 00:32:33,709 it would be impossible to do with a tool with just Query, right? 512 00:32:34,116 --> 00:32:38,016 but, but you see some of that come into play when you know, 513 00:32:38,016 --> 00:32:39,636 okay, GraphQL gets involved. 514 00:32:39,636 --> 00:32:40,926 It's like, well, now we have schema. 515 00:32:40,956 --> 00:32:42,186 Now we can do all this cool stuff. 516 00:32:42,713 --> 00:32:44,993 it's kind of the sa it's kind of the same thing here. 517 00:32:44,993 --> 00:32:49,673 Whenever you add schema into something and create stricter contracts, even if those 518 00:32:49,673 --> 00:32:53,139 contracts are with yourself, like you can build much better tooling around it. 519 00:32:53,829 --> 00:32:58,269 I couldn't agree more schemas, like nine out of 10 cases. 520 00:32:58,609 --> 00:32:59,559 It's a great deal. 521 00:32:59,559 --> 00:33:04,479 You put in a little bit of work and you get so much out of it constantly 522 00:33:04,479 --> 00:33:09,399 in all of those different dimensions, types, validation, and like you can 523 00:33:09,399 --> 00:33:13,539 also like, and I think as a industry we've only scratched the surface what 524 00:33:13,539 --> 00:33:17,709 we can actually do with schemas, like at least as a JavaScript industry in 525 00:33:17,709 --> 00:33:23,199 other program languages, schemas are like highly leveraged to, for example, 526 00:33:23,409 --> 00:33:26,229 work with data in a more efficient way. 527 00:33:26,259 --> 00:33:29,069 So this is where like Protobuf, JRPC, et cetera. 528 00:33:29,069 --> 00:33:33,459 A lot of that is used to minimize the amount of data that we send 529 00:33:33,459 --> 00:33:37,659 across the wires or have more stable contracts as we are evolving things. 530 00:33:37,809 --> 00:33:41,259 And I think we're just scratching the surface of like what will be the 531 00:33:41,889 --> 00:33:46,569 javaScript equivalent where we have, so right now, maybe we have something that 532 00:33:46,569 --> 00:33:51,039 also gives us the benefit of something like Protobuf in let's say 2030. 533 00:33:51,279 --> 00:33:53,199 I don't wanna be overly optimistic here. 534 00:33:54,009 --> 00:33:54,579 Sounds accurate. 535 00:33:54,579 --> 00:34:00,586 But, but yeah, I, I think this is super compelling what you're pitching here. 536 00:34:00,586 --> 00:34:04,443 And like, I don't think this is just a, pitch, but it's actually happening. 537 00:34:04,683 --> 00:34:07,593 And, Kyle, who we also had previously on the guest. 538 00:34:08,193 --> 00:34:12,543 Who's now at Electric, is an excellent person to lead the charge on this, so 539 00:34:12,543 --> 00:34:14,733 I'm really excited to, see that evolve. 540 00:34:15,063 --> 00:34:18,633 I have many more questions that I would like to ask you or Kyle. 541 00:34:18,633 --> 00:34:18,873 Let's do it. 542 00:34:18,963 --> 00:34:22,593 But I'll, I'll, uh, I won't go too much into that there. 543 00:34:22,593 --> 00:34:26,649 Just as you mentioned that you're, only so far in the weeds so far. 544 00:34:26,949 --> 00:34:33,159 but one thing that I'm also curious about in regards to TanStack DB is do 545 00:34:33,159 --> 00:34:38,656 you already have a hunch of like, what is that contract, that makes when you bring 546 00:34:38,716 --> 00:34:44,899 a plugable, sync engine that you provide there as a data source, what does that 547 00:34:44,899 --> 00:34:47,569 need to quack like, that it's a duck, 548 00:34:48,219 --> 00:34:48,639 right? 549 00:34:49,166 --> 00:34:56,226 yes, we do have a flexible and changing idea of what those, contracts look like. 550 00:34:56,643 --> 00:35:00,003 in fact, in inside of, it's still at slash. 551 00:35:00,828 --> 00:35:03,258 Still at TanStack slash optimistic on GitHub. 552 00:35:03,694 --> 00:35:08,724 but we do already have, like some of the core hooks and logic set up in there 553 00:35:08,964 --> 00:35:14,298 already to around collections, that the documentation obviously isn't there 554 00:35:14,298 --> 00:35:19,174 yet, but if you dig into the code in the examples, you can start to see, kind 555 00:35:19,174 --> 00:35:22,448 of the silhouette of what syncing is. 556 00:35:22,448 --> 00:35:25,444 So, you know, we have some configuration. 557 00:35:25,782 --> 00:35:30,048 there's like a sync option that takes a sync configuration. 558 00:35:30,168 --> 00:35:35,738 So it has been formalized, for now in terms of what we believe 559 00:35:35,738 --> 00:35:38,708 it needs to be, you know, to get a proof of concept out the door. 560 00:35:39,248 --> 00:35:42,268 and you know, one of the good examples to go look at in there is there is 561 00:35:42,268 --> 00:35:48,733 an Electric, there's an Electric sync configuration that now dog foods, that 562 00:35:48,763 --> 00:35:52,603 that interface in that contract to kind of give you an idea of how that could feel. 563 00:35:53,053 --> 00:35:56,433 Now things are gonna change, things are gonna get better, upgrade, you 564 00:35:56,433 --> 00:36:00,753 know, we'll, we'll try and add more adapters and break our expectations. 565 00:36:00,753 --> 00:36:04,690 So, the idea is that the, those sync contracts are going to evolve 566 00:36:04,690 --> 00:36:07,816 drastically, over the next little while. 567 00:36:08,237 --> 00:36:09,047 That sounds awesome. 568 00:36:09,047 --> 00:36:13,907 And I'm particularly excited about all of those adapters since once you start 569 00:36:13,907 --> 00:36:18,827 adjusting your own perspective, then almost anything can be a data source 570 00:36:18,827 --> 00:36:21,017 or a sync engine for that matter. 571 00:36:21,197 --> 00:36:24,527 It might not be inherently reactive, but then you throw polling on 572 00:36:24,527 --> 00:36:29,297 it and until that data source is itself reactive, you can sort of, 573 00:36:29,654 --> 00:36:31,445 paper over that through polling. 574 00:36:31,475 --> 00:36:35,015 And just like a, let's say the GitHub, API could be actually 575 00:36:35,015 --> 00:36:37,265 a sync engine implementation. 576 00:36:37,265 --> 00:36:37,535 Absolutely. 577 00:36:37,535 --> 00:36:43,055 And now you can build a local app that works with like GitHub data just as 578 00:36:43,055 --> 00:36:45,005 it's local, like code, like is local. 579 00:36:45,005 --> 00:36:45,455 That's the idea. 580 00:36:46,400 --> 00:36:50,672 And, you know, going beyond that, I think, with Query right now, it's easy 581 00:36:50,672 --> 00:36:55,292 to get trapped into thinking like, oh, I can just Query my, my one database. 582 00:36:55,292 --> 00:36:57,932 Or you start thinking, well, I can Query multiple. 583 00:36:58,395 --> 00:37:01,305 or even start Querying anything that is a promise. 584 00:37:01,305 --> 00:37:06,765 So, so once you start thinking about the, the sync protocol or the sync contract 585 00:37:06,765 --> 00:37:11,132 as just something to be fulfilled, it kind of opens up the same gate. 586 00:37:11,432 --> 00:37:15,122 It's like a parable to when people are like, oh, I can use React Query to 587 00:37:15,152 --> 00:37:19,802 use, like device APIs because they're just based on a promise, you know? 588 00:37:20,222 --> 00:37:25,208 So I imagine the same thing will happen, for these sync contracts as we kind of 589 00:37:25,208 --> 00:37:29,338 just learn that, you know, oh, anything that I can read and write to, I can turn 590 00:37:29,338 --> 00:37:31,708 into a sync, like a sync configuration. 591 00:37:32,338 --> 00:37:36,178 And I think it gets really exciting when you start looking at the ability to have 592 00:37:36,658 --> 00:37:41,788 multiple sync configurations working together and potentially merging into 593 00:37:41,788 --> 00:37:44,282 the same schema in your application. 594 00:37:44,715 --> 00:37:46,755 and they might handle different responsibilities. 595 00:37:46,785 --> 00:37:48,375 'cause the reality is that. 596 00:37:48,800 --> 00:37:50,870 I mean, a lot of people would love offline. 597 00:37:51,290 --> 00:37:55,177 You know, you can do offline for a lot of things, but I don't know of 598 00:37:55,237 --> 00:38:01,877 any application that's providing a lot of value these days that doesn't 599 00:38:01,877 --> 00:38:04,757 eventually need to connect to the server. 600 00:38:05,207 --> 00:38:10,067 And like you said, eventually need very strict transactions on I did 601 00:38:10,067 --> 00:38:13,457 this thing and did it happen, and we cannot proceed until it did. 602 00:38:13,547 --> 00:38:13,877 Right? 603 00:38:14,417 --> 00:38:18,027 So we're trying to make sure that we don't code ourselves into a corner 604 00:38:18,027 --> 00:38:22,923 here and we wanna design it so that, you can do all of those things 605 00:38:22,923 --> 00:38:24,483 kinda, you know, synchronous first. 606 00:38:24,920 --> 00:38:29,480 you can have sync contracts that are very optimistic and just fire 607 00:38:29,480 --> 00:38:31,070 and forget and we'll sync it later. 608 00:38:31,580 --> 00:38:33,200 And when you need to. 609 00:38:33,560 --> 00:38:38,180 You can kind of go deeper and say, okay, I'm finding off this mutation, 610 00:38:38,360 --> 00:38:44,510 but I'd like to opt into some more strict confirmations around it to 611 00:38:44,510 --> 00:38:45,920 make sure that we don't proceed. 612 00:38:45,920 --> 00:38:48,560 You can lock things easier. 613 00:38:49,010 --> 00:38:54,343 So I don't know, I like this future where it's, it's kind of like Query 614 00:38:54,343 --> 00:39:00,233 for Query in a way where you know, we're just adding organization, we're 615 00:39:00,233 --> 00:39:07,193 adding more intelligent lifecycle where we're adding a heartbeat to 616 00:39:07,503 --> 00:39:11,583 what people experience today is react Query is like, oh, I'm syncing data. 617 00:39:11,913 --> 00:39:15,843 We're just going to breathe a little bit more life into that engine, 618 00:39:16,417 --> 00:39:22,957 without trying to control everything about the experience, about the 619 00:39:22,957 --> 00:39:27,063 backend, and about the language that you use to do things and. 620 00:39:27,612 --> 00:39:31,236 you know, if we can create that adapter economy there, I think that, we could 621 00:39:31,236 --> 00:39:35,259 see some really cool stuff happen, we're working really closely with ElectricSQL 622 00:39:35,259 --> 00:39:41,209 and also with Convex, you know, convex uses Query directly, which is amazing. 623 00:39:41,209 --> 00:39:46,429 And we also have really good relationships with TRPC that uses Query. 624 00:39:46,789 --> 00:39:53,442 So we have a lot of people involved in this, space to different varying degrees. 625 00:39:53,472 --> 00:39:57,726 And I'm confident that that's, really why we think now is a good time 626 00:39:57,726 --> 00:40:00,936 is because we have enough signal. 627 00:40:01,539 --> 00:40:05,109 to design something that could be helpful to a majority of people. 628 00:40:05,516 --> 00:40:08,696 We're trying to take a slow though, to be honest, because this is 629 00:40:08,696 --> 00:40:10,106 not something you just rush into. 630 00:40:11,066 --> 00:40:12,656 Oh, I completely agree. 631 00:40:12,686 --> 00:40:16,586 Maybe using this very topic as an opportunity to pull back 632 00:40:16,586 --> 00:40:18,056 the, the curtains a little bit. 633 00:40:18,436 --> 00:40:23,146 what I see as just like the common threads through all of the, the projects, the 634 00:40:23,146 --> 00:40:28,136 all the TanStack projects, is that they have a very, kinda like the, the TanStack 635 00:40:28,156 --> 00:40:30,646 way of like how the API looks and feels. 636 00:40:30,646 --> 00:40:32,426 It's like, it's very intuitive. 637 00:40:32,426 --> 00:40:38,296 It's nicely modeled around the common scenarios, but then also allows for like 638 00:40:38,296 --> 00:40:42,676 reaching for that extra configuration, that extra functionality once you need 639 00:40:42,676 --> 00:40:47,356 it, but it doesn't overwhelm you upfront with like, needing to know of all of that. 640 00:40:47,956 --> 00:40:53,682 And now you're going into a new field and in an existing field even deeper. 641 00:40:53,982 --> 00:40:56,082 And so now you need to apply like that's. 642 00:40:56,532 --> 00:41:01,922 At the end, there is a new TanStack DB products and library emerging, 643 00:41:02,292 --> 00:41:06,552 and I'm certain that will feel just as intuitive and as nice 644 00:41:06,552 --> 00:41:08,775 as the other TanStack libraries. 645 00:41:09,165 --> 00:41:12,252 But that doesn't just happen, by itself. 646 00:41:12,312 --> 00:41:15,972 But there's something, a lot of intuition, a lot of experience 647 00:41:15,972 --> 00:41:16,962 that's going into that. 648 00:41:17,352 --> 00:41:19,902 And I'm not sure whether you formalized that, but we, we got 649 00:41:19,902 --> 00:41:21,402 some questions from the audience. 650 00:41:21,655 --> 00:41:25,912 whether you have any sort of like process guidelines, your own 651 00:41:25,912 --> 00:41:29,392 guidance, your inner guidance, intuition, how would you frame that? 652 00:41:29,742 --> 00:41:34,562 that could also serve as advice to others who aspire to build tools, 653 00:41:34,562 --> 00:41:36,332 like, like the ones you're working on? 654 00:41:37,205 --> 00:41:38,405 Well, I like to think about it. 655 00:41:39,185 --> 00:41:43,925 I like to approach it in a way of like, there's different tiers 656 00:41:44,615 --> 00:41:46,415 of things that you can control. 657 00:41:47,015 --> 00:41:49,595 So for me personally, if I'm working on a project. 658 00:41:50,615 --> 00:41:51,575 Building it myself. 659 00:41:51,575 --> 00:41:57,569 Like I can control a lot and I'm just very picky and, I try to 660 00:41:57,569 --> 00:41:59,999 be my best customer in a way. 661 00:41:59,999 --> 00:42:04,319 Like, I try to approach using my own software as if I don't know everything 662 00:42:04,319 --> 00:42:07,109 about it and call me schizophrenic. 663 00:42:07,109 --> 00:42:10,709 But like, you need to be able to kind of assume this other identity 664 00:42:10,979 --> 00:42:13,869 to where you're like, okay, I don't know anything about this project. 665 00:42:13,869 --> 00:42:17,489 I'm trying to use this API, this is confusing. 666 00:42:17,519 --> 00:42:18,939 What does this even mean? 667 00:42:19,189 --> 00:42:22,769 So you need to wear multiple hats at the same time and be able to switch 668 00:42:22,769 --> 00:42:25,589 between them very quickly to say, oh, yeah, okay, now I'm gonna go back 669 00:42:25,589 --> 00:42:30,899 to, architect Tanner and, and, change this to, make it easier to understand. 670 00:42:31,469 --> 00:42:31,979 So. 671 00:42:32,564 --> 00:42:35,684 A lot of it is just, I think just being very picky and just using your 672 00:42:35,684 --> 00:42:40,904 own tools, like a lot, using your own tools a lot and showing other people 673 00:42:40,904 --> 00:42:44,684 your tools before you release them and say, well what do you think about this? 674 00:42:44,684 --> 00:42:47,744 And trying to teach your tool to people and they'll say, Hey, that's 675 00:42:47,744 --> 00:42:49,604 really cool, but this is super weird. 676 00:42:49,634 --> 00:42:50,984 Like, I don't agree with that. 677 00:42:51,224 --> 00:42:54,164 So you just need to be getting feedback all the time and say, 678 00:42:54,164 --> 00:42:55,394 always be shipping, right? 679 00:42:55,904 --> 00:43:00,584 You can ship to a friend, you can ship to your company, you can ship somewhere. 680 00:43:00,854 --> 00:43:04,514 It doesn't have to be NPM before, you know you can get feedback. 681 00:43:05,110 --> 00:43:06,277 so that's kind of rule number one. 682 00:43:06,717 --> 00:43:12,098 after that, I believe that at this point for TanStack, things 683 00:43:12,098 --> 00:43:13,504 are also changing a little bit. 684 00:43:13,504 --> 00:43:18,394 Like I said, I'm not the one who's the driving force between TanStack DB Kyle is. 685 00:43:18,754 --> 00:43:21,604 and if you look at other libraries, the same thing has kind of been happening. 686 00:43:21,604 --> 00:43:21,964 So. 687 00:43:22,296 --> 00:43:27,696 TanStack form was, you know, the bulk of the entire project was spearheaded and 688 00:43:27,696 --> 00:43:30,066 completed and done by Corbin Crutchley. 689 00:43:30,626 --> 00:43:35,036 and it doesn't mean I didn't, I had a lot to do with the initial, like, 690 00:43:35,336 --> 00:43:39,356 parts of TanStack form, you know, for the first little while, but I 691 00:43:39,356 --> 00:43:40,676 can't be everywhere all at once. 692 00:43:42,056 --> 00:43:46,599 So I've mostly been focusing on router and start for the last two years. 693 00:43:47,229 --> 00:43:52,569 And so the next part of it is, you know, if you can't control everything 694 00:43:52,569 --> 00:43:55,869 on your own, you need to be able to find people that you trust. 695 00:43:56,469 --> 00:44:02,542 And that's really what it comes down to is I get petitions and, people every day 696 00:44:02,869 --> 00:44:08,516 on Twitter and on GitHub who are like, Hey, I have this idea for a library. 697 00:44:08,546 --> 00:44:09,506 We should do it. 698 00:44:09,566 --> 00:44:12,326 Or I have this idea for a feature or whatever. 699 00:44:12,746 --> 00:44:13,286 And. 700 00:44:13,631 --> 00:44:16,909 that's excellent feedback when we take that feedback into consideration 701 00:44:16,969 --> 00:44:19,039 for all, all everything that we see. 702 00:44:19,466 --> 00:44:23,306 but the choice of letting somebody come in and start making decisions for 703 00:44:23,306 --> 00:44:25,076 you is a really, really big decision. 704 00:44:25,676 --> 00:44:28,166 And it just needs to be one that you trust. 705 00:44:28,166 --> 00:44:31,216 And so if you see one of the, every single one of the core 706 00:44:31,216 --> 00:44:36,362 maintainers and core contributors to TanStack, did not happen overnight. 707 00:44:36,519 --> 00:44:37,659 except for Corbin Crutchley. 708 00:44:37,659 --> 00:44:41,409 I met Corbin and I knew it in 10 minutes that, he was the right person for the job. 709 00:44:41,942 --> 00:44:43,532 but it really comes down to trust. 710 00:44:43,532 --> 00:44:47,672 And, and at the end of the day, I trust, you know, Dominic and 711 00:44:47,672 --> 00:44:54,452 Kevin and Corbin, and Manuel, and Sean and Chris and Kyle, right? 712 00:44:54,452 --> 00:44:58,312 I trust all these individuals and many more that I didn't 713 00:44:58,312 --> 00:45:01,146 mention, because they understand. 714 00:45:01,731 --> 00:45:02,301 The brand. 715 00:45:02,331 --> 00:45:06,988 Now they understand our priorities and they understand what needs to happen. 716 00:45:07,108 --> 00:45:11,322 You know, we, prioritize type safety above all else. 717 00:45:11,892 --> 00:45:17,142 You know, we prioritize the 90% use case above all else, but we make it so that you 718 00:45:17,142 --> 00:45:19,692 can gracefully opt into advance features. 719 00:45:20,278 --> 00:45:26,068 it's not formalized in a document, but it is formalized in the experience that 720 00:45:26,068 --> 00:45:28,558 you get using one of these libraries. 721 00:45:29,248 --> 00:45:33,138 And if you know, you know, and if we're going to ship a new product, 722 00:45:33,828 --> 00:45:37,188 everybody collectively understands that it needs to meet the same 723 00:45:37,188 --> 00:45:38,538 standards as all the other products. 724 00:45:38,538 --> 00:45:43,382 So, and the people that I, invite in or, want to come and help me 725 00:45:43,382 --> 00:45:46,442 build stuff, those are people that I trust to execute on that vision. 726 00:45:46,442 --> 00:45:46,742 So. 727 00:45:47,105 --> 00:45:47,945 That is awesome. 728 00:45:47,975 --> 00:45:49,325 I fully agree with that. 729 00:45:49,325 --> 00:45:51,275 Thank you so much for, for sharing that. 730 00:45:51,568 --> 00:45:55,918 you've mentioned TanStack Router and TanStack Start both of those projects. 731 00:45:55,918 --> 00:45:57,838 I'm also using myself a lot. 732 00:45:58,062 --> 00:46:01,692 I'm curious if you now extrapolate a little bit further. 733 00:46:01,692 --> 00:46:07,058 TanStack Start is, just getting to a point where it's will hit I guess 1.0 734 00:46:07,058 --> 00:46:11,918 at some point as well and if you're now extrapolate forward TanStack start 735 00:46:12,132 --> 00:46:15,992 filling in all of those, features and, boxes that you have in mind. 736 00:46:16,375 --> 00:46:21,355 and if you then take TanStack DB and you combine them, there's 737 00:46:21,355 --> 00:46:26,065 possibly like some really interesting opportunities that weren't really 738 00:46:26,065 --> 00:46:28,135 thinkable or possible before. 739 00:46:28,405 --> 00:46:32,365 Are there any kind of napkin sketches, shower thoughts you can 740 00:46:32,365 --> 00:46:37,482 share where you imagine like some new emerging, superpowers or kinda like 741 00:46:37,482 --> 00:46:40,872 a new kind of framework that will be possible for this combination? 742 00:46:41,302 --> 00:46:47,542 not in the sense of like some new monolithic enclosure around these 743 00:46:47,542 --> 00:46:53,658 things, but like the vision that I have for it is that, already today you 744 00:46:53,658 --> 00:46:56,638 can, build a TanStack Start project. 745 00:46:57,388 --> 00:47:01,928 And when you build a Start project, you're not, just using start. 746 00:47:01,988 --> 00:47:03,488 People don't understand this either. 747 00:47:03,488 --> 00:47:07,718 So, I mean, I'll take the moment to explain it so that like, when you use 748 00:47:07,718 --> 00:47:15,878 Next js right, you install next JS and the router is enclosed inside of next 749 00:47:15,878 --> 00:47:19,628 js, and the server loading strategies are all enclosed inside of there. 750 00:47:19,628 --> 00:47:22,708 The SSR tools and everything is just, monolithic. 751 00:47:22,708 --> 00:47:25,605 It's, abstractions around a whole thing, right? 752 00:47:26,095 --> 00:47:28,603 And there, there're dependencies inside of each other. 753 00:47:28,753 --> 00:47:31,783 Now, TanStack start is very different. 754 00:47:31,783 --> 00:47:35,833 It's weird because we say the framework is TanStack start, but it's not. 755 00:47:36,163 --> 00:47:41,500 It's just a convenient marketing, term to make it sound different 756 00:47:41,500 --> 00:47:43,300 than what TanStack router is. 757 00:47:43,780 --> 00:47:49,930 So TanStack router is what you'll still import with a start application 758 00:47:49,930 --> 00:47:51,280 that you've used it, you know this. 759 00:47:51,280 --> 00:47:55,540 So when you import, most of the imports that you're making and the utilities 760 00:47:55,540 --> 00:47:58,090 that you're calling with TanStack Start are actually coming from router. 761 00:47:58,583 --> 00:48:02,933 there's actually very few that are coming from start until you need 762 00:48:02,933 --> 00:48:05,033 those server side capabilities, right? 763 00:48:05,063 --> 00:48:11,460 So when you have your server entry, or you want to write an API route, or 764 00:48:11,460 --> 00:48:15,967 you have a server function or you need some middleware, or you need to access 765 00:48:16,387 --> 00:48:18,967 request headers or something like that. 766 00:48:19,582 --> 00:48:20,902 That's when you reach for Start. 767 00:48:21,292 --> 00:48:24,472 And so it's interesting to think about Start and Router as actual 768 00:48:24,712 --> 00:48:26,992 their parallel dependencies together. 769 00:48:27,475 --> 00:48:34,015 and yes, Start does rely on like a peer dependency in a sense of TanStack Router. 770 00:48:34,315 --> 00:48:37,495 So that's why we kind of say, oh, you're using TanStack Start 771 00:48:37,495 --> 00:48:39,985 because it implies usage of Router. 772 00:48:40,375 --> 00:48:43,975 But where they're together, I think that's the most interesting part because 773 00:48:44,485 --> 00:48:48,025 you get into the app and you start building and you realize that you're 774 00:48:48,025 --> 00:48:50,155 really just using these tools together. 775 00:48:51,155 --> 00:48:55,555 And maybe you're using TanStack Router and you're like, oh, this caching is 776 00:48:55,585 --> 00:48:57,325 really good in the router and I like this. 777 00:48:57,925 --> 00:49:03,205 And then you get to a moment where you're like, oh, I really wish I had formalized 778 00:49:03,265 --> 00:49:07,315 mutations around this thing, or that I could share data between routes. 779 00:49:07,705 --> 00:49:12,565 So then you bring in TanStack Query and you know, you don't just turn 780 00:49:12,565 --> 00:49:15,775 it on in the router, you bring in TanStack Query and they work together. 781 00:49:16,165 --> 00:49:16,435 So. 782 00:49:17,035 --> 00:49:21,715 They have interfaces that, integrate with each other and 783 00:49:21,715 --> 00:49:22,855 they work alongside each other. 784 00:49:23,695 --> 00:49:30,942 And my hope for something like TanStack DB around the router and start is 785 00:49:31,002 --> 00:49:33,425 that it would be the same experience. 786 00:49:33,455 --> 00:49:38,325 You would bring it in and you would use it alongside these other utilities. 787 00:49:38,702 --> 00:49:44,305 but the solution should be that bringing in something like TanStack db, the end 788 00:49:44,305 --> 00:49:48,565 result should be that you should be able to, with a little bit more work, 789 00:49:48,655 --> 00:49:54,115 like you said, up at this top layer of producing, you know, providing some schema 790 00:49:54,115 --> 00:49:58,675 and providing some, some structure that you would be able to then get rid of a 791 00:49:58,675 --> 00:50:02,208 lot of the code, that you have in your. 792 00:50:02,590 --> 00:50:10,553 data loading lifecycle points and your user interaction points, in your actual 793 00:50:10,553 --> 00:50:13,233 business logic of your application. 794 00:50:13,596 --> 00:50:17,840 the hope for something like TanStack DB would be similar to the experience of, 795 00:50:18,410 --> 00:50:23,240 you know, somebody moving into TanStack Query, being able to get rid of all of 796 00:50:23,240 --> 00:50:28,910 that manual data fetching code with fetch and useEffect and all this other stuff. 797 00:50:29,450 --> 00:50:31,070 Moving to something like Query. 798 00:50:31,640 --> 00:50:35,570 I want that same experience for TanStack DB if it's warranted, right? 799 00:50:35,570 --> 00:50:41,284 So it's like you're unintentionally building schema and database and trying, 800 00:50:41,284 --> 00:50:44,314 you know, it's like you're trying to formalize all these contracts, but you, 801 00:50:44,355 --> 00:50:45,700 don't have the right tool to do it. 802 00:50:46,567 --> 00:50:53,017 Moving to TanStack DB should be an event that removes the burden of a lot of code 803 00:50:53,047 --> 00:50:58,237 that you've written and removes a lot of the burden of linking queries together and 804 00:50:58,237 --> 00:51:00,187 linking mutations and queries together. 805 00:51:00,440 --> 00:51:01,460 that should be the goal. 806 00:51:01,824 --> 00:51:05,514 not only goal for the developer side of it, but also the user side of it, 807 00:51:05,514 --> 00:51:10,194 where when you move to Query from something that's very manual, all 808 00:51:10,194 --> 00:51:11,974 of a sudden your data is up to date. 809 00:51:11,974 --> 00:51:13,954 Now it's fresher. 810 00:51:13,974 --> 00:51:20,034 You can tell a website that's probably using React Query because you do something 811 00:51:20,034 --> 00:51:21,354 and it updates and it's always there. 812 00:51:21,684 --> 00:51:24,111 You focus the window and it's always there. 813 00:51:24,404 --> 00:51:27,554 same thing for moving something like TanStack db. 814 00:51:27,914 --> 00:51:30,524 You'll see better results around mutations. 815 00:51:30,524 --> 00:51:33,261 You know, you'll click something it won't just be optimistic, 816 00:51:33,261 --> 00:51:35,031 but it'll be synced everywhere. 817 00:51:35,528 --> 00:51:37,718 and when things happen on the server. 818 00:51:38,528 --> 00:51:42,998 And, you know, hopefully if you're using something like web sockets or some kind 819 00:51:42,998 --> 00:51:46,988 of servers sent event, you'll just kind of get that synced to you automatically 820 00:51:46,988 --> 00:51:49,658 without needing to invalidate or refocus the window or anything. 821 00:51:49,658 --> 00:51:54,614 So, if we can move both of those chess pieces forward, you know, both 822 00:51:54,614 --> 00:51:59,851 on the developer experience side of, Hey, I, get to delete code now and 823 00:52:00,121 --> 00:52:04,034 have better contracts and a better experience as a developer and just 824 00:52:04,034 --> 00:52:06,988 more confidence, in what I'm doing. 825 00:52:07,648 --> 00:52:12,388 And as a user, you get to move forward to say things are faster, they're 826 00:52:12,388 --> 00:52:16,828 more responsive, and the user also has more confidence that what they're 827 00:52:16,828 --> 00:52:21,524 doing is happening and what they're seeing is up to date and real, right? 828 00:52:21,854 --> 00:52:24,484 So I think that's, the end goal. 829 00:52:24,711 --> 00:52:26,991 and if we can't accomplish that, we won't launch it. 830 00:52:27,524 --> 00:52:28,454 that's the requirement, 831 00:52:28,893 --> 00:52:30,273 That definitely resonates. 832 00:52:30,333 --> 00:52:36,783 And I think that's sort of like a, a nice litmus test for a library that if 833 00:52:36,783 --> 00:52:41,763 you adopt a library in your application and the library does some things 834 00:52:41,763 --> 00:52:46,996 that you've previously done before, ideally the library should absorb 835 00:52:47,086 --> 00:52:51,976 everything that is not intent, that is very specific about your application. 836 00:52:52,276 --> 00:52:55,966 So everything that remains is like pure intent. 837 00:52:56,086 --> 00:52:57,766 That's about my application. 838 00:52:58,036 --> 00:53:02,296 Everything else is like, you've hopefully picked the right tool that like the 839 00:53:02,296 --> 00:53:06,466 choice of the tool is part of your intent, but then you're assuming down like one 840 00:53:06,466 --> 00:53:12,143 level, become even more meta about within the scope of this tool, this library. 841 00:53:12,263 --> 00:53:15,932 Now I'm specifying my further intent when you pick a really, really 842 00:53:15,932 --> 00:53:21,672 great tool, it's, you can notice it by, it removing even more code 843 00:53:21,672 --> 00:53:22,842 that you had previously written. 844 00:53:22,842 --> 00:53:27,836 It surprises you of like how concise you can express what you want to 845 00:53:27,836 --> 00:53:31,946 do in a way that you didn't even expect how simple this can be. 846 00:53:31,946 --> 00:53:36,866 And I think a really great library kinda like surprises you through its simplicity. 847 00:53:37,359 --> 00:53:42,549 and so I wanna round out this conversation on one last topic that 848 00:53:42,549 --> 00:53:46,359 I think you're a really excellent person to share your thoughts on this. 849 00:53:46,636 --> 00:53:52,406 most TanStack projects are more client side centric, like TanStack table, 850 00:53:52,436 --> 00:53:55,126 TanStack, form TanStack Query, et cetera. 851 00:53:55,199 --> 00:54:00,659 those are all primitives that help us to build rich client side applications. 852 00:54:00,998 --> 00:54:05,339 but if you're looking at the React ecosystem, on a larger scale, there's 853 00:54:05,339 --> 00:54:10,349 been a lot of momentum and movement and developments more on the server side 854 00:54:10,589 --> 00:54:13,199 spectrum of application development. 855 00:54:13,619 --> 00:54:18,029 And I think it can be a bit confusing for developers who are not as 856 00:54:18,029 --> 00:54:22,769 experienced on either side of the spectrum to what to kind of lean into. 857 00:54:22,769 --> 00:54:27,333 So it's not everything is always compatible and, there's maybe some 858 00:54:27,333 --> 00:54:31,563 applications that are being built that go heavily on server side 859 00:54:31,563 --> 00:54:35,433 technologies, even though that's not the best fit for them and vice versa. 860 00:54:35,613 --> 00:54:40,216 So I'm curious whether you can share some reflections on, that sort of 861 00:54:40,336 --> 00:54:45,106 broadening spectrum of react covering the server as well, and whether you can 862 00:54:45,106 --> 00:54:50,189 provide some guidance to developers, where to, focus their, attention on. 863 00:54:50,639 --> 00:54:51,959 That's a hard question. 864 00:54:52,411 --> 00:54:56,161 because there's a couple of different ways to look at that. 865 00:54:56,461 --> 00:54:57,961 There's a personal way to look at it. 866 00:54:57,961 --> 00:55:02,838 Like, what should you be learning yourself to, you know, be relevant? 867 00:55:03,581 --> 00:55:09,401 and I think that you should know as much of the web platform as you can, right? 868 00:55:09,791 --> 00:55:11,501 Whether that's client or server. 869 00:55:11,591 --> 00:55:16,258 You should, you know, if you're a web developer, you need to know the web. 870 00:55:16,821 --> 00:55:17,961 and that includes servers. 871 00:55:18,151 --> 00:55:23,511 So, on a personal level, you need to be learning as much as you possibly can. 872 00:55:24,011 --> 00:55:26,711 does that mean you need to be learning every language you can. 873 00:55:26,711 --> 00:55:27,161 No. 874 00:55:27,259 --> 00:55:31,074 but it means you need to know the concepts, to be able to at least 875 00:55:31,074 --> 00:55:35,378 communicate with, people or with a team, you know, accurately. 876 00:55:35,918 --> 00:55:40,268 So there's like this personal level thing that I, I think is really important. 877 00:55:40,268 --> 00:55:47,528 Like, I'm definitely not an expert at, you know other languages and like server side 878 00:55:47,558 --> 00:55:50,138 building, server side things, servers. 879 00:55:50,768 --> 00:55:55,441 but I've worked with teams that have built very, very sophisticated systems and I've 880 00:55:55,441 --> 00:55:57,181 helped architect some of those systems. 881 00:55:57,771 --> 00:56:00,171 and you know, I've been able to work through that, those thought 882 00:56:00,171 --> 00:56:01,581 processes and learn with them. 883 00:56:01,581 --> 00:56:03,531 So I think that's very valuable. 884 00:56:03,711 --> 00:56:07,674 Now, in, practice, I think practice is a little bit different. 885 00:56:07,864 --> 00:56:12,211 and this is where it's like a big, it depends, because you might be at, 886 00:56:12,388 --> 00:56:16,738 you know, Y Combinator startup where you just have to know everything and 887 00:56:16,738 --> 00:56:20,038 you are building full stack because you don't have a choice, right? 888 00:56:20,507 --> 00:56:24,237 and in that moment, your job requires you to do it all. 889 00:56:24,257 --> 00:56:25,487 So you better do it all. 890 00:56:25,487 --> 00:56:28,307 You better learn it, and you better in invest into everything that 891 00:56:28,307 --> 00:56:30,527 you need to ship your product. 892 00:56:31,097 --> 00:56:35,504 And I think that's really what it comes down to in practice is that, yes, you have 893 00:56:35,504 --> 00:56:37,454 to be thinking about your career, right? 894 00:56:37,904 --> 00:56:39,224 But not. 895 00:56:39,747 --> 00:56:42,747 being negligent to the task at hand. 896 00:56:42,747 --> 00:56:47,057 And if you work for a company where you're expected to be a, full stack 897 00:56:47,057 --> 00:56:50,477 developer, then you better make sure that you're investing in both the 898 00:56:50,477 --> 00:56:52,457 front end and the back end equally. 899 00:56:52,907 --> 00:56:57,347 if you work for a company and you're a front end developer and you know that, 900 00:56:57,557 --> 00:57:00,707 you know, pretty soon you're gonna, they're gonna start running React 901 00:57:00,707 --> 00:57:02,777 server components and server technology. 902 00:57:03,137 --> 00:57:06,797 Does it mean you need to become a database expert and learn SQL and learn 903 00:57:06,797 --> 00:57:11,567 how to run Redis and, you know, and Kubernetes or just Docker or whatever? 904 00:57:11,927 --> 00:57:15,197 No, it doesn't necessarily mean all of that, but it does mean that within 905 00:57:15,197 --> 00:57:19,397 the realm of, of like JavaScript running on the server, you should 906 00:57:19,397 --> 00:57:22,517 probably start getting familiar with JavaScript on the server. 907 00:57:22,937 --> 00:57:27,357 You should probably start learning, you know, what those patterns look like. 908 00:57:28,467 --> 00:57:33,104 And I think, you know, on, on the, really far end of the spectrum, which is more 909 00:57:33,104 --> 00:57:37,170 common than you think, because there, there's companies out there that have been 910 00:57:37,170 --> 00:57:42,627 around for a really long time and they're running technology that is, that's old 911 00:57:42,747 --> 00:57:46,407 and outdated, and they move slow and they make a lot of money and they have a lot 912 00:57:46,407 --> 00:57:51,687 of teams and a lot of employees, and maybe they're publicly traded, but that doesn't 913 00:57:51,687 --> 00:57:55,767 mean that, you know, that they're even allowed to run JavaScript on the server. 914 00:57:56,117 --> 00:58:00,857 I mean, there are companies out there that are, you know, billion dollar 915 00:58:00,857 --> 00:58:04,127 companies that are not allowed to run JavaScript on the server yet. 916 00:58:04,817 --> 00:58:09,213 So, in situations like that, it's like, well, do you need to focus on 917 00:58:09,273 --> 00:58:10,743 learning React server components? 918 00:58:11,253 --> 00:58:15,363 Sure, you can go check it out and, and learn how to do some things 919 00:58:15,363 --> 00:58:16,863 with SSR and play around with it. 920 00:58:17,433 --> 00:58:21,513 But if that's your job, your job is probably to be the best front 921 00:58:21,513 --> 00:58:23,603 end engineer that you possibly can. 922 00:58:24,223 --> 00:58:28,316 And if, that's the case, you just need to make sure that you're focusing 923 00:58:28,346 --> 00:58:29,916 on what's important to your company. 924 00:58:30,306 --> 00:58:33,096 So I don't want to sound like, you know, you need to sell out 925 00:58:33,096 --> 00:58:34,446 your career to your company. 926 00:58:34,973 --> 00:58:38,693 obviously I, you know, I like to stay on the bleeding edge of everything as well. 927 00:58:38,903 --> 00:58:41,903 I'm just a really pragmatic person, and at the end of the 928 00:58:41,903 --> 00:58:44,333 day, everybody wants to get paid. 929 00:58:44,453 --> 00:58:49,043 Everybody needs to get paid, and we should not ignore that that is a reality. 930 00:58:49,583 --> 00:58:54,876 And if your paycheck is important to you it's a, a critical piece of your life. 931 00:58:55,551 --> 00:58:59,841 Then you need to be focusing on, on what's gonna make sure that that paycheck 932 00:58:59,871 --> 00:59:01,581 keeps growing and getting bigger. 933 00:59:01,971 --> 00:59:06,448 And if that paycheck isn't going to get bigger or grow with your effort, Then you 934 00:59:06,448 --> 00:59:12,163 should be learning other technologies that will help you secure either a different 935 00:59:12,163 --> 00:59:17,593 job or a promotion or whatever that's going to let you use that new knowledge 936 00:59:17,653 --> 00:59:20,143 to grow yourself and grow your career. 937 00:59:20,833 --> 00:59:22,183 That, that's kind of where I put it. 938 00:59:22,208 --> 00:59:24,523 So it is, a lot of it depends, right? 939 00:59:25,019 --> 00:59:25,589 totally. 940 00:59:25,709 --> 00:59:27,569 I think that's fantastic advice. 941 00:59:27,569 --> 00:59:28,669 We can leave it at that. 942 00:59:28,669 --> 00:59:31,563 I know that, you only have so much time. 943 00:59:31,563 --> 00:59:33,483 I just wanna highlight one point. 944 00:59:33,543 --> 00:59:38,299 You've used the word pragmatic and this is really what, for me resembles that's the 945 00:59:38,299 --> 00:59:44,629 essence of like the entire TanStack family of tools, like it's above everything else. 946 00:59:44,629 --> 00:59:45,889 I think it's pragmatic. 947 00:59:46,159 --> 00:59:49,009 So in case you ever wanna formalize that, that is like my 948 00:59:49,009 --> 00:59:50,629 candidate I'm offering to you. 949 00:59:51,439 --> 00:59:55,649 I wanna thank you so much for taking the time, sharing, everything. 950 00:59:55,889 --> 00:59:57,299 That you've shared today. 951 00:59:57,563 --> 01:00:01,613 and for all the loves, sweat and tears you're putting into all of 952 01:00:01,613 --> 01:00:03,713 your projects for such a long time. 953 01:00:03,743 --> 01:00:06,413 I'm really excited to see where all of this is going. 954 01:00:06,713 --> 01:00:11,459 Particularly excited for TanStack DB and, thank you so much 955 01:00:11,459 --> 01:00:12,993 for, coming on the show today. 956 01:00:13,233 --> 01:00:13,803 Absolutely. 957 01:00:13,803 --> 01:00:14,313 It's been a pleasure. 958 01:00:15,166 --> 01:00:17,746 Thank you for listening to the localfirst.fm podcast. 959 01:00:17,926 --> 01:00:21,016 If you've enjoyed this episode and haven't done so already, please 960 01:00:21,016 --> 01:00:22,306 subscribe and leave a review. 961 01:00:22,696 --> 01:00:25,216 Please also share this episode with your friends and colleagues. 962 01:00:25,606 --> 01:00:28,606 Spreading the word about the podcast is a great way to support 963 01:00:28,606 --> 01:00:30,316 it and to help me keep it going. 964 01:00:30,976 --> 01:00:34,396 A special thanks again to Jazz for supporting this podcast. 965 01:00:34,696 --> 01:00:35,656 I'll see you next time.