WEBVTT 1 00:00:05.240 --> 00:00:08.759 Hey folks, welcome back to another episode of JavaScript Jabber. 2 00:00:09.160 --> 00:00:11.640 This week on our panel, we have a j O'Neil. 3 00:00:12.279 --> 00:00:17.160 Yo yo yo coming at you live from a broken 4 00:00:17.239 --> 00:00:21.000 Stater No, sorry, not stater solenoid. 5 00:00:22.519 --> 00:00:23.000 Okay. 6 00:00:24.280 --> 00:00:25.800 We also have Steve Edwards. 7 00:00:26.519 --> 00:00:30.120 Yo coming at you. Just one yo for me from 8 00:00:30.239 --> 00:00:31.399 Claudy and Cool Portland. 9 00:00:32.960 --> 00:00:36.679 I'm Charles Maxwood from Top End Devs. And this week 10 00:00:36.719 --> 00:00:39.960 we have a special guest that is Stephen Haberman. 11 00:00:40.520 --> 00:00:42.640 Steven, do you want to introduce yourself? I don't think 12 00:00:42.640 --> 00:00:43.640 we've had you on before. 13 00:00:44.240 --> 00:00:46.600 Yeah, sure, I will do a singular yo as well, 14 00:00:47.560 --> 00:00:52.560 coming from Omaha, Nebraska and yeah, yeah, really appreciate you 15 00:00:52.600 --> 00:00:57.359 having me on. In terms of intros right now, I'm 16 00:00:57.359 --> 00:01:00.320 a back end you know, team lead type in engineer 17 00:01:00.439 --> 00:01:04.719 at home Bound. You mentioned construction, so we're talking about Joyce, 18 00:01:04.799 --> 00:01:09.920 our joystore m home Bounds, a residential construction startup. So 19 00:01:09.959 --> 00:01:15.079 we besides just building SaaS software, well that's kind of 20 00:01:15.079 --> 00:01:17.159 the record. We don't build sas software. We're built software 21 00:01:17.239 --> 00:01:19.920 for the back end up. The main thing our company 22 00:01:20.319 --> 00:01:24.480 is built Home is build construction resident shams. And yeah 23 00:01:24.519 --> 00:01:24.799 that's me. 24 00:01:25.680 --> 00:01:29.480 Yeah, So you talked about the Joyce or m Yeah, 25 00:01:29.480 --> 00:01:31.480 I think you emailed me about it, and that's how 26 00:01:31.719 --> 00:01:37.239 how I found it. Anyway, I'm just wondering as we 27 00:01:37.280 --> 00:01:40.959 get into this, first of all, what problem does it solve? 28 00:01:41.040 --> 00:01:44.239 Then maybe that's tied up in why you built it. 29 00:01:44.760 --> 00:01:48.519 Yeah, sure, no, that's a great question. And so where 30 00:01:48.640 --> 00:01:51.200 where choice came from was a few years ago. We 31 00:01:51.200 --> 00:01:54.599 were setting up to build our back end stack. You know, 32 00:01:54.599 --> 00:01:56.920 we're a typescript shop. We do a lot of touch 33 00:01:56.959 --> 00:01:59.959 script on the front end, react very standards sort of stuff, 34 00:02:00.079 --> 00:02:02.680 and wanted to do various standard stuff on the back 35 00:02:02.760 --> 00:02:05.879 end as well, and we picked graph QL as are 36 00:02:06.159 --> 00:02:09.199 you know, layer in between at the time, which bastually 37 00:02:09.240 --> 00:02:12.159 still enjoy I know, you know that can be some 38 00:02:12.479 --> 00:02:15.000 that can be a tangent for later. But so we 39 00:02:15.039 --> 00:02:17.960 started off writing our graph QL back end in type 40 00:02:17.960 --> 00:02:20.719 script and you know, went to go pick an orm 41 00:02:20.800 --> 00:02:22.599 because that's kind of what you do when you do 42 00:02:22.639 --> 00:02:26.840 these things. This is probably twenty nineteen or so. And 43 00:02:27.000 --> 00:02:29.000 one of the things that we ran into just right 44 00:02:29.000 --> 00:02:31.599 away was just pervasive M plus ones and a graph 45 00:02:31.680 --> 00:02:34.080 QL and back end. So you know, graph CUOL is 46 00:02:34.080 --> 00:02:37.479 not like your typical endpoints right where in the typical 47 00:02:37.560 --> 00:02:41.240 web endpoint, you know, slash authors or whatever, you know 48 00:02:41.319 --> 00:02:42.960 exactly what your endpoint is going to do, so you 49 00:02:43.000 --> 00:02:45.759 can do one big query kind of upfront to you know, 50 00:02:45.840 --> 00:02:49.919 preload your data as much as you can and then 51 00:02:50.039 --> 00:02:54.199 let your logic run, you know, afterwards. But graph ql 52 00:02:54.280 --> 00:02:57.159 has such a dynamic you know, there is no single endpoint. 53 00:02:57.159 --> 00:03:01.439 Every quarter is so dynamic that you know, the engineer 54 00:03:01.479 --> 00:03:06.039 can't just upfront write the exact you know, preload or 55 00:03:06.120 --> 00:03:08.719 query or whatnot that it's going to magically load the 56 00:03:08.800 --> 00:03:12.479 data in a perform a way. So we've been using 57 00:03:12.520 --> 00:03:15.080 another ORM or two at the time, but we're just 58 00:03:15.159 --> 00:03:17.199 really struggling with M plus ones and so that was 59 00:03:17.240 --> 00:03:22.080 really joyce first claim to fame is that we had 60 00:03:22.080 --> 00:03:24.159 started out doing some co generation from the schema and 61 00:03:24.199 --> 00:03:26.520 that sort of thing, which is very standard now in 62 00:03:26.520 --> 00:03:31.400 a lot of ORMs. But yeah, we're just wanted to 63 00:03:31.400 --> 00:03:34.439 fundamentally solve M plus ones and so we started out 64 00:03:34.439 --> 00:03:37.039 putting Joyce on top of the Facebook data loader project, 65 00:03:37.159 --> 00:03:40.400 which uses this little you know, that event loop tic 66 00:03:40.560 --> 00:03:43.919 trick if you guys are familiar with that, to you know, 67 00:03:43.960 --> 00:03:48.520 if you know the N plus one problem, right, if 68 00:03:48.520 --> 00:03:50.159 I've got an author and I'm gonna read some books, 69 00:03:50.159 --> 00:03:51.800 and then the books I'm gonna read the book reviews, 70 00:03:51.800 --> 00:03:55.400 it's really easy for as you go down your object 71 00:03:55.439 --> 00:03:58.800 graph to like make a query for every single books, reviews, 72 00:03:58.840 --> 00:04:01.159 over and over and over and over over right and 73 00:04:01.199 --> 00:04:03.840 plus one, I guess. You know, let me know. If 74 00:04:03.879 --> 00:04:05.439 you want me to go slower through the N plus 75 00:04:05.439 --> 00:04:06.360 one problem. 76 00:04:06.080 --> 00:04:07.840 Well, yeah, I'm gonna say, I'll give it a real 77 00:04:07.879 --> 00:04:10.280 quick definition. I wanted to get into that quick before 78 00:04:10.280 --> 00:04:14.039 we love too far. So basically, if you have, you know, 79 00:04:14.120 --> 00:04:18.360 your books and author problems, the N plus one problem is. 80 00:04:18.319 --> 00:04:19.120 Where you do it. 81 00:04:19.399 --> 00:04:22.000 You know, a query for how would you put it? 82 00:04:22.040 --> 00:04:22.480 An author? 83 00:04:23.040 --> 00:04:24.879 So if you have an author that has multiple books, 84 00:04:24.879 --> 00:04:27.800 you're doing a query for every book, right, give me 85 00:04:28.680 --> 00:04:30.800 this author in this book, this author and this book, 86 00:04:30.800 --> 00:04:33.240 this author in this book. Whereas if to solve that problem, 87 00:04:33.319 --> 00:04:35.920 you can do one big query, give me this author 88 00:04:36.279 --> 00:04:39.839 and all their books, you know, in one query altogether 89 00:04:39.920 --> 00:04:42.319 all the book I d's I guess. So that's the 90 00:04:42.399 --> 00:04:45.800 basic N plus one. I'm sure there's better explanations. 91 00:04:45.199 --> 00:04:47.279 But that's that's what I have. 92 00:04:48.920 --> 00:04:53.720 Yeah, And it's really easy to happen to happen. So 93 00:04:53.839 --> 00:04:57.759 Joyce is an entity based r M. So it is 94 00:04:57.839 --> 00:05:01.399 very inspired by like Ruby and active record and some 95 00:05:01.439 --> 00:05:04.759 of the other og entity or ms. You know, if 96 00:05:04.759 --> 00:05:06.279 you go all the way back to you know, Og 97 00:05:06.399 --> 00:05:08.199 hybridn ate and Java hybridnade back in the day and 98 00:05:08.240 --> 00:05:12.639 those sort of things. But there's pros and cons of 99 00:05:12.879 --> 00:05:15.519 an entity or m type approach where you know, you 100 00:05:15.560 --> 00:05:18.120 think of your I really like to think of a 101 00:05:18.160 --> 00:05:21.279 database schema as a graph and a connected graph and 102 00:05:21.319 --> 00:05:25.560 that sort of thing. But if you think of them 103 00:05:25.560 --> 00:05:28.120 as objects, it's really easy, which is kind of the 104 00:05:28.120 --> 00:05:32.759 slippery slope of a leaky abstraction, right, because if you 105 00:05:32.800 --> 00:05:35.639 think of your entities as objects, which is what entity 106 00:05:35.720 --> 00:05:38.680 or ms do, it's really easy for programmers to accidentally 107 00:05:38.720 --> 00:05:43.319 write four loops that cause database queries, right, because if 108 00:05:43.399 --> 00:05:45.680 you have an author object and you're like, oh, I'm 109 00:05:45.720 --> 00:05:48.480 just gonna ask for the books, you know, one of 110 00:05:48.480 --> 00:05:50.600 the things that entity based or ms do is is 111 00:05:50.639 --> 00:05:52.680 they do this lazy loading of like, oh, you don't 112 00:05:52.680 --> 00:05:55.839 have the books, so go get those for you, which 113 00:05:55.839 --> 00:05:57.439 seems really nice. But as soon as you do that 114 00:05:57.480 --> 00:06:00.879 in a for loop, now you've you've got an M 115 00:06:00.879 --> 00:06:04.279 plus one, and that's been a problem in or MS, 116 00:06:04.319 --> 00:06:06.680 just like fundamentally forever. You know, as soon as you 117 00:06:06.759 --> 00:06:11.199 start doing and what's what's annoying is when it's it's 118 00:06:11.199 --> 00:06:13.160 more obvious when it's in the small. You know, if 119 00:06:13.199 --> 00:06:16.920 you've got an endpoint and you're right in your one 120 00:06:16.959 --> 00:06:19.839 endpoint file and you've right there in the code, you've 121 00:06:19.839 --> 00:06:21.279 got a for loop, You're like, well, I loaded the 122 00:06:21.319 --> 00:06:23.360 authors and then within that I'm loading the books. It's 123 00:06:23.439 --> 00:06:26.279 very obvious within this file that I need to you know, 124 00:06:26.319 --> 00:06:29.000 hoist my data loading up out of more my fore loop. 125 00:06:29.519 --> 00:06:32.519 But what's kind of insiduous about entity based or MS 126 00:06:32.639 --> 00:06:36.480 is is when you start running side effects and other 127 00:06:36.959 --> 00:06:39.519 drive business logic. Like you know, entity or ms. They 128 00:06:39.560 --> 00:06:42.439 like to put methods inside the author class to do 129 00:06:42.519 --> 00:06:45.040 some business logic or have an author life cycle hook 130 00:06:45.160 --> 00:06:47.439 or or these sort of things. And as soon as 131 00:06:47.560 --> 00:06:51.360 some of those side effects start, you know accidentally or 132 00:06:51.639 --> 00:06:56.240 sort of what's the emergent behavior being called in a loop? 133 00:06:56.959 --> 00:06:58.560 Now you know, you're back to an N plus one. 134 00:06:59.040 --> 00:07:01.879 And what was maybe interesting about graph QL was just 135 00:07:01.920 --> 00:07:04.439 like how quickly that happened, right, So like if you're 136 00:07:04.560 --> 00:07:07.000 in a rails back end, you can go, you know, 137 00:07:07.079 --> 00:07:09.959 two or three years and you know, fight your you know, 138 00:07:10.199 --> 00:07:11.920 you have your every two weeks and plus one that 139 00:07:12.000 --> 00:07:15.240 somebody goes and you know, figures out a production where 140 00:07:15.240 --> 00:07:17.920 it's happening and tries to magically hoist the data loading 141 00:07:18.000 --> 00:07:21.279 up to the top of the endpoint. And and that's 142 00:07:21.319 --> 00:07:23.199 just kind of a cost of doing business in a 143 00:07:23.199 --> 00:07:27.000 big rails back end. And but you can kind of 144 00:07:27.000 --> 00:07:29.319 get away with it, you know, until you your scale 145 00:07:29.439 --> 00:07:32.240 is too big or whatnot. And maybe what's unique, and 146 00:07:32.600 --> 00:07:35.120 maybe I think why graph ql has maybe not been 147 00:07:35.160 --> 00:07:37.800 as popular as it could have been is just how 148 00:07:37.839 --> 00:07:39.959 easy that is to happen. It happens right away in 149 00:07:40.000 --> 00:07:43.639 graph ql. And so that was really what Joyce set 150 00:07:43.680 --> 00:07:45.560 up to solve, was we wanted to make a back 151 00:07:45.639 --> 00:07:49.519 graph ko background back end that didn't suck, to go 152 00:07:49.639 --> 00:07:52.879 right right, and we leaned on this Facebook data loader, 153 00:07:53.399 --> 00:07:55.600 which did actually come out of the graph ql community. 154 00:07:55.639 --> 00:07:58.399 It's it's you know, we're sitting on shoulders of giants 155 00:07:58.399 --> 00:08:01.839 and those sort of things. But maybe what's unique about 156 00:08:01.879 --> 00:08:04.399 Joyce is the data loader pattern had been around for 157 00:08:04.399 --> 00:08:08.560 a long time, but engineers were generally expected to integrate 158 00:08:08.600 --> 00:08:11.079 it by hand, right, you go into this graph QL 159 00:08:11.160 --> 00:08:15.160 resolver and do your data loader logic or then you 160 00:08:15.160 --> 00:08:18.600 know there's i know, the graph quol frameworks like the 161 00:08:18.639 --> 00:08:24.279 fastifies and we're curious and those were of things that 162 00:08:24.439 --> 00:08:26.279 you know, they have the data loader pattern built into it, 163 00:08:26.319 --> 00:08:28.399 but you as the engineer had to go make use 164 00:08:28.439 --> 00:08:32.159 of it, and that's his boiler plate and nobody does it, 165 00:08:32.200 --> 00:08:35.039 and it's it's kind of annoying. So Joyce claimed the 166 00:08:35.080 --> 00:08:40.200 thing was that it's like every operation asterisks, there's one 167 00:08:40.279 --> 00:08:42.799 or two that don't, especially like paginated it's very hard 168 00:08:42.840 --> 00:08:47.440 to do passionated autobashion. But otherwise, like every operation and 169 00:08:47.519 --> 00:08:50.799 joyed auto batches through data loader. So if you asked 170 00:08:50.799 --> 00:08:54.200 for an author and you accidentally out ask for an 171 00:08:54.200 --> 00:08:56.279 author and a loop and you asked for fifty, that's 172 00:08:56.360 --> 00:08:59.879 you know, one sequel call if you accidentally or not 173 00:09:00.039 --> 00:09:03.440 and accidentally, you know, on purpose, load a bunch of 174 00:09:03.480 --> 00:09:05.080 books in a for loop, or a bunch of books 175 00:09:05.080 --> 00:09:07.279 in a life cycle event, or a bunch of you know, 176 00:09:07.559 --> 00:09:11.440 in a graph QL NaSTA graph col resolver. Basically, every 177 00:09:11.480 --> 00:09:15.519 operation enjoiced goes through a data liiver for free and 178 00:09:15.639 --> 00:09:22.000 gets auto batched, and yeah, that's what got us started 179 00:09:22.000 --> 00:09:22.519 down the path. 180 00:09:24.159 --> 00:09:27.399 How are you doing that? Do you do you await 181 00:09:27.480 --> 00:09:29.360 at the end. I'm actually looking for an example on 182 00:09:29.399 --> 00:09:32.200 your website, you see if I if I can see 183 00:09:32.240 --> 00:09:35.159 what this looks like. But I'm imagining you must not 184 00:09:35.320 --> 00:09:38.360 await in the loop because the data obviously isn't there 185 00:09:38.440 --> 00:09:40.240 if you're waiting for it to batch, So you must 186 00:09:40.279 --> 00:09:43.559 await at the end of the loop or something like that, 187 00:09:43.919 --> 00:09:47.039 or or you're putting it in a callback or something 188 00:09:47.080 --> 00:09:50.320 that some sort of handler rather than a promise. 189 00:09:51.080 --> 00:09:55.960 Yep, we had some good docs. Let's see if you 190 00:09:56.000 --> 00:09:59.639 go to goals and then avoiding mplus ones over on 191 00:09:59.639 --> 00:10:05.600 the OCCA probably describes it pretty well, really soulfully. And 192 00:10:06.360 --> 00:10:09.080 I mean the wrinkle is that we we sit on 193 00:10:09.120 --> 00:10:13.279 top of nodes promises. Promises are really amazing because they 194 00:10:13.519 --> 00:10:16.600 because they're on the event loop and you you always 195 00:10:16.600 --> 00:10:19.480 have to await them, which which it's ironic because in 196 00:10:19.519 --> 00:10:22.240 like twenty ten, this was like everything he did in 197 00:10:22.320 --> 00:10:23.840 node had to do a callback and it was really 198 00:10:23.919 --> 00:10:28.519 terrible and every you know, everybody hated it. But yeah, 199 00:10:28.960 --> 00:10:31.879 the people do a node in twenty ten, man that 200 00:10:32.240 --> 00:10:33.799 you were that was hardcore. 201 00:10:33.519 --> 00:10:35.440 But banging rocks together? 202 00:10:36.000 --> 00:10:39.080 Yeah right, Oh what's so ironic is is this how 203 00:10:39.159 --> 00:10:42.919 well JavaScript is a language and touch script especially on 204 00:10:42.960 --> 00:10:46.039 top of it, have evolved since then too, you know, 205 00:10:46.240 --> 00:10:48.559 add acy, kuwait and all of these things, such that 206 00:10:49.279 --> 00:10:51.600 it's termed what was really annoying? This event move model 207 00:10:51.799 --> 00:10:54.120 of only one thread at a time. It's a really 208 00:10:54.159 --> 00:10:58.759 a pretty pleasant environment to work in. And so to 209 00:10:58.799 --> 00:11:02.639 get back to what data leader this is basically because 210 00:11:02.679 --> 00:11:06.360 you have to await everything anyway, the promise in the 211 00:11:06.360 --> 00:11:10.000 event loop is basically what sets a really fast timer 212 00:11:10.039 --> 00:11:12.559 for you. So like, pretend we weren't in JavaScript, we 213 00:11:12.559 --> 00:11:14.759 were in Java or you know, o G Java or 214 00:11:14.799 --> 00:11:16.639 something like this, and you're like, okay, well I'm going 215 00:11:16.720 --> 00:11:19.320 to do you know, ten wire calls or twenty of 216 00:11:19.360 --> 00:11:21.480 wire calls. But I don't really know how many I'm 217 00:11:21.519 --> 00:11:23.799 going to do, right, because before you start your four loop, 218 00:11:23.840 --> 00:11:25.840 you don't know if there's five books or ten books 219 00:11:26.399 --> 00:11:27.919 or you know how many books that four loop is 220 00:11:27.960 --> 00:11:31.399 going to go through. And so you kind of but 221 00:11:31.559 --> 00:11:33.240 but you don't you want to make that first book 222 00:11:33.279 --> 00:11:35.120 call and I have it not go right away, right, 223 00:11:35.120 --> 00:11:37.559 because like as soon as the io leaves the server, 224 00:11:37.720 --> 00:11:39.919 you know there's your inmplus one. So you want to 225 00:11:39.960 --> 00:11:43.279 go through your your probbial four loop. You know, maybe 226 00:11:43.279 --> 00:11:45.600 this is a graph QL server run time or whatever, 227 00:11:45.639 --> 00:11:48.159 but you know, let's think of it as a four loop. 228 00:11:49.080 --> 00:11:50.960 You want to like ask for book one, ask for 229 00:11:51.000 --> 00:11:52.879 book two, ask for book three, ask for book four, 230 00:11:52.960 --> 00:11:55.799 and have these like not actually happen yet. You want 231 00:11:55.799 --> 00:11:57.879 them to just be I'm going to goad and jump 232 00:11:57.919 --> 00:12:00.759 to the term promises. You want to to be a 233 00:12:00.759 --> 00:12:04.240 promise of a book, and you want to wait until 234 00:12:04.360 --> 00:12:06.200 you've asked for all of the books. And there's the 235 00:12:06.240 --> 00:12:08.159 hard thing is you don't know when you're done in 236 00:12:08.440 --> 00:12:11.320 most environments, right, So like an og JAVA or something 237 00:12:11.360 --> 00:12:14.120 like this, you'd write a four loop and you would 238 00:12:14.120 --> 00:12:15.360 get to the end of the fore loop and then 239 00:12:15.440 --> 00:12:17.720 you would have to like tell the run time to like, Okay, 240 00:12:17.759 --> 00:12:20.080 I'm at the end of the fore loop, ask for 241 00:12:20.120 --> 00:12:23.320 all my books. You know, flush my book calls and 242 00:12:23.759 --> 00:12:27.000 you could do that, but nobody does. And so what's 243 00:12:27.000 --> 00:12:30.639 really interesting about promises instead is that the very first 244 00:12:30.879 --> 00:12:33.320 you know time you asked for a book, it puts 245 00:12:33.360 --> 00:12:35.399 a little I want to use the term poison building, 246 00:12:35.440 --> 00:12:37.759 but that's not quite right. It puts a little hint 247 00:12:37.799 --> 00:12:39.960 at the end of the event loop, which is going 248 00:12:40.039 --> 00:12:41.600 to run right away, right right. It's not like a 249 00:12:41.679 --> 00:12:43.840 set and Millie's fifty or a set Milli's one hundred. 250 00:12:44.159 --> 00:12:47.799 It just says, like, you know, in just a little bit, 251 00:12:48.159 --> 00:12:51.799 the next tick, right, plush, plush, my sequel calls and 252 00:12:51.840 --> 00:12:53.799 that's it. Like that, that's the end of the trick, 253 00:12:54.200 --> 00:12:58.440 and it's It's really pretty surprising how such a simple 254 00:12:58.480 --> 00:13:03.799 little idea can you know, fundamentally transform the performance in 255 00:13:04.240 --> 00:13:07.720 ergonomics right of choice, like with joice and things. Using 256 00:13:07.799 --> 00:13:14.320 data Vader, you get this really elegant you know, ervergence, autobatching. 257 00:13:15.000 --> 00:13:16.639 It just works, it always works. You don't have to 258 00:13:16.679 --> 00:13:18.480 do anything to get it. 259 00:13:19.600 --> 00:13:23.919 Yeah. I think that Objection does something similar to this too, 260 00:13:23.919 --> 00:13:25.720 at least it does with its query builder. You may 261 00:13:25.759 --> 00:13:29.600 have taken it a step further and that you're you're 262 00:13:29.679 --> 00:13:36.399 exposing a query builder kind of implicitly, so as you're 263 00:13:36.440 --> 00:13:39.879 going through the loop, the query builder continues until you're 264 00:13:39.919 --> 00:13:42.600 done with the loop. I haven't actually, I don't know 265 00:13:42.639 --> 00:13:44.879 if I've actually tried this an objection to know whether 266 00:13:44.960 --> 00:13:48.879 or not it's doing something similar with with the n 267 00:13:48.919 --> 00:13:52.399 plus one problem. But it the query builder in general 268 00:13:52.519 --> 00:13:56.080 is built that way, but it's more of a chaining 269 00:13:56.240 --> 00:13:58.879 type of thing, like you you can keep chaining the 270 00:13:58.960 --> 00:14:02.639 query builder and then it waits until next tick to 271 00:14:02.759 --> 00:14:06.200 actually resolve the query builder into something. So by the 272 00:14:06.320 --> 00:14:09.559 time you await it, you're awaiting whatever is at the 273 00:14:09.639 --> 00:14:11.440 end of the chain, not what's at the beginning of 274 00:14:11.480 --> 00:14:14.480 the chain, or or the chain collapses. I'm not really 275 00:14:14.519 --> 00:14:18.240 sure what the how the mechanism works, but I do 276 00:14:18.360 --> 00:14:22.480 know that it has it has similar magic where there's 277 00:14:22.559 --> 00:14:26.799 state management inside of the query builder that's waiting for 278 00:14:26.840 --> 00:14:30.879 that next tick in order to resolve the query builder. 279 00:14:30.879 --> 00:14:33.720 And this this looks This looks similar, but it's got 280 00:14:33.840 --> 00:14:38.919 more of a a naive looking you know, like like 281 00:14:39.000 --> 00:14:42.840 it looks naive and then you it look it looks 282 00:14:42.840 --> 00:14:45.159 like you have a dot each, So rather than using 283 00:14:45.279 --> 00:14:48.960 the four loop on it, you use it. Well, I'm 284 00:14:49.559 --> 00:14:51.759 I see where you're you're building the query. I don't 285 00:14:51.759 --> 00:14:54.320 see where you actually use the query. I saw one example, 286 00:14:54.519 --> 00:14:56.879 like there was a dot each. Is that what you're providing? 287 00:14:56.960 --> 00:14:59.720 So people don't people don't call four each, they call 288 00:14:59.799 --> 00:15:00.360 dot each. 289 00:15:03.519 --> 00:15:06.120 I'm trying to find that dot each that you're referencing. 290 00:15:06.600 --> 00:15:08.320 Oh you might. 291 00:15:09.159 --> 00:15:11.320 Oh that was that was an example of ruby code. 292 00:15:11.360 --> 00:15:14.120 Never mind, Yes, sorry, yeah. 293 00:15:13.360 --> 00:15:14.519 That is a very ruby thing. 294 00:15:14.600 --> 00:15:19.840 Yes, yeah, yeah, you know I didn't actually use rails 295 00:15:19.840 --> 00:15:21.919 for like years and years and years, but did just 296 00:15:21.960 --> 00:15:25.080 stuff rails and active record to be thoroughly impressed with 297 00:15:25.159 --> 00:15:30.240 the ergonomics and and so Joyce is kind of unashamedly 298 00:15:31.480 --> 00:15:34.360 tries to you know, borrow as much ergonomics and best 299 00:15:34.399 --> 00:15:36.960 practices as we can for active records. And so you'll 300 00:15:37.000 --> 00:15:39.759 see some active record isms, especially in the docks of 301 00:15:39.879 --> 00:15:44.559 you know how well, and particularly the M plus ones. 302 00:15:44.679 --> 00:15:47.200 I guess that would be one thing I think we 303 00:15:47.279 --> 00:15:49.159 kind of use this as a talking point is how 304 00:15:50.840 --> 00:15:54.240 active record, I would have heard, has not really solved 305 00:15:54.480 --> 00:16:01.080 like in the same way the joyst has solved M 306 00:16:01.120 --> 00:16:03.600 plus ones. You know, inactive record is is kind of 307 00:16:03.600 --> 00:16:05.200 this whack a mole job of finding where you need 308 00:16:05.200 --> 00:16:09.320 to do your load hint, you know, preload hint. And 309 00:16:09.879 --> 00:16:11.519 we can get into it maybe a little later, but 310 00:16:11.519 --> 00:16:13.960 but Choice does have the concept of preload hints to 311 00:16:14.320 --> 00:16:19.120 make all of your weights go away, which which is 312 00:16:19.159 --> 00:16:21.480 maybe a tangent. And so in Joyce you can do 313 00:16:21.519 --> 00:16:24.000 preloadhnts because you'll get more ergonomics and you don't have 314 00:16:24.039 --> 00:16:28.639 to awight coat, but you don't have to, like you'll 315 00:16:28.639 --> 00:16:32.279 still get this emergent auto batching behavior even without. And 316 00:16:32.960 --> 00:16:35.200 it's interesting you mentioned objection. I'll have to go. Look, 317 00:16:35.279 --> 00:16:38.440 it's been a while since i've you know, for sure 318 00:16:38.519 --> 00:16:42.879 taken a look at the other or ms around. I 319 00:16:42.919 --> 00:16:45.200 think a lot of the ORMs that I've seen, you know, 320 00:16:45.279 --> 00:16:47.279 do require these hints for the engineer to like know 321 00:16:47.440 --> 00:16:50.000 upfront what's going to happen, you know, to know upfront 322 00:16:50.000 --> 00:16:51.480 that in my query I need to ask for this, 323 00:16:51.519 --> 00:16:52.720 and in my query I need to ask for this 324 00:16:52.759 --> 00:16:54.639 because later somebody is going to use it, right, because 325 00:16:54.720 --> 00:16:56.960 later somebody is going to do a for loop. And 326 00:16:57.240 --> 00:17:03.279 that's really the beauty of the approach is it's there's 327 00:17:03.600 --> 00:17:07.319 you know, any emergent behavior that actually accidentally runs accidentally 328 00:17:07.400 --> 00:17:10.440 or on purpose runs in a loop gets the gets 329 00:17:10.440 --> 00:17:11.079 the autovension. 330 00:17:13.559 --> 00:17:16.559 Okay, yeah, so if I I would love it if 331 00:17:16.680 --> 00:17:19.480 with your N plus ones lazy loading in a loop, example, 332 00:17:19.599 --> 00:17:24.039 if if it continued like the next one or three 333 00:17:24.119 --> 00:17:27.960 lines or whatever comes after this, I get what's happening there. 334 00:17:28.000 --> 00:17:31.319 But then I wonder, how would I use this, because 335 00:17:31.319 --> 00:17:35.119 it because you know, every everything's alighted away as to 336 00:17:35.160 --> 00:17:37.440 how I use it, And just for the mental model 337 00:17:37.559 --> 00:17:40.440 of it, I'm like, do it, do I await it 338 00:17:40.519 --> 00:17:45.160 a final time? Or do I what I. 339 00:17:45.119 --> 00:17:47.039 See what you're saying. Maybe go to the load safe 340 00:17:47.079 --> 00:17:50.079 relations page right below this you'll get a little bit 341 00:17:50.079 --> 00:17:54.799 of a few more Synceax examples of like using acting 342 00:17:54.880 --> 00:17:59.240 the entities and the relations on the entities, so we 343 00:17:59.319 --> 00:18:01.680 do wrap our relations, you know. So this would be 344 00:18:01.720 --> 00:18:04.200 author dot books, you know, that's the books relation or 345 00:18:04.480 --> 00:18:08.720 author dut publishers, the publisher relation, and some of the 346 00:18:08.720 --> 00:18:11.599 og ORMs like type orm at least back when I 347 00:18:11.640 --> 00:18:14.079 did it, and I'm ninety percent sure they still do that, 348 00:18:14.960 --> 00:18:18.079 and even the java ORMs the hybernates in the world. 349 00:18:18.119 --> 00:18:21.599 What a model of those like? As the array directly right, 350 00:18:21.720 --> 00:18:26.039 author dot books is literally a book array, but it's 351 00:18:26.079 --> 00:18:27.920 not really because it has to be lazy loaded, right, 352 00:18:27.960 --> 00:18:30.599 and so then they do various proxy lazy loading magic 353 00:18:30.640 --> 00:18:32.559 to make it look like a book array as soon 354 00:18:32.599 --> 00:18:35.000 as you access it. We go ahead and wrap all 355 00:18:35.000 --> 00:18:39.279 of our relations and these little rappers that you can 356 00:18:39.359 --> 00:18:41.480 either ask to be loaded. So like on that load 357 00:18:41.519 --> 00:18:46.480 safe relations, you'll if the publisher's not loaded yet, the 358 00:18:46.519 --> 00:18:48.000 type system knows about it. If this is kind of 359 00:18:48.000 --> 00:18:51.799 the tangent that I was alluding to earlier, is that 360 00:18:52.119 --> 00:18:54.799 when I used type orm back in the day, because 361 00:18:54.839 --> 00:18:58.400 of this, the type system would never know whether something 362 00:18:58.519 --> 00:19:01.079 was loaded or not. Right, if you just gave me 363 00:19:01.079 --> 00:19:03.960 an author and I wanted to get to the books, 364 00:19:04.680 --> 00:19:07.720 sure I could do author books, but but I didn't 365 00:19:07.720 --> 00:19:10.160 really know whether that had been loaded or not. 366 00:19:11.160 --> 00:19:14.279 And if they're all monads, it's monads all the way down. 367 00:19:14.799 --> 00:19:20.319 Well you're getting yes, you're getting that. Yeah, and so 368 00:19:21.359 --> 00:19:31.240 correct use of monads. Nice. No, Actually, well, you guys 369 00:19:31.240 --> 00:19:35.880 talked about effect recently, right, how those guys on the podcast. 370 00:19:35.880 --> 00:19:37.880 I think that's how that go by the TS effect 371 00:19:41.680 --> 00:19:45.279 Or maybe I'm getting my podcast mixed up. Well, the 372 00:19:46.359 --> 00:19:49.640 promise promise is basically a monad unless you talk to 373 00:19:49.680 --> 00:19:51.720 the TS affect people, and the TS effect people have 374 00:19:51.759 --> 00:19:54.400 strong opinions how promise is not the perfect monad, and 375 00:19:54.440 --> 00:19:58.160 they have their own effect that is the more perfect monad. 376 00:19:58.759 --> 00:20:00.799 Which is fine, but I I don't know. I think 377 00:20:00.960 --> 00:20:05.839 it's a little maybe academic and promising is just fine 378 00:20:05.839 --> 00:20:07.279 to me, I guess so for. 379 00:20:07.359 --> 00:20:11.519 The people at home, yeah, that have never encountered somebody 380 00:20:11.680 --> 00:20:14.759 who can both know what a monad is and explain 381 00:20:14.839 --> 00:20:17.400 it in a way that other people can understand at 382 00:20:17.400 --> 00:20:21.079 the same time. I am the singularity. Now, a monad 383 00:20:21.160 --> 00:20:26.720 is simply an object that encapsulates a value that is 384 00:20:26.880 --> 00:20:29.680 not the value itself. So, for example, if you have 385 00:20:30.880 --> 00:20:35.200 answer is equal to forty two, that's a value. If 386 00:20:35.200 --> 00:20:37.559 you were to wrap answer in a promise so that 387 00:20:37.640 --> 00:20:39.799 you have to do something else like call dot then 388 00:20:39.880 --> 00:20:42.640 or in some way unwrap it in order to get 389 00:20:42.680 --> 00:20:45.839 the value forty two out of it, that's a monad. 390 00:20:48.119 --> 00:20:50.680 Yeah, and I think it's applicable here because I think 391 00:20:50.720 --> 00:20:53.480 one of the things moments are great about is delaying evaluation. 392 00:20:54.200 --> 00:20:56.079 You know, to your example, when you ask for forty 393 00:20:56.079 --> 00:20:58.160 two and it's just like forty two is right there. 394 00:20:58.480 --> 00:21:01.240 You know, there's no ability to do like metaprogramming around 395 00:21:01.279 --> 00:21:05.079 that or you know, but if you're you know, you 396 00:21:05.160 --> 00:21:07.279 mentioned monad wrapping the value that you have to ask 397 00:21:07.359 --> 00:21:11.039 for the fact that monad's fundamental and promises. You know, 398 00:21:11.200 --> 00:21:14.160 is is if you squint a monad, you have to 399 00:21:14.200 --> 00:21:18.640 ask it for its value. That that delayed execution is 400 00:21:18.640 --> 00:21:23.000 what allows you to do fun things like autobatchet sequel calls. 401 00:21:25.240 --> 00:21:27.440