WEBVTT 1 00:00:00.040 --> 00:00:03.600 All right, time to dive in. Today. We're going to 2 00:00:03.680 --> 00:00:07.240 be looking at rust specifically how it's used in web development. 3 00:00:07.480 --> 00:00:09.160 And you know what, you've given us a really interesting 4 00:00:09.199 --> 00:00:11.919 mix of stuff to go through. Oh yeah, yeah, we've 5 00:00:11.919 --> 00:00:14.960 got excerpts from this book practical Rust Web projects, and 6 00:00:15.000 --> 00:00:18.800 then some of the official documentation for Rust itself. So yeah, 7 00:00:19.079 --> 00:00:20.320 it should be fun to dig into. 8 00:00:20.399 --> 00:00:22.719 Yeah, that's a great combo. There's like we can get 9 00:00:22.719 --> 00:00:25.359 the practical side and then dive into like all the 10 00:00:25.519 --> 00:00:28.079 nitty gritty technical stuff that you know makes it. 11 00:00:28.120 --> 00:00:31.760 Tick totally, and right off the bat, the book highlights 12 00:00:31.800 --> 00:00:37.240 these three big strength of Rust, right, security, concurrency, and 13 00:00:37.320 --> 00:00:41.560 then low level control. And for someone building like a website, 14 00:00:41.640 --> 00:00:44.560 especially one that you know, handles sensitive stuff or needs 15 00:00:44.560 --> 00:00:47.439 to be super responsive. I mean, these features sound almost 16 00:00:47.439 --> 00:00:48.320 too good to be true. 17 00:00:48.600 --> 00:00:51.200 Well let's break them down. First off, security, I mean, 18 00:00:51.240 --> 00:00:53.119 when it comes to the web, right, the stakes are high, 19 00:00:53.479 --> 00:00:56.560 like really high. One little vulnerability and oh boy, things 20 00:00:56.600 --> 00:00:57.520 can go south fast. 21 00:00:57.759 --> 00:00:57.840 Right. 22 00:00:58.039 --> 00:01:00.280 What's wild about Rust is that it can actually like 23 00:01:00.520 --> 00:01:03.520 stop a lot of common security problems right at compile time. 24 00:01:03.840 --> 00:01:06.799 Wait, so you mean before the code even runs exactly. 25 00:01:06.840 --> 00:01:10.239 It's like the compiler is this super thorough code inspector. 26 00:01:10.280 --> 00:01:14.760 You know, it's checking for like memory errors, data rases, 27 00:01:14.799 --> 00:01:17.359 and all these other sneaky things that could like create 28 00:01:17.400 --> 00:01:21.719 security holes. Having that kind of scrutiny at the compilation stage, 29 00:01:21.959 --> 00:01:25.079 m hm, it gives developers a huge advantage, a level 30 00:01:25.079 --> 00:01:28.159 of like confidence that's really hard to get with other languages. 31 00:01:28.319 --> 00:01:31.439 That's a powerful advantage for sure, especially like you said, 32 00:01:31.680 --> 00:01:35.159 these days where everyone's so concerned about security. Right, But okay, 33 00:01:35.159 --> 00:01:39.439 what about concurrency? I mean, websites these days, they have 34 00:01:39.480 --> 00:01:42.840 to handle so much at once, right, like user interactions, 35 00:01:42.959 --> 00:01:46.599 database queries, all these background processes. Just seems like a 36 00:01:46.719 --> 00:01:50.079 nightmare to manage all that efficiently and you know safely. 37 00:01:50.519 --> 00:01:53.439 You're right. Concurrency is a major challenge in web development. 38 00:01:53.519 --> 00:01:55.519 Like the old ways of doing things, they often lead 39 00:01:55.519 --> 00:01:58.680 to code that's like super complex and easy to mess up. 40 00:01:58.719 --> 00:02:01.959 I mean, but rust it tackles this head on with 41 00:02:02.040 --> 00:02:05.920 its ownership and borrowing system. This ensures that your code 42 00:02:05.959 --> 00:02:11.120 is thread safe, but without like sacrificing performance. Honestly, it's 43 00:02:11.120 --> 00:02:14.639 a game changer for building like high performance web apps 44 00:02:14.680 --> 00:02:15.759 that you can actually rely on. 45 00:02:16.280 --> 00:02:18.599 Okay, I'm starting to see why people are so excited 46 00:02:18.639 --> 00:02:23.120 about Rust. Now, the book also mentions low level control 47 00:02:23.159 --> 00:02:26.439 as a strength. But is that something that you know, 48 00:02:26.520 --> 00:02:29.080 a typical web developer really needs to worry about. It 49 00:02:29.120 --> 00:02:31.039 sounds kind of intimidating, to be honest. 50 00:02:31.080 --> 00:02:34.240 You don't have to be like a hardware guru or anything, 51 00:02:34.599 --> 00:02:36.879 but having that low level control can be a real asset, 52 00:02:36.960 --> 00:02:39.199 especially when you're like trying to squeeze out every bit 53 00:02:39.240 --> 00:02:39.840 of performance. 54 00:02:40.000 --> 00:02:40.280 Okay. 55 00:02:40.400 --> 00:02:43.319 It basically lets you fine tune how your code talks 56 00:02:43.360 --> 00:02:45.919 to the underlying system, you know, so you can really 57 00:02:45.960 --> 00:02:46.759 get things humming. 58 00:02:46.840 --> 00:02:50.039 So for tasks that are like really resource intensive, Rust 59 00:02:50.080 --> 00:02:53.400 can give you that extra edge. Exactly interesting, And speaking 60 00:02:53.479 --> 00:02:55.360 of putting all this into practice, the book walks through 61 00:02:55.400 --> 00:02:59.919 this project called cat decks. Yeah, it's this Pokemon inspired 62 00:03:00.120 --> 00:03:02.280 index of like cat breeds. 63 00:03:02.400 --> 00:03:05.280 I love it, Yeah, CatEx. Yeah, it's a super fun 64 00:03:05.319 --> 00:03:07.800 way to show how you can use Rust to build 65 00:03:08.159 --> 00:03:09.280 actual web applications. 66 00:03:09.400 --> 00:03:12.159 Totally, And the book explains how cat x uses server 67 00:03:12.280 --> 00:03:14.800 side rendering with Rust. Now, I'm more familiar with those 68 00:03:14.800 --> 00:03:17.240 like drag and drop website builders, So can you maybe 69 00:03:18.039 --> 00:03:21.639 break down what server side rendering actually is and why 70 00:03:21.680 --> 00:03:22.360 it matters here. 71 00:03:22.479 --> 00:03:25.560 Sure. So in a service side rendered website, basically the 72 00:03:25.599 --> 00:03:29.599 server is dynamically building those HTML pages for each request, right, 73 00:03:29.639 --> 00:03:32.240 so instead of sending like a static file, it's assembling 74 00:03:32.280 --> 00:03:37.080 the page on the fly, pulling in data from like databases, 75 00:03:37.159 --> 00:03:39.599 any user input, and all those other kind of moving parts. 76 00:03:40.199 --> 00:03:43.240 This approach has some real advantages, especially for sites with 77 00:03:43.800 --> 00:03:45.840 a lot of content or complex interactions. 78 00:03:45.960 --> 00:03:47.840 So the server is doing more work upfront, but then 79 00:03:47.879 --> 00:03:51.360 it delivers a fully formed page to the user's browser. 80 00:03:51.039 --> 00:03:53.879 Right exactly. And in the case of cats, imagine the 81 00:03:53.919 --> 00:03:57.039 server grab an info about each cat breed from a database, 82 00:03:57.280 --> 00:04:01.400 plugging that into a predesign htmail template, and then boom, 83 00:04:01.520 --> 00:04:03.199 sending that complete page to the user. 84 00:04:03.439 --> 00:04:05.800 That makes sense, But the book also brings up this 85 00:04:05.840 --> 00:04:09.840 potential issue, right, what happens when that cadex database gets huge, 86 00:04:09.919 --> 00:04:12.879 constantly generating those pages from scratch. It seems like that 87 00:04:12.919 --> 00:04:14.159 could slow things down. 88 00:04:14.080 --> 00:04:16.680 Right, Yeah, you've hit on a key point. If you've 89 00:04:16.720 --> 00:04:19.800 got tons of data and it's changing all the time, 90 00:04:20.360 --> 00:04:25.399 that pure server side rendering approach, it can become a bottleneck. 91 00:04:25.800 --> 00:04:29.439 And that's where the book's discussion of rest APIs with 92 00:04:29.519 --> 00:04:30.160 rust comes in. 93 00:04:30.399 --> 00:04:33.000 Rest APIs Okay, I've heard that term, but I'm still 94 00:04:33.040 --> 00:04:35.160 a little fuzzy on what it actually means. Can you 95 00:04:35.639 --> 00:04:36.680 break that down for us? 96 00:04:36.759 --> 00:04:40.680 For sure? Think of a rest API as this specialized 97 00:04:40.720 --> 00:04:43.399 way for the server and the client, which would be 98 00:04:43.439 --> 00:04:45.920 like the user's web browser to talk to each other. 99 00:04:46.319 --> 00:04:49.000 Instead of sending full blown web pages, the API sends 100 00:04:49.600 --> 00:04:52.120 data like in a structured format. It could be Jason 101 00:04:52.199 --> 00:04:55.240 or xmount, things like that, and then that data can 102 00:04:55.279 --> 00:04:57.319 be used by the client side code, which is usually 103 00:04:57.319 --> 00:05:00.720 the JavaScript, to dynamically build the page right there in 104 00:05:00.720 --> 00:05:01.480 the user's browser. 105 00:05:01.600 --> 00:05:03.720 So it's more like a team effort, right, instead of 106 00:05:03.759 --> 00:05:06.160 this server doing all the work, it's kind of sharing. 107 00:05:05.879 --> 00:05:08.839 The load exactly. The server's like here's the raw data, 108 00:05:09.240 --> 00:05:11.240 and the client side code is like, all right, I'll 109 00:05:11.279 --> 00:05:14.959 assemble and present this. And that can seriously boost performance, 110 00:05:15.040 --> 00:05:19.319 especially for data heavy websites like we were talking about 111 00:05:19.319 --> 00:05:19.839 with cadecs. 112 00:05:20.000 --> 00:05:22.480 That's really clever, but it also seems like you need 113 00:05:22.519 --> 00:05:24.879 to understand like both the server side stuff and the 114 00:05:25.120 --> 00:05:26.959 client side stuff, right, you do. 115 00:05:27.439 --> 00:05:30.319 But the cool thing is that Rust plays really well 116 00:05:30.319 --> 00:05:33.160 with front end technologies like JavaScript. You can build that 117 00:05:33.240 --> 00:05:36.839 API with Rust, serving up data nice and efficiently and 118 00:05:36.879 --> 00:05:40.079 then use whatever JavaScript framework you like to handle all 119 00:05:40.079 --> 00:05:43.600 the client side logic. And like how it looks okay? 120 00:05:43.639 --> 00:05:45.560 So Rust is like the powerful engine on the back 121 00:05:45.680 --> 00:05:48.079 end feeding the data to the front end, where JavaScript 122 00:05:48.160 --> 00:05:50.600 takes over to create the user interface. 123 00:05:50.720 --> 00:05:52.759 Yep, that's a good way to put it now. 124 00:05:53.240 --> 00:05:57.079 The book also mentions using web sockets for real time 125 00:05:57.160 --> 00:05:58.199 two way communication. 126 00:05:58.560 --> 00:06:00.120 Ah, I can see. 127 00:06:00.160 --> 00:06:03.079 That'd be useful for like a live chat feature on 128 00:06:03.120 --> 00:06:04.120 the Cattex site. Right. 129 00:06:04.360 --> 00:06:09.079 Absolutely. Web sockets create this persistent connection between the server 130 00:06:09.160 --> 00:06:11.120 and the client, so you can have that constant back 131 00:06:11.160 --> 00:06:12.879 and forth flow of data. What was up? A ton 132 00:06:12.879 --> 00:06:16.439 of possibilities live chat, you got it, real time notifications, 133 00:06:16.480 --> 00:06:18.519 collaborative editing, all sorts of cool stuff. 134 00:06:18.600 --> 00:06:21.759 Wow, RUSS seems to have like all the bases covered. 135 00:06:21.759 --> 00:06:24.800 But let's be real, managing all these different pieces the server, 136 00:06:25.000 --> 00:06:29.160 the database, the web sockets, it sounds pretty complex. I'm 137 00:06:29.160 --> 00:06:31.920 already getting server management anxiety just thinking about it. 138 00:06:32.040 --> 00:06:34.759 I hear you. It can seem daunting, but that's where 139 00:06:34.800 --> 00:06:38.120 the idea of serverless computing comes in. And hey, guess what. 140 00:06:38.720 --> 00:06:42.279 The Practical Rust Web Projects book actually dives into that too. 141 00:06:42.800 --> 00:06:45.399 Serverless. Wait, you mean I could potentially build this whole 142 00:06:45.439 --> 00:06:48.120 Catdex website without actually managing any servers myself. 143 00:06:48.160 --> 00:06:48.600 You got it. 144 00:06:48.759 --> 00:06:52.759 That sounds amazing, But how does that even work in practice? 145 00:06:52.920 --> 00:06:55.959 In a serverless environment? You focus on writing your apps 146 00:06:56.000 --> 00:07:00.959 logic as functions, and then a cloud provide like AWS. 147 00:07:01.040 --> 00:07:03.600 They handle all the underlying stuff, the servers, the scaling, 148 00:07:03.680 --> 00:07:06.639 load balancing, all that. You basically just deploy your code 149 00:07:06.720 --> 00:07:07.800 and cloud takes care of the rest. 150 00:07:08.000 --> 00:07:09.759 So I can just focus on the code and let 151 00:07:09.759 --> 00:07:12.720 the cloud handle all those infrastructure headache exactly. That's a 152 00:07:12.759 --> 00:07:16.759 game changer. Now, the book mentions using AWS lambda specifically 153 00:07:17.000 --> 00:07:21.000 for serverless rust, is that like a viable approach. 154 00:07:21.120 --> 00:07:24.680 It's not just viable, it's a powerful combo. Awslambda lets 155 00:07:24.720 --> 00:07:28.920 you upload your rust functions and then it automatically runs 156 00:07:28.920 --> 00:07:31.720 them on demand. It scales them up or down based 157 00:07:31.759 --> 00:07:34.040 on traffic, so you don't have to worry about it. Yeah, 158 00:07:34.079 --> 00:07:36.000 and get this. The book even talks about using this 159 00:07:36.040 --> 00:07:38.920 thing called the serverless framework. Okay, it lets you define 160 00:07:38.959 --> 00:07:41.040 your entire infrastructure as code. 161 00:07:41.800 --> 00:07:44.959 Wait, so I could like write code to define my servers, 162 00:07:45.040 --> 00:07:47.920 my database, my whole setup. That's incredible, right. 163 00:07:48.279 --> 00:07:51.959 This approach brings a whole new level of like flexibility 164 00:07:51.959 --> 00:07:55.680 and automation to web development. You can version control your infrastructure, 165 00:07:55.839 --> 00:07:59.360 easily deploy changes, and just like focus on building great 166 00:07:59.360 --> 00:08:02.199 apps without getting bogged down and all that server stuff. 167 00:08:02.360 --> 00:08:05.680 All right, this is officially mind blowing. And to top 168 00:08:05.720 --> 00:08:08.360 it all off, the Rust documentation you sent me talks 169 00:08:08.360 --> 00:08:11.639 about compiling to this thing called web assembly. Apparently it 170 00:08:11.720 --> 00:08:14.759 lets Rust run like right in the browser. Is this 171 00:08:14.879 --> 00:08:15.279 for real? 172 00:08:15.519 --> 00:08:17.560 Oh yeah, web assembly is a real game changer. It 173 00:08:17.639 --> 00:08:21.360 lets languages like Rust run at near native speeds within 174 00:08:21.399 --> 00:08:24.759 web pages. It's opening up possibilities that we just couldn't 175 00:08:24.800 --> 00:08:26.279 do with JavaScript alan before. 176 00:08:26.519 --> 00:08:29.720 So instead of relying solely on JavaScript, we could use 177 00:08:29.800 --> 00:08:34.279 Rust to build these like super high performance parts of 178 00:08:34.320 --> 00:08:37.080 a website that run directly in the browser exactly. 179 00:08:37.159 --> 00:08:40.279 And this is especially exciting for things that need like 180 00:08:40.480 --> 00:08:46.799 crazy performance, think complex calculations, data visualizations, maybe even game development. 181 00:08:46.960 --> 00:08:50.759 The documentation even highlights this Rust powered image recizer that 182 00:08:50.840 --> 00:08:52.200 runs entirely in the browser. 183 00:08:52.440 --> 00:08:54.679 So instead of uploading a huge image and then resizing 184 00:08:54.759 --> 00:08:57.279 it on the server, we could offload that processing to 185 00:08:57.320 --> 00:08:59.360 the user's browser with web assembly. 186 00:08:59.519 --> 00:09:02.360 Exactly, and imagine the possibilities if we combined this with cattex. 187 00:09:02.480 --> 00:09:05.279 Oh yeah, you could resize images on the client side 188 00:09:05.320 --> 00:09:08.799 before they're even uploaded. That would save bandwidth and reduce 189 00:09:08.840 --> 00:09:11.559 the load on the server. Pretty amazing stuff. 190 00:09:11.919 --> 00:09:14.679 This is truly remarkable. I feel like we've only just 191 00:09:14.720 --> 00:09:16.639 scratched the surface of what Rust can do in the 192 00:09:16.639 --> 00:09:20.320 web development world. I'm definitely eager to explore this further. 193 00:09:20.600 --> 00:09:23.279 Yeah, there's a lot to uncover. It seems we've got 194 00:09:23.279 --> 00:09:26.240 you hook on the potential of Rust for web development. 195 00:09:26.639 --> 00:09:29.240 Hooks doesn't even begin to cover it. You mentioned this 196 00:09:29.799 --> 00:09:32.759 web assembly image recizer and the documentation says it can 197 00:09:32.799 --> 00:09:36.399 reach near native speeds. Is that level of performance really 198 00:09:36.480 --> 00:09:38.159 possible inside a web browser? 199 00:09:38.200 --> 00:09:40.879 Oh, it's not just hype. Web assembly really is a 200 00:09:40.919 --> 00:09:44.159 game changer when it comes to web performance. By compiling 201 00:09:44.240 --> 00:09:48.080 languages like Rust to this like low level bycode, we 202 00:09:48.159 --> 00:09:50.879 can really tap into the power of the user's hardware. 203 00:09:51.080 --> 00:09:54.679 So we're basically like bypassing some of those limitations of 204 00:09:54.759 --> 00:09:58.840 JavaScript and getting a more direct line to the browser's capabilities. 205 00:09:59.080 --> 00:10:01.200 That's a great way to put it. Web assembly lets 206 00:10:01.279 --> 00:10:03.759 us build web apps with performance that used to only 207 00:10:03.799 --> 00:10:08.080 be possible with like native desktop applications, and that has 208 00:10:08.200 --> 00:10:13.480 huge implications for well pretty much everything, complex visualizations, immersive games, 209 00:10:13.519 --> 00:10:14.039 you name it. 210 00:10:14.080 --> 00:10:16.519 This opens up a whole new world. But is web 211 00:10:16.519 --> 00:10:20.039 assembly limited to just those smaller kind of self contained 212 00:10:20.080 --> 00:10:23.960 modules like the image recizer example. Could we build entire 213 00:10:24.000 --> 00:10:26.360 web applications using Rust and web assembly. 214 00:10:26.440 --> 00:10:29.279 Now that's where things get really exciting. We're already seeing 215 00:10:29.279 --> 00:10:32.679 frameworks like You pop up and they let developers build 216 00:10:32.879 --> 00:10:36.879 entire front end applications with Rust and web assembly. Really yeah, 217 00:10:37.120 --> 00:10:40.879 You is heavily inspired by those popular JavaScript frameworks like React, 218 00:10:41.279 --> 00:10:44.399 but it brings all those Rust benefits, the safety, the performance, 219 00:10:44.440 --> 00:10:46.240 the reliability right to the front end. 220 00:10:46.360 --> 00:10:49.120 So instead of JavaScript handling the user interface, we could 221 00:10:49.159 --> 00:10:52.080 have Rust powering both the service side logic and the 222 00:10:52.759 --> 00:10:54.480 client side interaction exactly. 223 00:10:54.519 --> 00:10:58.039 And with Rust's focus on memory safety and predictable behavior, 224 00:10:58.440 --> 00:11:01.080 we can create web applications that are not only super fast, 225 00:11:01.240 --> 00:11:03.960 but also really stable and much less likely to crash. 226 00:11:04.240 --> 00:11:07.240 This is like changing the whole game. It really flips 227 00:11:07.320 --> 00:11:10.039 the traditional way we think about web development on its head. 228 00:11:10.840 --> 00:11:14.039 Now I want to circle back to that Practical Rust 229 00:11:14.080 --> 00:11:17.360 Web Projects book and the catdex example for a minute, 230 00:11:17.559 --> 00:11:21.320 the book explains how to build a server side rendered website. 231 00:11:22.519 --> 00:11:25.200 What are some of the key steps in setting up 232 00:11:25.200 --> 00:11:26.799 a site like that with rust? 233 00:11:27.279 --> 00:11:29.840 Well, the book used this framework called actis Web, which 234 00:11:29.879 --> 00:11:33.240 is known for being like really fast and flexible. So 235 00:11:33.279 --> 00:11:35.840 the first thing is defining the structure of your application, 236 00:11:36.559 --> 00:11:38.919 like creating the blueprints. You know, you set up roots 237 00:11:39.039 --> 00:11:43.159 to handle incoming requests. You define handlers which contain the 238 00:11:43.200 --> 00:11:46.080 logic to process those requests and send back responses that 239 00:11:46.159 --> 00:11:46.559 kind of thing. 240 00:11:46.600 --> 00:11:48.360 So it's like mapping out all the different parts of 241 00:11:48.360 --> 00:11:51.879 your website and defining how each section will respond to 242 00:11:51.919 --> 00:11:53.399 what the user does exactly. 243 00:11:53.440 --> 00:11:55.919 You're basically creating a roadmap for how your web application 244 00:11:55.960 --> 00:11:59.200 will function. Then the book gets into using handlebars, which 245 00:11:59.200 --> 00:12:03.039 is a templting engine. It lets you embed dynamic content 246 00:12:03.120 --> 00:12:05.519 within your HTML files. This is where you start pulling 247 00:12:05.519 --> 00:12:09.039 in data from databases and other sources to make those 248 00:12:09.080 --> 00:12:09.919 pages dynamic. 249 00:12:10.120 --> 00:12:13.399 So instead of having static HTML files, we're using these 250 00:12:13.440 --> 00:12:16.440 templates that can be filled in with real time data, 251 00:12:16.440 --> 00:12:19.919 making the website more interactive and engaging. 252 00:12:20.200 --> 00:12:23.799 Exactly. Handlebars is a great way to separate the structure 253 00:12:23.840 --> 00:12:26.919 of your HTML from the dynamic content, which keeps your 254 00:12:26.919 --> 00:12:30.320 code cleaner and easier to maintain. Of course, you can't 255 00:12:30.320 --> 00:12:33.720 have a web application without a database. The Kadex project 256 00:12:33.799 --> 00:12:37.440 uses Diesel, which is a really robust ARM that stands 257 00:12:37.480 --> 00:12:40.480 or object relational mapper, and it basically makes it way 258 00:12:40.519 --> 00:12:42.320 easier to work with databases and Rust. 259 00:12:42.799 --> 00:12:46.039 Ah Diesel, I remember reading about that, but if I'm 260 00:12:46.039 --> 00:12:49.039 being honest, databases still kind of intimidate me. It feels 261 00:12:49.080 --> 00:12:50.559 like a whole other world to learn. 262 00:12:50.840 --> 00:12:53.960 I get it. Databases can be complex, but that's exactly 263 00:12:54.000 --> 00:12:56.120 why Diesel is so great. It lets you interact with 264 00:12:56.159 --> 00:12:59.240 your database using familiar Rust syntax. It handles a lot 265 00:12:59.240 --> 00:13:01.600 of the complexity of writing raw SQL queries for you. 266 00:13:02.039 --> 00:13:04.679 So what it's like having a translator that speaks both 267 00:13:04.759 --> 00:13:07.759 Rust and SQL, making it easier for my application to 268 00:13:07.799 --> 00:13:08.759 talk to the database. 269 00:13:09.039 --> 00:13:13.120 Perfect analogy. Diesel streamlines the whole process of working with 270 00:13:13.200 --> 00:13:16.679 databases in Rust, making it much more approachable even for 271 00:13:16.759 --> 00:13:18.919 developers who aren't database gurus. 272 00:13:19.159 --> 00:13:22.799 That's a relief. Now. The book mentions using Docker to 273 00:13:22.840 --> 00:13:26.159 set up a Postgres school database. I've heard of Docker, 274 00:13:26.200 --> 00:13:28.440 but can you give me like a quick explanation of 275 00:13:28.480 --> 00:13:30.080 what it is and why we need it here. 276 00:13:30.399 --> 00:13:34.399 Docker is awesome for creating containerized environments. Think of a 277 00:13:34.440 --> 00:13:38.639 container as like a lightweight, self contained package. It's got 278 00:13:38.679 --> 00:13:42.440 everything your application needs to run, the code, libraries, dependencies, 279 00:13:42.559 --> 00:13:45.360 even the operating system. Oh wow. In the cattext project, 280 00:13:45.360 --> 00:13:48.000 you use Docker to spin up a postgrescool database instance 281 00:13:48.399 --> 00:13:50.480 really quickly and easily. You don't have to go through 282 00:13:50.480 --> 00:13:53.600 all the hassle of installing and configuring it manually on 283 00:13:53.600 --> 00:13:54.320 your own system. 284 00:13:54.440 --> 00:13:57.279 So it's like having a pre built, portable environment that 285 00:13:57.320 --> 00:13:59.440 I can use to run my database exactly. 286 00:13:59.720 --> 00:14:02.559 Doctor makes setting up and managing the infrastructure for your 287 00:14:02.600 --> 00:14:04.519 web application a breeze. 288 00:14:04.639 --> 00:14:07.200 All right, back to Diesel. How does it actually handle 289 00:14:07.200 --> 00:14:10.559 the connection to the database. I imagine managing those connections 290 00:14:10.559 --> 00:14:12.759 efficiently is really important for performance. 291 00:14:12.840 --> 00:14:15.639 Right, You're right it is. Diesel uses something called a 292 00:14:15.679 --> 00:14:18.879 connection pool, which is basically a bunch of pre established 293 00:14:18.919 --> 00:14:22.279 connections to the database. So when your application needs to 294 00:14:22.399 --> 00:14:26.159 run a query, it borrows a connection from the pool, 295 00:14:26.840 --> 00:14:28.919 uses it, and then puts it back when it's done. 296 00:14:29.000 --> 00:14:29.320 Okay. 297 00:14:29.440 --> 00:14:32.600 This avoids the overhead of creating a brand new connection 298 00:14:32.679 --> 00:14:35.279 for each request, which can really bog things down. 299 00:14:35.759 --> 00:14:37.960 So it's like having a dedicated lane at a toll booth, 300 00:14:37.960 --> 00:14:39.399 so we don't have to wait in line every time 301 00:14:39.399 --> 00:14:40.639 we need to get to the database. 302 00:14:40.720 --> 00:14:43.559 Uh huh. I like that the connection pool keeps things 303 00:14:43.600 --> 00:14:47.240 flowing smoothly. Now, earlier we were talking about how concurrency 304 00:14:47.320 --> 00:14:50.639 is one of Russ's big strengths. Right, I'm curious how 305 00:14:50.679 --> 00:14:55.159 does Diesel handle concurrent database access? Wouldn't be a problem 306 00:14:55.320 --> 00:14:58.159 if multiple threads were all trying to use the database 307 00:14:58.200 --> 00:14:58.960 at the same time. 308 00:15:00.120 --> 00:15:03.159 Rate question, and it highlights a key thing about databases. 309 00:15:03.639 --> 00:15:07.799 By default, Diesel uses synchronous IO for database operations, so 310 00:15:07.879 --> 00:15:11.799 each database request will block the thread until it's finished. Now, 311 00:15:11.799 --> 00:15:14.360 that might seem like a limitation in a concurrent environment, 312 00:15:14.399 --> 00:15:17.240 but Rust provides a solution with this feature called web 313 00:15:17.279 --> 00:15:19.559 dot bloc weblock. What does that do? 314 00:15:19.799 --> 00:15:23.559 Webb block lets you move blocking operations like database queries 315 00:15:23.840 --> 00:15:26.399 off to a separate threadpool so they don't hold up 316 00:15:26.399 --> 00:15:29.039 the main thread, which needs to be free to handle 317 00:15:29.080 --> 00:15:32.159 incoming requests and keep your web application responsive. 318 00:15:32.799 --> 00:15:35.440 So it's like having a dedicated team of workers handling 319 00:15:35.440 --> 00:15:38.519 the database tasks while the main team focuses on serving 320 00:15:38.559 --> 00:15:40.440 those Web requests exactly. 321 00:15:40.639 --> 00:15:44.000 Web byblock helps you harness the power of concurrency without 322 00:15:44.080 --> 00:15:47.240 sacrificing the responsiveness of your app. It really shows how 323 00:15:47.320 --> 00:15:51.200 Rust lets developers write code that is both efficient and safe, 324 00:15:51.600 --> 00:15:54.320 even when dealing with tricky stuff like database interactions. 325 00:15:54.399 --> 00:15:57.200 This is all so fascinating. It's amazing to see how 326 00:15:57.240 --> 00:16:00.639 all these pieces fit together. The framework, the splitting engine, 327 00:16:00.679 --> 00:16:04.440 the arm, and Rust's concurrency features. They all come together 328 00:16:04.519 --> 00:16:08.080 to create this powerful and efficient web development ecosystem. 329 00:16:08.240 --> 00:16:11.039 It really is a testament to how thoughtfully Rust and 330 00:16:11.120 --> 00:16:13.080 its whole ecosystem have been designed. 331 00:16:13.320 --> 00:16:16.039 But let's be real, building a website isn't just about 332 00:16:16.039 --> 00:16:19.919 showing static content. We want users to actually interact with it, 333 00:16:20.120 --> 00:16:24.840 submit data, have those dynamic experiences. How does Rust handle 334 00:16:24.879 --> 00:16:26.960 things like forms and user input. 335 00:16:27.360 --> 00:16:30.519 Well, the cattex project actually demonstrates this. It builds a 336 00:16:30.559 --> 00:16:33.840 form for adding newcats to the database. It shows how 337 00:16:33.840 --> 00:16:38.360 to handle HTTP post requests, process the data from the form, 338 00:16:38.600 --> 00:16:41.559 and then interact with the database to store that new information. 339 00:16:42.039 --> 00:16:44.320 So it's like creating a conversation between the user and 340 00:16:44.360 --> 00:16:47.759 the application. The user provides input and then the application 341 00:16:47.840 --> 00:16:50.519 response by updating the database and maybe showing some feedback 342 00:16:50.600 --> 00:16:51.480 or updated content. 343 00:16:51.720 --> 00:16:54.919 You got it. Handling forms and user input is essential 344 00:16:54.919 --> 00:16:57.320 for web development, and Rust has all the tools and 345 00:16:57.399 --> 00:17:00.399 libraries you need to do it securely and efficiently. You 346 00:17:00.399 --> 00:17:04.519 can validate user input, sanitize data to prevent security problems, 347 00:17:04.720 --> 00:17:07.839 and provide clear error messages if things go wrong. It's 348 00:17:07.880 --> 00:17:11.000 all about making a smooth and reliable experience for the user. 349 00:17:11.079 --> 00:17:12.720 This is all starting to click for me. I'm actually 350 00:17:12.759 --> 00:17:14.759 feeling like I could build a website using Rust. 351 00:17:15.079 --> 00:17:18.160 I think you absolutely could, and remember that Practical Rust 352 00:17:18.200 --> 00:17:20.599 Web Projects book is there to guide you every step 353 00:17:20.599 --> 00:17:23.160 of the way. Right. The great thing about Rust is 354 00:17:23.200 --> 00:17:25.759 that its strong type system and the compiler are like 355 00:17:25.759 --> 00:17:29.119 your partners in crime. They'll catch errors early on and 356 00:17:29.200 --> 00:17:31.880 help you write really solid, dependable. 357 00:17:31.319 --> 00:17:36.000 Code that's encouraging to hear. Now, speaking of real world applications, 358 00:17:36.160 --> 00:17:39.359 let's talk about image uploads. I can't imagine cat des 359 00:17:39.400 --> 00:17:41.400 without a way to show off pictures of all these 360 00:17:41.440 --> 00:17:44.839 adorable cats. How does Rust handle file uploads? 361 00:17:45.240 --> 00:17:47.759 The cat dex project covers that too, yea. It shows 362 00:17:47.799 --> 00:17:50.599 how to handle file uploads using multipart form data, which 363 00:17:50.640 --> 00:17:52.559 is a standard way of sending files over the web. 364 00:17:53.200 --> 00:17:56.559 You can receive those cat picks from users, process them 365 00:17:56.559 --> 00:17:59.039 in your RUST code, and then store them either on 366 00:17:59.079 --> 00:18:02.000 the servers, file says, or a cloud storage service like 367 00:18:02.119 --> 00:18:03.119 AWSS three. 368 00:18:03.200 --> 00:18:05.359 So it's like adding a virtual photo album to the 369 00:18:05.359 --> 00:18:09.200 Catdex website where users can share their own cat photos Precisely. 370 00:18:09.960 --> 00:18:13.680 Handling file uploads opens up so many possibilities for building rich, 371 00:18:13.880 --> 00:18:18.119 interactive web applications, and because RUSS focuses on safety and 372 00:18:18.279 --> 00:18:21.200 error handling, you can be sure that the process is 373 00:18:21.359 --> 00:18:25.680 robust and secure, protecting your application from potential vulnerabilities. 374 00:18:26.200 --> 00:18:28.799 This is incredibly impressive. We've covered a lot, from the 375 00:18:28.799 --> 00:18:32.720 basics of server side rendering to the details of database interactions, 376 00:18:32.799 --> 00:18:36.480 form handling, and even file uploads. It's amazing to see 377 00:18:36.480 --> 00:18:39.640 how seamlessly Rust brings all these pieces together into a 378 00:18:39.680 --> 00:18:41.400 complete web development ecosystem. 379 00:18:41.559 --> 00:18:44.400 And we're not done yet. There's still so much to explore, 380 00:18:44.759 --> 00:18:47.000 like the ins and outs of deployment, how to handle 381 00:18:47.119 --> 00:18:50.319 errors effectively, and the overall impact Rust is having on 382 00:18:50.359 --> 00:18:51.559 the future of web development. 383 00:18:51.640 --> 00:18:53.920 I can't wait to dive deeper, but for now, I 384 00:18:53.920 --> 00:18:55.920 think we need a moment to let all this sink in. 385 00:18:56.240 --> 00:18:58.559 Yes, there's definitely a lot to process. We'll pick up 386 00:18:58.599 --> 00:18:59.599 our explorations soon. 387 00:19:00.000 --> 00:19:02.720 Okay, so I think I'm caught up. Last week left off, 388 00:19:02.759 --> 00:19:07.400 we were talking about image uploads for our Imaginary Catdex website, 389 00:19:07.680 --> 00:19:10.160 and the book mentions how important it is to handle 390 00:19:10.160 --> 00:19:13.759 those uploads, you know, securely. Makes sense, especially when you're 391 00:19:13.759 --> 00:19:17.359 dealing with stuff that users are sending in. 392 00:19:17.559 --> 00:19:22.240 Oh. Absolutely, security is like the top priority, especially with 393 00:19:22.319 --> 00:19:24.920 user generated content, right. You always have to be on 394 00:19:25.000 --> 00:19:28.759 lookout for those those sneaky uploads that could, you know, 395 00:19:28.799 --> 00:19:31.960 try to exploit weaknesses in your app or like mess 396 00:19:32.000 --> 00:19:32.519 with your server. 397 00:19:32.680 --> 00:19:34.559 Yeah, so it's not just about making sure those cat 398 00:19:34.559 --> 00:19:36.319 picks are cute. We also got to make sure they're 399 00:19:36.319 --> 00:19:39.599 not like hiding any digital viruses or something exactly. 400 00:19:39.640 --> 00:19:42.799 You got to be really careful about validating file types, 401 00:19:43.200 --> 00:19:48.240