WEBVTT

1
00:00:00.040 --> 00:00:03.799
<v Speaker 1>All right, diving into Rust for web development.

2
00:00:03.399 --> 00:00:05.080
<v Speaker 2>That's a that's a great choice.

3
00:00:05.160 --> 00:00:08.320
<v Speaker 1>It's known for its speed and security, right yeah. Yeah,

4
00:00:08.359 --> 00:00:09.880
<v Speaker 1>And to help us kind of break it all down,

5
00:00:10.080 --> 00:00:14.679
<v Speaker 1>we have excerpts from Rust Web Programming, a hands on

6
00:00:14.800 --> 00:00:19.000
<v Speaker 1>guide Excellent. I'm excited to unpack this. It's a good one,

7
00:00:19.120 --> 00:00:23.160
<v Speaker 1>I think so. Yeah, So Rust is gaining traction, it is.

8
00:00:23.239 --> 00:00:26.320
<v Speaker 1>It is, especially for those high performance web apps for sure.

9
00:00:26.519 --> 00:00:27.320
<v Speaker 2>For sure, it kind of.

10
00:00:27.280 --> 00:00:30.239
<v Speaker 1>Bridges the gap, you know, between that low level control

11
00:00:30.839 --> 00:00:33.960
<v Speaker 1>and high level abstraction. Absolutely, so it seems like this

12
00:00:34.000 --> 00:00:35.960
<v Speaker 1>book is a perfect starting point.

13
00:00:36.280 --> 00:00:38.039
<v Speaker 2>I think so too, especially for.

14
00:00:38.000 --> 00:00:40.880
<v Speaker 1>Those who may have some background and web development already.

15
00:00:41.039 --> 00:00:44.640
<v Speaker 2>Yeah, if you've got HTML, CSS, JavaScript out of your belt,

16
00:00:44.719 --> 00:00:46.159
<v Speaker 2>you're you're going to be in a good spot.

17
00:00:46.320 --> 00:00:49.000
<v Speaker 1>Like the usual suspects for sure. But it also delves

18
00:00:49.039 --> 00:00:51.880
<v Speaker 1>into deploying on AWS, yeah, which I think is a

19
00:00:52.079 --> 00:00:54.759
<v Speaker 1>major win absolutely for practical experience.

20
00:00:54.840 --> 00:00:56.479
<v Speaker 2>You gotta get that real world story. Yeah.

21
00:00:56.520 --> 00:00:59.240
<v Speaker 1>So there's a lot to unpack, there is, But we

22
00:00:59.280 --> 00:01:02.280
<v Speaker 1>can't forget about those core Rust concepts like.

23
00:01:02.320 --> 00:01:05.879
<v Speaker 2>Yeah, like data types, memory management, or handling, right, and

24
00:01:06.239 --> 00:01:08.680
<v Speaker 2>these can be stumbling blocks, especially if you're coming from

25
00:01:08.719 --> 00:01:11.319
<v Speaker 2>a language like Python or JavaScript. Oh for sure, you

26
00:01:11.359 --> 00:01:12.920
<v Speaker 2>know where things are maybe a little bit.

27
00:01:12.799 --> 00:01:17.200
<v Speaker 1>Looser, yeah, a little more forgiving exactly. So how Rust

28
00:01:17.319 --> 00:01:20.239
<v Speaker 1>handles things differently is one of the first things that

29
00:01:20.280 --> 00:01:24.519
<v Speaker 1>grab my attention. Okay, strong typing. This concept of ownership

30
00:01:24.519 --> 00:01:28.400
<v Speaker 1>of variables and memory management without a garbage collector, right,

31
00:01:28.439 --> 00:01:29.560
<v Speaker 1>that's a lot to process.

32
00:01:29.959 --> 00:01:31.480
<v Speaker 2>It is, It is a lot to process, and that's

33
00:01:31.799 --> 00:01:36.480
<v Speaker 2>that's what makes us so unique. This, this ownership system

34
00:01:36.480 --> 00:01:41.120
<v Speaker 2>in particular, is key to Rust's memory safety. Okay, without

35
00:01:41.200 --> 00:01:44.959
<v Speaker 2>needing that garbage collector. Interesting, Yeah, so think of it

36
00:01:45.000 --> 00:01:47.719
<v Speaker 2>this way. Every piece of data in Rust has a

37
00:01:47.760 --> 00:01:50.719
<v Speaker 2>designated owner, and when that owner is no longer needed,

38
00:01:51.400 --> 00:01:54.599
<v Speaker 2>the data is automatically cleaned up. No more memory leaks

39
00:01:54.680 --> 00:01:56.400
<v Speaker 2>or those pesky dangling pointers.

40
00:01:56.640 --> 00:02:00.519
<v Speaker 1>It's like having a built in cleanup crew your code.

41
00:02:00.599 --> 00:02:01.599
<v Speaker 2>That's a great way to put it.

42
00:02:01.560 --> 00:02:04.959
<v Speaker 1>Always making sure things are tidy, yeah and efficient.

43
00:02:04.560 --> 00:02:05.840
<v Speaker 2>Keep everything nice and clean.

44
00:02:06.879 --> 00:02:10.400
<v Speaker 1>But how does that play out in a real world scenario?

45
00:02:10.680 --> 00:02:14.280
<v Speaker 2>Okay, so let's take strings as an example. On page sixteen,

46
00:02:15.400 --> 00:02:19.360
<v Speaker 2>the book shows how a string is created and assigned

47
00:02:19.360 --> 00:02:22.680
<v Speaker 2>to a variable, making that variable the owner. Then if

48
00:02:22.719 --> 00:02:26.120
<v Speaker 2>you pass that string to a function, ownership is transferred.

49
00:02:26.759 --> 00:02:30.719
<v Speaker 2>You're essentially handing over responsibility, gotcha, for that piece of data.

50
00:02:30.960 --> 00:02:35.520
<v Speaker 2>And this prevents situations where multiple parts of your code

51
00:02:35.639 --> 00:02:39.080
<v Speaker 2>might try to modify the same data simultaneously.

52
00:02:38.840 --> 00:02:40.120
<v Speaker 1>Which would cause chaos.

53
00:02:40.439 --> 00:02:41.919
<v Speaker 2>Yeah, it can lead to all sorts of problems.

54
00:02:41.960 --> 00:02:45.120
<v Speaker 1>So it's like having a clear chain of command for

55
00:02:45.319 --> 00:02:48.319
<v Speaker 1>your data absolutely, so everyone knows who's in charge exactly.

56
00:02:48.360 --> 00:02:51.759
<v Speaker 2>And it's visually represented in that diagram on page sixteen

57
00:02:52.159 --> 00:02:54.719
<v Speaker 2>showing the strings relationship to strains, So it really helps

58
00:02:54.759 --> 00:02:56.280
<v Speaker 2>to see it laid out like that.

59
00:02:56.319 --> 00:02:59.599
<v Speaker 1>Definitely, now onto something that always makes me a bit nervous,

60
00:03:00.199 --> 00:03:00.919
<v Speaker 1>error handling.

61
00:03:01.080 --> 00:03:01.719
<v Speaker 2>Oh yeah.

62
00:03:01.840 --> 00:03:05.120
<v Speaker 1>It seems that Rust takes a very unique approach, as

63
00:03:05.159 --> 00:03:08.080
<v Speaker 1>it does with these things called options and results. Oh right,

64
00:03:08.319 --> 00:03:09.879
<v Speaker 1>It kind of sounds a little intimidating.

65
00:03:10.000 --> 00:03:12.120
<v Speaker 2>They do. They do sound a little intimidating at first,

66
00:03:12.599 --> 00:03:18.039
<v Speaker 2>but options and results are Rust's way of forcing you

67
00:03:18.120 --> 00:03:22.479
<v Speaker 2>to confront those potential errors head on, okay, like, really

68
00:03:22.479 --> 00:03:25.159
<v Speaker 2>think about what could go wrong, gotcha. The book uses

69
00:03:25.199 --> 00:03:28.120
<v Speaker 2>a great example on page ten with a hash mat. Okay,

70
00:03:28.199 --> 00:03:33.280
<v Speaker 2>when you try to retrieve a value using a key

71
00:03:33.400 --> 00:03:36.520
<v Speaker 2>that the key might not exist and So instead of

72
00:03:36.560 --> 00:03:40.120
<v Speaker 2>just like returning the value, which could lead to unexpected crashes,

73
00:03:40.479 --> 00:03:41.680
<v Speaker 2>Rust returns an option.

74
00:03:42.439 --> 00:03:45.520
<v Speaker 1>So it's like Rust is saying, hey, be prepared, Yeah,

75
00:03:45.599 --> 00:03:47.520
<v Speaker 1>this might not work out as plans, exactly.

76
00:03:47.560 --> 00:03:49.240
<v Speaker 2>It's a bit more upfront than other.

77
00:03:49.199 --> 00:03:51.960
<v Speaker 1>Languages that kind of let you get away with ignoring

78
00:03:52.000 --> 00:03:53.159
<v Speaker 1>those potential errors.

79
00:03:53.280 --> 00:03:55.120
<v Speaker 2>Right. In those other languages, you can just kind of

80
00:03:55.159 --> 00:03:57.639
<v Speaker 2>like cross your fingers and hope for the best.

81
00:03:57.759 --> 00:03:58.840
<v Speaker 1>Yeah, hope it works.

82
00:03:58.960 --> 00:04:01.759
<v Speaker 2>But Rust is like, nope, let's deal with this right now.

83
00:04:01.840 --> 00:04:02.919
<v Speaker 1>Yeah, let's be explicit.

84
00:04:03.039 --> 00:04:03.240
<v Speaker 2>Yeah.

85
00:04:03.280 --> 00:04:06.759
<v Speaker 1>So that option acts like a container. It either holds

86
00:04:06.759 --> 00:04:10.680
<v Speaker 1>the value you're looking for, or it indicates that it's empty, exact,

87
00:04:10.759 --> 00:04:14.080
<v Speaker 1>and you have to explicitly check and unwrap it to

88
00:04:14.280 --> 00:04:15.280
<v Speaker 1>access that value.

89
00:04:15.560 --> 00:04:18.920
<v Speaker 2>Yep, And that prevents those nasty runtime surprises.

90
00:04:18.959 --> 00:04:20.399
<v Speaker 1>So you're not getting this, like you said.

91
00:04:20.279 --> 00:04:22.160
<v Speaker 2>Crashes exactly, No, no crashes.

92
00:04:22.240 --> 00:04:25.000
<v Speaker 1>Later on down the line, I'm starting to see how

93
00:04:25.000 --> 00:04:31.279
<v Speaker 1>this emphasis on explicit error handling can lead to more

94
00:04:31.360 --> 00:04:32.800
<v Speaker 1>robust code in the long run.

95
00:04:32.959 --> 00:04:35.680
<v Speaker 2>Absolutely, it's like building a safety net, yeah, into your

96
00:04:35.720 --> 00:04:37.040
<v Speaker 2>program from the ground up.

97
00:04:37.160 --> 00:04:40.519
<v Speaker 1>Okay, great, now onto structs and treats. I have to

98
00:04:40.560 --> 00:04:43.120
<v Speaker 1>admit those names sound a little intimidating a little bit.

99
00:04:43.199 --> 00:04:45.800
<v Speaker 2>Yeah they sound a little scary, yeah, but they're actually

100
00:04:45.800 --> 00:04:46.680
<v Speaker 2>pretty straightforward.

101
00:04:46.839 --> 00:04:47.160
<v Speaker 1>Okay.

102
00:04:47.480 --> 00:04:51.600
<v Speaker 2>So think of structs as blueprints, okay for your data.

103
00:04:52.279 --> 00:04:54.720
<v Speaker 2>They let you define the structure of the information you're

104
00:04:54.720 --> 00:04:55.240
<v Speaker 2>working with.

105
00:04:55.480 --> 00:04:56.120
<v Speaker 1>Gotcha.

106
00:04:56.279 --> 00:04:58.639
<v Speaker 2>Traits, on the other hand, are like contracts.

107
00:04:58.800 --> 00:04:59.120
<v Speaker 1>Okay.

108
00:04:59.240 --> 00:05:02.319
<v Speaker 2>They define be behavior that different structs can share.

109
00:05:02.920 --> 00:05:06.079
<v Speaker 1>So if you have a struct that represents a user, okay,

110
00:05:06.199 --> 00:05:08.839
<v Speaker 1>you can have a trait that defines how to authenticate

111
00:05:08.879 --> 00:05:11.879
<v Speaker 1>that user right exactly, okay, and any other struct that

112
00:05:11.920 --> 00:05:17.199
<v Speaker 1>wants to handle authentication would need to implement that trait exactly.

113
00:05:17.319 --> 00:05:21.439
<v Speaker 2>Yeah. And that's how you ensure consistency, yeah, across your code.

114
00:05:21.480 --> 00:05:21.839
<v Speaker 1>Gotcha.

115
00:05:21.959 --> 00:05:25.160
<v Speaker 2>So the book illustrates this concept nicely on pages twenty eight,

116
00:05:25.319 --> 00:05:28.439
<v Speaker 2>thirty and fifty one with the coordinates struct and traits

117
00:05:28.480 --> 00:05:31.120
<v Speaker 2>like get to delete and edit. Cool, and it shows

118
00:05:31.120 --> 00:05:34.199
<v Speaker 2>you how you can add specific functionality to a struck,

119
00:05:34.720 --> 00:05:37.439
<v Speaker 2>making your code more modular and easier to maintain.

120
00:05:37.519 --> 00:05:40.600
<v Speaker 1>So it's about those building blocks, creating those reusable components

121
00:05:40.639 --> 00:05:44.000
<v Speaker 1>that you can mix and match to create more complex functionality.

122
00:05:44.160 --> 00:05:44.600
<v Speaker 2>Exactly.

123
00:05:45.160 --> 00:05:50.240
<v Speaker 1>Awesome. So, speaking of toolboxes, okay, we can't forget about Cargo.

124
00:05:50.279 --> 00:05:52.959
<v Speaker 2>Of course not. Cargo's the best rusts.

125
00:05:52.680 --> 00:05:54.680
<v Speaker 1>Build system and package manager.

126
00:05:55.040 --> 00:05:55.279
<v Speaker 2>Right.

127
00:05:55.560 --> 00:05:59.480
<v Speaker 1>It's like having a personal assistant for your rest projects. Yeah,

128
00:05:59.800 --> 00:06:03.480
<v Speaker 1>it seems like Cargo handles everything. It pretty much does,

129
00:06:03.600 --> 00:06:10.160
<v Speaker 1>from managing dependencies, building your code, running tests, generating documentation.

130
00:06:10.879 --> 00:06:12.319
<v Speaker 2>It's like the Swiss army knife.

131
00:06:12.319 --> 00:06:14.279
<v Speaker 1>It is a Swiss army knife.

132
00:06:13.920 --> 00:06:14.759
<v Speaker 2>Of Rust develops.

133
00:06:15.000 --> 00:06:18.920
<v Speaker 1>You don't have to manually download and install libraries, worry

134
00:06:18.920 --> 00:06:22.639
<v Speaker 1>about compatibility issues, any of that headache inducing stuff.

135
00:06:22.680 --> 00:06:23.079
<v Speaker 2>None of that.

136
00:06:23.480 --> 00:06:25.240
<v Speaker 1>Cargo just handles it all for you.

137
00:06:25.560 --> 00:06:26.759
<v Speaker 2>Yep, it just takes care of it.

138
00:06:27.240 --> 00:06:30.000
<v Speaker 1>Now, let's move on to web frameworks. Okay, the book

139
00:06:30.040 --> 00:06:33.399
<v Speaker 1>focuses on Actics Web, known for its speed.

140
00:06:34.199 --> 00:06:35.199
<v Speaker 2>It is blazing fast.

141
00:06:35.240 --> 00:06:36.800
<v Speaker 1>What makes it so fast, so.

142
00:06:36.800 --> 00:06:43.120
<v Speaker 2>Actis Web leverages Rust's asynchronous capabilities. It uses async programming,

143
00:06:43.639 --> 00:06:46.879
<v Speaker 2>which essentially allows your web app to juggle multiple tasks

144
00:06:47.040 --> 00:06:50.959
<v Speaker 2>concurrently without getting bogged down by waiting. Think of it

145
00:06:51.000 --> 00:06:53.839
<v Speaker 2>like a chef who can prep ingredients for one dish

146
00:06:54.560 --> 00:06:56.079
<v Speaker 2>while another is simmering on the stove.

147
00:06:56.639 --> 00:06:59.480
<v Speaker 1>So instead of waiting for one task to finish before

148
00:06:59.519 --> 00:07:02.360
<v Speaker 1>moving on to the next, exactly, it can keep things moving.

149
00:07:02.439 --> 00:07:04.519
<v Speaker 2>Yep, keep everything flow and smoothly.

150
00:07:04.240 --> 00:07:06.240
<v Speaker 1>Making it much more efficient and responsive.

151
00:07:06.360 --> 00:07:07.600
<v Speaker 2>It's all about that efficiency.

152
00:07:07.959 --> 00:07:11.839
<v Speaker 1>So Rust has built in support for this asynchronous programming

153
00:07:11.920 --> 00:07:15.279
<v Speaker 1>it does, which Actic's Web expertly uses right out of

154
00:07:15.279 --> 00:07:17.759
<v Speaker 1>the box. The book breaks down the structure of an

155
00:07:17.759 --> 00:07:20.879
<v Speaker 1>Actic's web app on page eighty six, Yeah, showing how

156
00:07:21.279 --> 00:07:26.839
<v Speaker 1>views are modularized for different functionalities like authentication or handling

157
00:07:27.279 --> 00:07:28.839
<v Speaker 1>specific data items.

158
00:07:28.959 --> 00:07:31.120
<v Speaker 2>Yeah, it's all about keeping your code nice and organized.

159
00:07:31.160 --> 00:07:34.279
<v Speaker 1>Yeah, it's all about organization and keeping your code clean exactly.

160
00:07:34.360 --> 00:07:37.000
<v Speaker 1>And then we have routes which we see defined on

161
00:07:37.079 --> 00:07:39.720
<v Speaker 1>pages ninety eight and one oh two. Yeah, and these

162
00:07:39.759 --> 00:07:41.680
<v Speaker 1>are like the signposts of your web app.

163
00:07:41.759 --> 00:07:44.680
<v Speaker 2>Yeah, think like the roadmap for your application.

164
00:07:45.040 --> 00:07:49.000
<v Speaker 1>So they direct incoming requests to the appropriate views based.

165
00:07:48.680 --> 00:07:51.879
<v Speaker 2>On the URL exactly. So somebody goes to you know,

166
00:07:52.000 --> 00:07:54.680
<v Speaker 2>slash log in, yeah, it knows to send them to

167
00:07:54.680 --> 00:07:56.480
<v Speaker 2>the log in view. Perfect, things like that.

168
00:07:57.160 --> 00:08:00.519
<v Speaker 1>Speaking of data, I see that actics Web uses Jason

169
00:08:00.800 --> 00:08:02.560
<v Speaker 1>extensively for communication.

170
00:08:02.839 --> 00:08:05.560
<v Speaker 2>Jason is the language of the web. It is, it is,

171
00:08:05.680 --> 00:08:06.199
<v Speaker 2>it really is.

172
00:08:06.360 --> 00:08:07.720
<v Speaker 1>But luckily there's Sarday.

173
00:08:08.040 --> 00:08:09.839
<v Speaker 2>Yes, Sauraday is a life saver.

174
00:08:09.959 --> 00:08:11.759
<v Speaker 1>To simplify that whole process.

175
00:08:11.920 --> 00:08:12.800
<v Speaker 2>Makes it so easy.

176
00:08:12.959 --> 00:08:18.560
<v Speaker 1>Saraday effortlessly converts Rust data structures into JSON format for

177
00:08:18.639 --> 00:08:23.240
<v Speaker 1>sending over the network, and seamlessly converts incoming Jason back

178
00:08:23.279 --> 00:08:24.279
<v Speaker 1>into Rust.

179
00:08:24.040 --> 00:08:27.040
<v Speaker 2>Structs, right back into those nice, neat data structures.

180
00:08:27.120 --> 00:08:30.600
<v Speaker 1>The book showcases this beautifully on page one oh five,

181
00:08:31.160 --> 00:08:34.480
<v Speaker 1>where a j request is handled and the response is

182
00:08:34.519 --> 00:08:38.440
<v Speaker 1>sent back as Jason data, all beautifully structured using a

183
00:08:38.559 --> 00:08:41.120
<v Speaker 1>Toto item struct defined on page one ten.

184
00:08:41.279 --> 00:08:42.279
<v Speaker 2>It's a great example.

185
00:08:42.399 --> 00:08:46.399
<v Speaker 1>Yeah, I think so too. So Rust combines power with elegance.

186
00:08:47.519 --> 00:08:49.720
<v Speaker 1>You get the control and safety of RUSS with the

187
00:08:49.799 --> 00:08:52.919
<v Speaker 1>convenience and readability of well structured code.

188
00:08:52.960 --> 00:08:55.240
<v Speaker 2>And that's what we all want, right we do. We

189
00:08:55.279 --> 00:08:57.879
<v Speaker 2>want our code to be readable and understandable.

190
00:08:58.080 --> 00:09:01.919
<v Speaker 1>So far we've explored how Rust hands data, yeah, manages

191
00:09:02.000 --> 00:09:06.399
<v Speaker 1>memory structures web apps. Right, it's a lot to take in,

192
00:09:06.480 --> 00:09:08.120
<v Speaker 1>but it's pretty impressive.

193
00:09:07.919 --> 00:09:09.320
<v Speaker 2>It is. It is very impressive.

194
00:09:09.399 --> 00:09:11.000
<v Speaker 1>So what's next on a Rust adventure?

195
00:09:11.200 --> 00:09:14.080
<v Speaker 2>Well, no web app is complete without data persistence, right,

196
00:09:14.360 --> 00:09:17.759
<v Speaker 2>We need a way to store information beyond those temporary

197
00:09:17.840 --> 00:09:22.039
<v Speaker 2>JSON files. So for that we have diesel therm for Rust.

198
00:09:22.799 --> 00:09:24.840
<v Speaker 1>All right, let's dive into that in part two. That's

199
00:09:24.879 --> 00:09:28.840
<v Speaker 1>good So, dear listener, take a moment to digest all

200
00:09:28.840 --> 00:09:30.759
<v Speaker 1>this amazing Rust knowledge.

201
00:09:30.919 --> 00:09:32.480
<v Speaker 2>There's a lot to unpack.

202
00:09:32.200 --> 00:09:34.440
<v Speaker 1>There is. We'll be right back with part two.

203
00:09:34.639 --> 00:09:36.120
<v Speaker 2>Yeah, looking forward to it.

204
00:09:36.000 --> 00:09:39.960
<v Speaker 1>To explore diesel and other fascinating aspects of Rust web development.

205
00:09:40.080 --> 00:09:42.919
<v Speaker 1>See you soon, Welcome back. Last time, we got a

206
00:09:42.919 --> 00:09:46.399
<v Speaker 1>glimpse of how Rust approaches you know, memory management and

207
00:09:46.559 --> 00:09:47.279
<v Speaker 1>error handling.

208
00:09:47.519 --> 00:09:49.759
<v Speaker 2>It's a different way of thinking, but I'm starting to

209
00:09:49.840 --> 00:09:52.279
<v Speaker 2>appreciate how it leads to more robust code.

210
00:09:52.320 --> 00:09:54.960
<v Speaker 1>Oh yeah, for sure. Yeah, but let's dive back into

211
00:09:55.000 --> 00:09:57.600
<v Speaker 1>the book and see how those concepts play out in

212
00:09:57.639 --> 00:09:58.360
<v Speaker 1>web development.

213
00:09:58.559 --> 00:09:58.960
<v Speaker 2>So good.

214
00:09:59.159 --> 00:10:03.000
<v Speaker 1>I'm particularly interested in those closures mentioned in the chapter

215
00:10:03.159 --> 00:10:07.559
<v Speaker 1>on handling HTTP requests? What exactly are they?

216
00:10:07.639 --> 00:10:13.600
<v Speaker 2>So? Closures are essentially anonymous functions that have this needability

217
00:10:14.080 --> 00:10:17.759
<v Speaker 2>to capture variables from their surrounding environment.

218
00:10:17.879 --> 00:10:18.799
<v Speaker 1>Do they have a memory?

219
00:10:19.600 --> 00:10:21.639
<v Speaker 2>Yeah, they kind of have a memory. They hold on

220
00:10:21.759 --> 00:10:24.799
<v Speaker 2>to information from the context in which they were created.

221
00:10:24.919 --> 00:10:29.000
<v Speaker 1>Okay, that sounds intriguing, but how does that translate to

222
00:10:29.519 --> 00:10:30.720
<v Speaker 1>building web servers?

223
00:10:30.840 --> 00:10:34.360
<v Speaker 2>So think about how you define routes in a web framework.

224
00:10:34.759 --> 00:10:39.720
<v Speaker 2>You're essentially mapping URLs to specific code that handles those requests.

225
00:10:40.200 --> 00:10:43.600
<v Speaker 2>Closures provide this really concise and flexible way to do this.

226
00:10:44.120 --> 00:10:48.039
<v Speaker 2>Remember that httpserver dot new function in aactics web.

227
00:10:48.159 --> 00:10:50.559
<v Speaker 1>Yeah, that's where you create the web server exactly.

228
00:10:50.720 --> 00:10:53.399
<v Speaker 2>You pass a closure to that function, and that closure

229
00:10:53.440 --> 00:10:55.159
<v Speaker 2>defines the applications logic.

230
00:10:55.480 --> 00:10:57.960
<v Speaker 1>So the closure acts like the brain of the web server.

231
00:10:58.279 --> 00:10:59.639
<v Speaker 2>Yeah, that's a great way to put.

232
00:10:59.559 --> 00:11:02.279
<v Speaker 1>It, decide what to do with each incoming request.

233
00:11:02.679 --> 00:11:07.480
<v Speaker 2>Yeah, it's like the control center okay. And because closures

234
00:11:07.519 --> 00:11:13.480
<v Speaker 2>can capture variables from their surroundings, they can access things

235
00:11:13.559 --> 00:11:17.080
<v Speaker 2>like database connections or configuration settings okay, that are defined

236
00:11:17.159 --> 00:11:18.480
<v Speaker 2>outside the closer itself.

237
00:11:18.559 --> 00:11:21.840
<v Speaker 1>So it's like having everything the server needs readily available.

238
00:11:21.919 --> 00:11:23.960
<v Speaker 2>Exactly. It's all right there at its fingertips.

239
00:11:24.200 --> 00:11:27.159
<v Speaker 1>It seems like closures bring a lot of organization and

240
00:11:27.200 --> 00:11:28.639
<v Speaker 1>efficiency to the table.

241
00:11:28.919 --> 00:11:30.080
<v Speaker 2>They really do, they really do.

242
00:11:30.240 --> 00:11:34.120
<v Speaker 1>But web development also often involves a lot of asynchronous programming.

243
00:11:34.200 --> 00:11:36.519
<v Speaker 2>Oh yeah, it's essential these days.

244
00:11:36.399 --> 00:11:38.120
<v Speaker 1>Which I'm still trying to wrap my head around.

245
00:11:38.279 --> 00:11:40.600
<v Speaker 2>It can be a little mind bending, it can, but

246
00:11:40.679 --> 00:11:42.879
<v Speaker 2>once you get it, it's really powerful.

247
00:11:43.000 --> 00:11:43.279
<v Speaker 1>Okay.

248
00:11:43.360 --> 00:11:46.919
<v Speaker 2>So a secretist programming is all about making your applications

249
00:11:47.519 --> 00:11:50.759
<v Speaker 2>more responsive and efficient. Okay, It allows a program to

250
00:11:50.799 --> 00:11:53.799
<v Speaker 2>work on other things while it's waiting for something like

251
00:11:53.840 --> 00:11:55.440
<v Speaker 2>a network request to complete.

252
00:11:55.559 --> 00:11:59.039
<v Speaker 1>Gotcha. So instead of just sitting idle, right, instead of.

253
00:11:59.000 --> 00:12:01.519
<v Speaker 2>Just blocking and waiting, it can go do other things.

254
00:12:01.559 --> 00:12:03.960
<v Speaker 2>It can multitask exactly, get multitask.

255
00:12:03.600 --> 00:12:05.399
<v Speaker 1>Making better use of resources and time.

256
00:12:05.559 --> 00:12:07.720
<v Speaker 2>Yeah, it's all about maximizing efficiency.

257
00:12:08.080 --> 00:12:10.399
<v Speaker 1>So instead of waiting for like a database query to

258
00:12:10.440 --> 00:12:15.399
<v Speaker 1>finish before moving on exactly, the server can handle other requests.

259
00:12:15.559 --> 00:12:16.600
<v Speaker 2>Yep, keep things moving.

260
00:12:16.679 --> 00:12:18.360
<v Speaker 1>It's like a well coordinated dance.

261
00:12:18.480 --> 00:12:19.639
<v Speaker 2>That's a great way to put it.

262
00:12:19.720 --> 00:12:22.799
<v Speaker 1>So Rust has this built in support. It does it

263
00:12:22.919 --> 00:12:26.960
<v Speaker 1>for asynchronous programming, which acticx web expertly uses.

264
00:12:27.120 --> 00:12:28.799
<v Speaker 2>Yeah, it just takes full advantage of it.

265
00:12:28.840 --> 00:12:31.039
<v Speaker 1>The book does a good job of breaking down the

266
00:12:31.080 --> 00:12:35.120
<v Speaker 1>core concepts of asinc in Rust. Okay, like the async

267
00:12:35.240 --> 00:12:37.440
<v Speaker 1>and awaight keywords.

268
00:12:37.039 --> 00:12:39.120
<v Speaker 2>Right, those are the key players.

269
00:12:38.759 --> 00:12:41.720
<v Speaker 1>And it even explores different ways to run these asynchronous

270
00:12:41.759 --> 00:12:44.960
<v Speaker 1>tasks concurrently using the futures crate.

271
00:12:45.120 --> 00:12:48.120
<v Speaker 2>Yeah, the Future's crate is essential for working with asink

272
00:12:48.159 --> 00:12:48.559
<v Speaker 2>and Rust.

273
00:12:48.600 --> 00:12:50.799
<v Speaker 1>Okay. So now let's shift gears a bit and talk

274
00:12:50.840 --> 00:12:53.600
<v Speaker 1>about managing the different views within our web app.

275
00:12:53.799 --> 00:12:54.639
<v Speaker 2>Right, sounds good?

276
00:12:54.759 --> 00:12:57.919
<v Speaker 1>You know, things like a home page, a log in page,

277
00:12:58.000 --> 00:12:58.879
<v Speaker 1>a user.

278
00:12:58.919 --> 00:13:01.000
<v Speaker 2>Profile, all the different sections.

279
00:13:01.200 --> 00:13:02.600
<v Speaker 1>How does rust approach that?

280
00:13:03.039 --> 00:13:08.200
<v Speaker 2>So Actic's Web encourages modularity by organizing views into separate modules.

281
00:13:09.000 --> 00:13:10.919
<v Speaker 1>So it's all about organization.

282
00:13:10.600 --> 00:13:13.600
<v Speaker 2>Yeah, keeping things tidy as our application grows, right, because

283
00:13:13.639 --> 00:13:16.879
<v Speaker 2>things can get messy quickly, they can if you're not careful.

284
00:13:17.120 --> 00:13:19.399
<v Speaker 1>So the book takes that a step further, okay, and

285
00:13:19.519 --> 00:13:22.399
<v Speaker 1>introduces this concept of view factories.

286
00:13:22.759 --> 00:13:24.360
<v Speaker 2>Oh yeah. View factories are great.

287
00:13:24.200 --> 00:13:28.519
<v Speaker 1>Functions dedicated to configuring and registering your views within the

288
00:13:28.559 --> 00:13:29.360
<v Speaker 1>web application.

289
00:13:29.639 --> 00:13:31.360
<v Speaker 2>Yeah. It's a nice way to centralize things.

290
00:13:31.639 --> 00:13:35.759
<v Speaker 1>So instead of scattering route definitions throughout our code, exactly,

291
00:13:35.879 --> 00:13:37.919
<v Speaker 1>have this centralized.

292
00:13:37.320 --> 00:13:39.519
<v Speaker 2>Place yep, one place to rule them all.

293
00:13:39.720 --> 00:13:40.320
<v Speaker 1>I like that.

294
00:13:40.440 --> 00:13:42.159
<v Speaker 2>It definitely makes things easier to manage.

295
00:13:42.240 --> 00:13:45.879
<v Speaker 1>So these view factories can be as simple or as

296
00:13:45.960 --> 00:13:47.879
<v Speaker 1>complex as you need them to be.

297
00:13:48.240 --> 00:13:50.360
<v Speaker 2>You can tailor them to your specific needs.

298
00:13:50.639 --> 00:13:54.200
<v Speaker 1>The book provides a clear example on page eighty seven, okay,

299
00:13:54.240 --> 00:13:57.159
<v Speaker 1>where a view factory is defined for the auth routs.

300
00:13:57.279 --> 00:14:00.720
<v Speaker 2>All right, so that's handling all your authentic stuff.

301
00:14:00.960 --> 00:14:03.960
<v Speaker 1>It's fascinating how they use the path struct to define

302
00:14:03.960 --> 00:14:08.240
<v Speaker 1>the base URL and then register each individual view using

303
00:14:08.240 --> 00:14:09.600
<v Speaker 1>the service config struct.

304
00:14:09.840 --> 00:14:11.279
<v Speaker 2>Yeah, it's very elegant solution.

305
00:14:11.440 --> 00:14:12.879
<v Speaker 1>That's very structured and elegant.

306
00:14:12.960 --> 00:14:14.720
<v Speaker 2>Yeah. Rust is all about that elegance.

307
00:14:15.279 --> 00:14:19.240
<v Speaker 1>Okay, So let's switch gears again and talk about data handling.

308
00:14:19.399 --> 00:14:22.399
<v Speaker 2>All right, data data data.

309
00:14:22.440 --> 00:14:25.159
<v Speaker 1>They've already seen how handles Jason.

310
00:14:25.000 --> 00:14:26.799
<v Speaker 2>Right, surday is the Jason Master.

311
00:14:26.960 --> 00:14:32.600
<v Speaker 1>But what about extracting data, okay from incoming requests and

312
00:14:32.759 --> 00:14:34.720
<v Speaker 1>sending data back to the client.

313
00:14:34.840 --> 00:14:37.679
<v Speaker 2>So that's that that communication back and forth between the

314
00:14:37.720 --> 00:14:38.960
<v Speaker 2>client and server.

315
00:14:39.240 --> 00:14:41.960
<v Speaker 1>So rust has an elegant solution for this as well.

316
00:14:41.960 --> 00:14:44.159
<v Speaker 1>Of course it does using structs and trades.

317
00:14:44.240 --> 00:14:45.919
<v Speaker 2>Structs and traits to the rescue.

318
00:14:45.960 --> 00:14:48.919
<v Speaker 1>They really are the backbone of rest. We really are

319
00:14:49.000 --> 00:14:52.879
<v Speaker 1>providing this amazing flexibility and organization.

320
00:14:52.519 --> 00:14:53.679
<v Speaker 2>All about structure, it is.

321
00:14:54.080 --> 00:14:56.799
<v Speaker 1>So let's imagine you have a form on your website

322
00:14:57.159 --> 00:15:01.000
<v Speaker 1>for users to enter their name and email address Classic

323
00:15:01.080 --> 00:15:02.759
<v Speaker 1>contact form, act contact form.

324
00:15:02.879 --> 00:15:06.519
<v Speaker 2>Yeah, you would define as struct in rusty to represent

325
00:15:06.559 --> 00:15:10.080
<v Speaker 2>that data with fields for name and email.

326
00:15:10.120 --> 00:15:11.519
<v Speaker 1>Yep, make a nice little struct.

327
00:15:12.039 --> 00:15:16.440
<v Speaker 2>And then in your Arctic's WebView you specify that you

328
00:15:16.559 --> 00:15:20.919
<v Speaker 2>expect this struct as the request body. Gotcha, and Actics

329
00:15:21.039 --> 00:15:25.519
<v Speaker 2>automatically takes care of de serializing the incoming Jason data

330
00:15:26.080 --> 00:15:27.240
<v Speaker 2>into that struct.

331
00:15:26.879 --> 00:15:28.840
<v Speaker 1>It just handles it for you, So no.

332
00:15:28.840 --> 00:15:31.399
<v Speaker 2>More manual parsing, potential errors.

333
00:15:31.440 --> 00:15:32.399
<v Speaker 1>It's all taken care of.

334
00:15:32.559 --> 00:15:34.039
<v Speaker 2>Pactics, just hands you the data.

335
00:15:34.159 --> 00:15:35.200
<v Speaker 1>Yep, nice and neat.

336
00:15:35.159 --> 00:15:37.960
<v Speaker 2>Neatly packaged and ready to use, ready to go. And

337
00:15:38.080 --> 00:15:40.879
<v Speaker 2>sending data back to the client follows a similar approach

338
00:15:41.159 --> 00:15:41.679
<v Speaker 2>pretty much.

339
00:15:41.759 --> 00:15:45.240
<v Speaker 1>Yeah, you can take a restruct, serialize it into Jason

340
00:15:45.360 --> 00:15:47.480
<v Speaker 1>using SORDE, and send it back.

341
00:15:47.279 --> 00:15:49.600
<v Speaker 2>As the response. So again, it's about making that data

342
00:15:49.639 --> 00:15:51.919
<v Speaker 2>exchange smooth and effortless.

343
00:15:51.960 --> 00:15:53.919
<v Speaker 1>Exactly, it should be a seamless process.

344
00:15:54.039 --> 00:15:59.120
<v Speaker 2>It's amazing how Rust manages to make even complex tasks yeah,

345
00:15:59.279 --> 00:16:01.480
<v Speaker 2>feel so streamlined and elegant.

346
00:16:01.639 --> 00:16:02.919
<v Speaker 1>It's a beautiful language.

347
00:16:02.960 --> 00:16:05.720
<v Speaker 2>But there's one crucial aspect we haven't touched upon yet.

348
00:16:05.960 --> 00:16:06.559
<v Speaker 1>Security.

349
00:16:06.639 --> 00:16:08.200
<v Speaker 2>Oh yeah, we can't forget about security.

350
00:16:08.279 --> 00:16:11.519
<v Speaker 1>How do we ensure our web applications are protected from

351
00:16:11.759 --> 00:16:13.360
<v Speaker 1>those malicious attacks?

352
00:16:13.480 --> 00:16:17.279
<v Speaker 2>So security is paramount and Rust lays a really strong

353
00:16:17.360 --> 00:16:21.679
<v Speaker 2>foundation for building secure applications. But we can't just rely

354
00:16:21.759 --> 00:16:24.720
<v Speaker 2>on the language alone. We need to be mindful of

355
00:16:25.039 --> 00:16:28.200
<v Speaker 2>common vulnerabilities and take steps to mitigate them.

356
00:16:28.480 --> 00:16:33.759
<v Speaker 1>So the book covers several security considerations from guarding against

357
00:16:33.799 --> 00:16:39.639
<v Speaker 1>cross site scripting EXSS attacks to implementing proper authentication and

358
00:16:39.679 --> 00:16:40.960
<v Speaker 1>authorization mechanisms.

359
00:16:41.000 --> 00:16:42.240
<v Speaker 2>Yeah, all the important stuff.

360
00:16:42.320 --> 00:16:47.080
<v Speaker 1>So it's a combination of leveraging Rust's strengths and following

361
00:16:47.120 --> 00:16:49.559
<v Speaker 1>those best practices for secure coding.

362
00:16:49.639 --> 00:16:50.559
<v Speaker 2>Yeah, you gotta have both.

363
00:16:50.879 --> 00:16:53.799
<v Speaker 1>So let's start with croft site scripting or EXSS. Right,

364
00:16:54.039 --> 00:16:57.720
<v Speaker 1>it's a common attack where malicious code is injected into

365
00:16:57.759 --> 00:16:59.840
<v Speaker 1>a web page that other users.

366
00:17:00.360 --> 00:17:02.559
<v Speaker 2>Yep, so it's like a way to sneak in code.

367
00:17:02.799 --> 00:17:05.599
<v Speaker 1>Imagine a comment section on a blog, Okay, where users

368
00:17:05.640 --> 00:17:07.039
<v Speaker 1>can submit their HTML.

369
00:17:07.319 --> 00:17:08.759
<v Speaker 2>Oh yeah, that's a classic example.

370
00:17:08.839 --> 00:17:12.440
<v Speaker 1>If an attacker manages to inject a malicious script, they

371
00:17:12.440 --> 00:17:17.000
<v Speaker 1>could potentially steal user data or hijack accounts, all sorts

372
00:17:17.000 --> 00:17:19.960
<v Speaker 1>of bad things. So that's why sanitizing user input is

373
00:17:20.000 --> 00:17:20.880
<v Speaker 1>so crucial.

374
00:17:21.039 --> 00:17:23.519
<v Speaker 2>It is absolutely crucial. You can't trust anything that comes

375
00:17:23.519 --> 00:17:24.279
<v Speaker 2>from the user.

376
00:17:24.200 --> 00:17:25.799
<v Speaker 1>Especially when dealing with HTML.

377
00:17:26.200 --> 00:17:28.480
<v Speaker 2>Yeah, especially EACHTML, because that's where a lot of these

378
00:17:28.519 --> 00:17:29.160
<v Speaker 2>attacks happen.

379
00:17:29.319 --> 00:17:33.519
<v Speaker 1>The book offers best practices for escaping special characters and

380
00:17:33.640 --> 00:17:36.640
<v Speaker 1>ensuring that users submitted content is displayed safely.

381
00:17:36.880 --> 00:17:40.559
<v Speaker 2>Right, So you're essentially neutralizing any potentially harmful code.

382
00:17:40.599 --> 00:17:43.920
<v Speaker 1>It's about treating all incoming data with a healthy dose

383
00:17:43.920 --> 00:17:44.599
<v Speaker 1>of suspicion.

384
00:17:44.759 --> 00:17:46.599
<v Speaker 2>Exactly, trust no one.

385
00:17:46.960 --> 00:17:51.160
<v Speaker 1>Now let's talk about authentication and authorization. Okay, we briefly

386
00:17:51.200 --> 00:17:54.240
<v Speaker 1>mentioned JWT's and password hashing earlier.

387
00:17:54.599 --> 00:17:56.559
<v Speaker 2>Right, those are our security heroes, but how do.

388
00:17:56.519 --> 00:17:59.960
<v Speaker 1>We actually implement those in our rust web app.

389
00:18:00.240 --> 00:18:03.799
<v Speaker 2>So jbt's and password hashing are key components of a

390
00:18:03.839 --> 00:18:08.039
<v Speaker 2>secure authentication system, and the book provides a great walkthrough

391
00:18:08.079 --> 00:18:11.920
<v Speaker 2>on how to implement them, starting with defining a user model. Okay,

392
00:18:12.119 --> 00:18:13.440
<v Speaker 2>much like the to do item model.

393
00:18:13.599 --> 00:18:16.759
<v Speaker 1>Right, so we're creating those rust strucks again exactly.

394
00:18:16.880 --> 00:18:18.359
<v Speaker 2>We love our structure that mirror.

395
00:18:18.200 --> 00:18:21.039
<v Speaker 1>The structure of our data, this time representing a user

396
00:18:21.079 --> 00:18:21.759
<v Speaker 1>in our system.

397
00:18:22.000 --> 00:18:25.559
<v Speaker 2>Right, so you'd have feels for things like username, email address,

398
00:18:25.880 --> 00:18:26.960
<v Speaker 2>and of course the password.

399
00:18:27.119 --> 00:18:30.079
<v Speaker 1>Okay, but with passwords we have to be extra careful. Right.

400
00:18:30.200 --> 00:18:32.079
<v Speaker 2>Oh yeah, passwords are super sensitive.

401
00:18:32.240 --> 00:18:34.680
<v Speaker 1>Storing them in plaintext is a big no no.

402
00:18:35.039 --> 00:18:37.640
<v Speaker 2>Absolutely, you never want to store passwords in plain text.

403
00:18:37.759 --> 00:18:40.200
<v Speaker 1>It's like leaving the keys to the kingdom out in

404
00:18:40.240 --> 00:18:40.720
<v Speaker 1>the open.

405
00:18:41.079 --> 00:18:42.880
<v Speaker 2>Yeah, it's just asking for trouble.

406
00:18:43.000 --> 00:18:45.160
<v Speaker 1>So that's where password hashing comes into play.

407
00:18:45.279 --> 00:18:46.720
<v Speaker 2>Password hashing to the rescue.

408
00:18:46.839 --> 00:18:50.119
<v Speaker 1>Instead of storing the actual password, right, we use a

409
00:18:50.119 --> 00:18:54.519
<v Speaker 1>special function to transform it into a scrambled, unreadable format.

410
00:18:54.680 --> 00:18:56.839
<v Speaker 2>Exactly. It's like turning it into gibberish.

411
00:18:57.119 --> 00:19:00.519
<v Speaker 1>The book suggests using the b crypt crate for this, okay,

412
00:19:00.559 --> 00:19:03.359
<v Speaker 1>and provides an example on page one seventy.

413
00:19:03.599 --> 00:19:05.759
<v Speaker 2>B crypt is a good choice. It's a very strong

414
00:19:05.799 --> 00:19:06.680
<v Speaker 2>hashing algorithm.

415
00:19:07.039 --> 00:19:09.440
<v Speaker 1>Okay. So even if someone gets their hands on those

416
00:19:09.839 --> 00:19:13.799
<v Speaker 1>hashed passwords, they're essentially useless pretty much.

417
00:19:13.960 --> 00:19:16.960
<v Speaker 2>Yeah. Yeah, it's extremely difficult to reverse that process.

418
00:19:17.119 --> 00:19:19.599
<v Speaker 1>It's like trying to solve the complex puzzle without all.

419
00:19:19.559 --> 00:19:22.000
<v Speaker 2>The pieces, exactly. It's a very difficult puzzle.

420
00:19:22.079 --> 00:19:26.359
<v Speaker 1>Okay. So we've hashed and stored those passwords securely.

421
00:19:26.079 --> 00:19:27.200
<v Speaker 2>All right, so far, so good.

422
00:19:27.480 --> 00:19:30.359
<v Speaker 1>What happens when a user tries to log in?

423
00:19:30.960 --> 00:19:33.319
<v Speaker 2>So, when a user tries to log in, we take

424
00:19:33.359 --> 00:19:36.119
<v Speaker 2>the password they enter, okay, hash it using the same

425
00:19:36.160 --> 00:19:41.079
<v Speaker 2>algorithm and compare the resulting hash to the one store

426
00:19:41.079 --> 00:19:41.799
<v Speaker 2>in the database.

427
00:19:42.039 --> 00:19:44.119
<v Speaker 1>So we're not comparing the actual.

428
00:19:43.759 --> 00:19:45.920
<v Speaker 2>Passwords, No, we're comparing the hashes.

429
00:19:45.880 --> 00:19:48.759
<v Speaker 1>Right, we're comparing the gibberius exactly, and if the hash

430
00:19:48.799 --> 00:19:51.839
<v Speaker 1>is match, we know they entered the correct password okay,

431
00:19:51.880 --> 00:19:53.519
<v Speaker 1>and if everything checks out all right.

432
00:19:53.440 --> 00:19:57.240
<v Speaker 2>If they pass the test, we issue them a JA

433
00:19:57.440 --> 00:20:02.039
<v Speaker 2>ANDBA Jason web tooken act like a digital passport containing

434
00:20:02.039 --> 00:20:04.720
<v Speaker 2>information about the user in their session. This token is

435
00:20:04.759 --> 00:20:07.720
<v Speaker 2>then sent back to the client, who usually stores it

436
00:20:07.759 --> 00:20:12.119
<v Speaker 2>in their browser okay and presents it with each subsequent request.

437
00:20:12.240 --> 00:20:15.440
<v Speaker 1>So it's like they're carrying their identification with them as

438
00:20:15.519 --> 00:20:16.759
<v Speaker 1>they navigate the application.

439
00:20:16.920 --> 00:20:17.880
<v Speaker 2>Is their ticket to ride it.

440
00:20:17.920 --> 00:20:22.000
<v Speaker 1>On the server side, we have middleware checking those JWTs,

441
00:20:22.720 --> 00:20:25.000
<v Speaker 1>acting like security guards.

442
00:20:25.119 --> 00:20:27.400
<v Speaker 2>Making sure everything's legit, ensuring.

443
00:20:27.079 --> 00:20:31.000
<v Speaker 1>That only authorized users can access certain areas.

444
00:20:31.079 --> 00:20:33.240
<v Speaker 2>Exactly. It's all about control access.

445
00:20:32.920 --> 00:20:35.839
<v Speaker 1>And if the JWT is invalid.

446
00:20:35.359 --> 00:20:37.359
<v Speaker 2>Or missing right, then we deny access.

447
00:20:37.400 --> 00:20:40.000
<v Speaker 1>We deny the request and send back an.

448
00:20:39.960 --> 00:20:41.599
<v Speaker 2>Error exactly, you shall not pass.

449
00:20:41.720 --> 00:20:44.160
<v Speaker 1>So it's a multi layered approach to security.

450
00:20:44.240 --> 00:20:44.559
<v Speaker 2>It is.

451
00:20:44.759 --> 00:20:47.599
<v Speaker 1>It is using different tools and techniques to protect our

452
00:20:47.640 --> 00:20:49.359
<v Speaker 1>application and its users.

453
00:20:49.400 --> 00:20:50.839
<v Speaker 2>You got to keep everyone safe.

454
00:20:50.960 --> 00:20:53.559
<v Speaker 1>We've covered a lot of ground here. We have from

455
00:20:53.640 --> 00:20:59.079
<v Speaker 1>closures and asynchronous programming to security and data handling all

456
00:20:59.119 --> 00:21:01.240
<v Speaker 1>the important stuff. What other gems are hidden?

457
00:21:01.440 --> 00:21:03.000
<v Speaker 2>Oh, there are plenty more gems.

458
00:21:02.839 --> 00:21:04.839
<v Speaker 1>Within this world of rust Web development.

459
00:21:04.960 --> 00:21:06.200
<v Speaker 2>Rust is full of surprises.

460
00:21:06.559 --> 00:21:10.759
<v Speaker 1>So the book touches on logging, okay, a crucial aspect

461
00:21:10.799 --> 00:21:13.599
<v Speaker 1>of monitoring and debugging web applications.

462
00:21:13.680 --> 00:21:14.720
<v Speaker 2>Logging is essential.

463
00:21:15.079 --> 00:21:18.640
<v Speaker 1>You gotta know what's going on, especially when building RESTful.

464
00:21:18.240 --> 00:21:20.519
<v Speaker 2>Services, especially in production, when things go wrong.

465
00:21:20.599 --> 00:21:22.680
<v Speaker 1>When things go wrong, you need to know why. So

466
00:21:22.799 --> 00:21:25.039
<v Speaker 1>logging it's like having a detailed record.

467
00:21:25.079 --> 00:21:26.480
<v Speaker 2>Yes, it's like a history book of.

468
00:21:26.400 --> 00:21:29.200
<v Speaker 1>Everything that's happening within our application.

469
00:21:28.799 --> 00:21:30.680
<v Speaker 2>Exactly, so you can go back and see what happened.

470
00:21:30.880 --> 00:21:36.799
<v Speaker 1>The book introduces some popular Rust logging libraries, like what

471
00:21:37.200 --> 00:21:40.359
<v Speaker 1>like log in on vlogger. Those are good ones, making

472
00:21:40.440 --> 00:21:43.920
<v Speaker 1>it super easy to integrate logging into our applications.

473
00:21:44.000 --> 00:21:45.640
<v Speaker 2>Yeah, they make it really straightforward.

474
00:21:45.960 --> 00:21:50.480
<v Speaker 1>But there's one more crucial piece of the puzzle okay, deployment.

475
00:21:50.680 --> 00:21:53.440
<v Speaker 2>Ah, yes, deployment the final frontier.

476
00:21:53.559 --> 00:21:56.519
<v Speaker 1>How do we actually get our rust web application out

477
00:21:56.559 --> 00:21:57.640
<v Speaker 1>into the world.

478
00:21:57.440 --> 00:22:00.240
<v Speaker 2>Out into the wild for others to use. So the

479
00:22:00.279 --> 00:22:04.599
<v Speaker 2>book uses AWS as an example. Deploying to an easy

480
00:22:04.640 --> 00:22:06.559
<v Speaker 2>two instance using Docker.

481
00:22:06.799 --> 00:22:07.920
<v Speaker 1>Docker, our trusty friend.

482
00:22:08.039 --> 00:22:09.279
<v Speaker 2>Docker is a lifesaver.

483
00:22:09.519 --> 00:22:13.759
<v Speaker 1>It's like packaging your application and all its dependencies into

484
00:22:13.759 --> 00:22:16.680
<v Speaker 1>this neat little container that can run anywhere exactly.

485
00:22:16.720 --> 00:22:18.319
<v Speaker 2>It's like a little self contained.

486
00:22:17.920 --> 00:22:22.240
<v Speaker 1>World regardless of the underlying operating system. Yep, it's platform

487
00:22:22.240 --> 00:22:26.640
<v Speaker 1>agnostic and AWSC two provides those virtual servers in the

488
00:22:26.799 --> 00:22:30.000
<v Speaker 1>cloud ready to host our containerized applications.

489
00:22:30.039 --> 00:22:31.279
<v Speaker 2>Yeah, it's a match made in heaven.

490
00:22:31.440 --> 00:22:34.240
<v Speaker 1>But how do we get our Docker image from our

491
00:22:34.240 --> 00:22:35.359
<v Speaker 1>computer to the cloud.

492
00:22:35.599 --> 00:22:38.680
<v Speaker 2>So that's where services like Docker Hub come in, which

493
00:22:38.720 --> 00:22:41.440
<v Speaker 2>act as a registry where you can store and share

494
00:22:41.839 --> 00:22:42.799
<v Speaker 2>your Docker images.

495
00:22:43.039 --> 00:22:45.759
<v Speaker 1>So you build your image locally, push it to Docker Hub,

496
00:22:46.279 --> 00:22:49.400
<v Speaker 1>and then your server on AWS can easily pull it

497
00:22:49.480 --> 00:22:50.559
<v Speaker 1>down and run it.

498
00:22:50.680 --> 00:22:52.319
<v Speaker 2>Yeah, it's a very streamline process.

499
00:22:52.359 --> 00:22:54.400
<v Speaker 1>We've covered so much ground in this deep.

500
00:22:54.200 --> 00:22:56.559
<v Speaker 2>Dive we have. It's been a whirlwind, from.

501
00:22:56.480 --> 00:23:01.559
<v Speaker 1>The fundamentals of RUSS to handling requests, securing our app

502
00:23:01.880 --> 00:23:03.920
<v Speaker 1>and even deploying it to the cloud.

503
00:23:04.400 --> 00:23:07.640
<v Speaker 2>The whole nine yards just mind boggling. It is a

504
00:23:07.680 --> 00:23:08.440
<v Speaker 2>lot to take.

505
00:23:08.240 --> 00:23:09.920
<v Speaker 1>In, but we've only scratched the surface.

506
00:23:09.960 --> 00:23:11.519
<v Speaker 2>Oh yeah, just the tip of the iceberg.

507
00:23:11.240 --> 00:23:13.279
<v Speaker 1>Of what's possible with Rust web development.

508
00:23:13.400 --> 00:23:15.440
<v Speaker 2>Rust is an incredibly powerful language.

509
00:23:15.519 --> 00:23:17.319
<v Speaker 1>So what other adventures await us?

510
00:23:17.680 --> 00:23:19.480
<v Speaker 2>Oh, there's always more to explore, and.

511
00:23:19.359 --> 00:23:21.680
<v Speaker 1>What exciting new concepts will we uncover?

512
00:23:22.319 --> 00:23:24.160
<v Speaker 2>I guess you'll have to stay tuned to find out.

513
00:23:24.279 --> 00:23:26.799
<v Speaker 1>So, dear listener, take a break, Yeah, grab a coffee

514
00:23:26.880 --> 00:23:30.319
<v Speaker 1>or something. Let all this information sink in. There's a

515
00:23:30.359 --> 00:23:33.039
<v Speaker 1>lot to process, and we'll be back with Part three.

516
00:23:33.440 --> 00:23:34.759
<v Speaker 2>Looking forward to it to.

517
00:23:34.799 --> 00:23:37.440
<v Speaker 1>Dive into even more fascinating aspects of Rust.

518
00:23:37.559 --> 00:23:38.160
<v Speaker 2>I see you soon.

519
00:23:39.799 --> 00:23:43.759
<v Speaker 1>Welcome back to our rest journey. We've covered so much already,

520
00:23:43.839 --> 00:23:48.119
<v Speaker 1>like how Rust handles data, manages memory, and even secures

521
00:23:48.119 --> 00:23:49.119
<v Speaker 1>our web applications.

522
00:23:49.160 --> 00:23:50.720
<v Speaker 2>It's been quite the adventure it has.

523
00:23:51.279 --> 00:23:53.519
<v Speaker 1>Now I'm really eager to dive into the practical side

524
00:23:53.519 --> 00:23:57.720
<v Speaker 1>of things, like interacting with databases and building those powerful,

525
00:23:57.799 --> 00:23:59.640
<v Speaker 1>RESTful APIs.

526
00:23:59.160 --> 00:24:02.960
<v Speaker 2>You're in for a tree database interaction is a cornerstone

527
00:24:03.000 --> 00:24:06.680
<v Speaker 2>it is of most web applications, and thankfully Rust has

528
00:24:06.720 --> 00:24:09.480
<v Speaker 2>a really powerful tool for that. Diesel the orm we

529
00:24:09.599 --> 00:24:10.640
<v Speaker 2>briefly touched on before.

530
00:24:10.880 --> 00:24:14.200
<v Speaker 1>Yeah, Diesel lets us communicate with our Postgres school database

531
00:24:14.640 --> 00:24:17.000
<v Speaker 1>using nice, clean, type safe rest code.

532
00:24:17.079 --> 00:24:18.039
<v Speaker 2>It's a beautiful thing.

533
00:24:18.160 --> 00:24:19.480
<v Speaker 1>I'm excited to see it in action.

534
00:24:19.640 --> 00:24:20.200
<v Speaker 2>Yeah, me too.

535
00:24:20.400 --> 00:24:23.640
<v Speaker 1>So the book provides a fantastic step by step guide

536
00:24:23.960 --> 00:24:28.640
<v Speaker 1>on using diesels, starting with setting up our development environment using.

537
00:24:28.440 --> 00:24:31.240
<v Speaker 2>Docker ah Docker our trusty friends.

538
00:24:31.000 --> 00:24:33.920
<v Speaker 1>Our trusty friend for creating those isolated environments.

539
00:24:33.960 --> 00:24:35.480
<v Speaker 2>Right. It keeps everything nice and contained.

540
00:24:35.680 --> 00:24:39.799
<v Speaker 1>It's like having a mini virtual machine dedicated to our database,

541
00:24:40.119 --> 00:24:43.680
<v Speaker 1>keeping things organized and preventing conflicts with other software on

542
00:24:43.680 --> 00:24:44.160
<v Speaker 1>our system.

543
00:24:44.319 --> 00:24:45.960
<v Speaker 2>Exactly. It's like its own little sandbox.

544
00:24:46.160 --> 00:24:49.880
<v Speaker 1>So docer makes setting up and managing these environments a breeze.

545
00:24:50.039 --> 00:24:51.599
<v Speaker 2>Oh yeah, it takes all the headache out of it.

546
00:24:51.799 --> 00:24:56.039
<v Speaker 1>The book then guides you through defining our database schemakay

547
00:24:56.200 --> 00:24:57.920
<v Speaker 1>using Diesel's migration system.

548
00:24:58.279 --> 00:25:00.200
<v Speaker 2>Ah. Migration's very import.

549
00:25:00.240 --> 00:25:02.279
<v Speaker 1>Like version control for our database. Right.

550
00:25:02.400 --> 00:25:04.160
<v Speaker 2>Yeah, that's a great way to think about it.

551
00:25:04.240 --> 00:25:06.640
<v Speaker 1>So they allow us to track changes, roll back to

552
00:25:06.680 --> 00:25:10.039
<v Speaker 1>previous versions if made, and keep everything organized.

553
00:25:10.359 --> 00:25:14.759
<v Speaker 2>It makes collaboration so much easier, I bet, yeah, because

554
00:25:14.799 --> 00:25:17.519
<v Speaker 2>everybody can be working on their own migrations and then

555
00:25:17.559 --> 00:25:19.720
<v Speaker 2>you just apply them in order and it all works out.

556
00:25:19.880 --> 00:25:23.559
<v Speaker 1>So Diesel makes this process very smooth, it does it?

557
00:25:23.599 --> 00:25:27.359
<v Speaker 1>Does You create these migration files that describe the changes

558
00:25:27.440 --> 00:25:30.039
<v Speaker 1>you want to make to your database, and Diesel takes

559
00:25:30.079 --> 00:25:31.839
<v Speaker 1>care of applying them in the correct order.

560
00:25:32.000 --> 00:25:34.559
<v Speaker 2>Yeah. It even has a command line tool does it

561
00:25:34.640 --> 00:25:36.759
<v Speaker 2>to simplify running those migrations.

562
00:25:36.799 --> 00:25:39.240
<v Speaker 1>So it's like a one stop shop pretty much. Yeah,

563
00:25:39.240 --> 00:25:41.440
<v Speaker 1>I'm looking at an example on page one fifty six.

564
00:25:41.960 --> 00:25:43.200
<v Speaker 1>It seems pretty straightforward.

565
00:25:43.279 --> 00:25:44.359
<v Speaker 2>Yeah, it's very intuitive.

566
00:25:44.480 --> 00:25:48.240
<v Speaker 1>You define the migration file and inside you write SQL

567
00:25:48.279 --> 00:25:51.039
<v Speaker 1>statements to create or modify tables.

568
00:25:51.160 --> 00:25:53.599
<v Speaker 2>So it's still SQL under the hood. It is, but

569
00:25:53.640 --> 00:25:55.279
<v Speaker 2>Diesel just gives you a nice way to manage it.

570
00:25:56.079 --> 00:25:58.359
<v Speaker 1>And the beauty of it is that Diesel ensures that

571
00:25:58.359 --> 00:26:04.200
<v Speaker 1>those migrations are applied in correct sequence, preventing any inconsistencies

572
00:26:04.279 --> 00:26:06.799
<v Speaker 1>or conflicts that could arise from out of order changes.

573
00:26:06.839 --> 00:26:08.400
<v Speaker 2>It's like a safety net for your database.

574
00:26:08.480 --> 00:26:10.599
<v Speaker 1>It takes a lot of the headache out of database management,

575
00:26:10.680 --> 00:26:11.319
<v Speaker 1>oh for sure.

576
00:26:11.440 --> 00:26:11.839
<v Speaker 2>For sure.

577
00:26:11.960 --> 00:26:15.680
<v Speaker 1>Okay, so we've defined our schema, we've run our migrations.

578
00:26:15.720 --> 00:26:18.720
<v Speaker 2>Now we need to create some Rust models, okay that

579
00:26:18.799 --> 00:26:20.440
<v Speaker 2>represent those database tables.

580
00:26:20.599 --> 00:26:24.039
<v Speaker 1>So these models are like the bridge between our RUST

581
00:26:24.160 --> 00:26:26.119
<v Speaker 1>code and the database, right.

582
00:26:26.200 --> 00:26:28.000
<v Speaker 2>Yeah, they're the intermediaria.

583
00:26:27.480 --> 00:26:30.680
<v Speaker 1>Making interacting with data types safe and easy to manage,

584
00:26:30.799 --> 00:26:31.119
<v Speaker 1>and they.

585
00:26:31.079 --> 00:26:32.240
<v Speaker 2>Keep our code nice and clean.

586
00:26:32.720 --> 00:26:35.079
<v Speaker 1>So we're essentially creating Rust structs.

587
00:26:35.480 --> 00:26:36.880
<v Speaker 2>We love our structure.

588
00:26:36.519 --> 00:26:38.920
<v Speaker 1>That mirror the structure of our table exactly.

589
00:26:38.960 --> 00:26:41.960
<v Speaker 2>Each field in the struct corresponds to a column in

590
00:26:42.000 --> 00:26:42.880
<v Speaker 2>the database table.

591
00:26:43.079 --> 00:26:45.640
<v Speaker 1>I love how Rust encourages us to think about these

592
00:26:45.720 --> 00:26:47.200
<v Speaker 1>data structures and types.

593
00:26:47.359 --> 00:26:50.000
<v Speaker 2>It makes the code so much more explicit and readable.

594
00:26:50.119 --> 00:26:50.839
<v Speaker 1>It really does.

595
00:26:51.039 --> 00:26:54.400
<v Speaker 2>Yeah, and Diesel leverages this to its advantage. It makes

596
00:26:54.680 --> 00:26:58.000
<v Speaker 2>working with databases in Rust a really enjoyable experience.

597
00:26:58.119 --> 00:27:01.359
<v Speaker 1>I bet so. No more wrestling with raw SQL queries.

598
00:27:01.079 --> 00:27:03.119
<v Speaker 2>No more raw sequel unless you really want.

599
00:27:02.960 --> 00:27:04.440
<v Speaker 1>It, unless you really want to.

600
00:27:04.759 --> 00:27:06.880
<v Speaker 2>But Diesel can handle most things for you.

601
00:27:07.240 --> 00:27:09.839
<v Speaker 1>I'm looking at this example on page one sixty one. Okay,

602
00:27:09.880 --> 00:27:13.480
<v Speaker 1>where they define a model for a to do item.

603
00:27:13.680 --> 00:27:15.240
<v Speaker 2>Right, the trustee to do list.

604
00:27:15.279 --> 00:27:18.880
<v Speaker 1>They're using this table macro, which seems to be doing

605
00:27:18.920 --> 00:27:22.200
<v Speaker 1>all the heavy lifting of mapping that's stretched to the

606
00:27:22.279 --> 00:27:23.119
<v Speaker 1>database table.

607
00:27:23.359 --> 00:27:25.440
<v Speaker 2>Yeah. That macro is a lifesaver.

608
00:27:25.160 --> 00:27:27.319
<v Speaker 1>Taking care of all that boilerplate code for you.

609
00:27:27.519 --> 00:27:30.000
<v Speaker 2>Exactly. It just does all the work behind the scenes.

610
00:27:30.079 --> 00:27:32.400
<v Speaker 1>Okay, so we've got our model set up, right, how

611
00:27:32.400 --> 00:27:34.880
<v Speaker 1>do we actually use them to interact with the database.

612
00:27:35.000 --> 00:27:39.200
<v Speaker 2>So Diesel provides this really expressive query builder that allows

613
00:27:39.240 --> 00:27:44.359
<v Speaker 2>you to write database queries in this really type safe way.

614
00:27:44.279 --> 00:27:47.559
<v Speaker 1>So we're not just throwing raw SEQL queries at the database, no, no, no,

615
00:27:47.599 --> 00:27:48.480
<v Speaker 1>and hoping for the best.

616
00:27:48.640 --> 00:27:51.200
<v Speaker 2>Diesels are there to guide us and make sure we're

617
00:27:51.200 --> 00:27:52.119
<v Speaker 2>doing things correctly.

618
00:27:52.279 --> 00:27:54.319
<v Speaker 1>I see an example on page one sixty eight where

619
00:27:54.319 --> 00:27:57.400
<v Speaker 1>they're using diesel to fetch all the to do items

620
00:27:57.400 --> 00:28:01.359
<v Speaker 1>from the database. It's an interesting blend of that sequel

621
00:28:01.599 --> 00:28:04.839
<v Speaker 1>like syntax with those Rust function calls.

622
00:28:05.200 --> 00:28:07.720
<v Speaker 2>Yeah, it's a nice fusion of the two worlds. Is

623
00:28:07.920 --> 00:28:11.000
<v Speaker 2>so you get the familiarity of sequel, but with the

624
00:28:11.079 --> 00:28:12.279
<v Speaker 2>type safety of Rust.

625
00:28:12.480 --> 00:28:15.440
<v Speaker 1>This is fantastic. So we can build these sophisticated database

626
00:28:15.480 --> 00:28:18.759
<v Speaker 1>interactions all within the safety and structure of RUSS exactly.

627
00:28:18.799 --> 00:28:20.359
<v Speaker 1>But what about user authentication?

628
00:28:20.720 --> 00:28:21.680
<v Speaker 2>Ah? Yes, security.

629
00:28:21.799 --> 00:28:24.640
<v Speaker 1>We talked about jbts and password hashing.

630
00:28:24.279 --> 00:28:25.960
<v Speaker 2>Earlier, right, our security heroes.

631
00:28:26.000 --> 00:28:27.680
<v Speaker 1>How do we put those into practice?

632
00:28:28.079 --> 00:28:31.960
<v Speaker 2>Okay, so user authentication is crucial for any application it

633
00:28:32.039 --> 00:28:35.200
<v Speaker 2>is that handles sensitive data. Yeah, and the book does

634
00:28:35.240 --> 00:28:38.640
<v Speaker 2>not disappoint. I bet it provides a really detailed guide

635
00:28:38.759 --> 00:28:43.519
<v Speaker 2>on implementing authentication using jtabts and password hashing. And it

636
00:28:43.559 --> 00:28:46.839
<v Speaker 2>starts by defining a user model. Okay, much like we

637
00:28:46.880 --> 00:28:48.279
<v Speaker 2>did with our to do item model.

638
00:28:48.559 --> 00:28:51.880
<v Speaker 1>So again we're creating those Rust strucks that mirror the

639
00:28:51.920 --> 00:28:54.759
<v Speaker 1>structure of our data. We love our structs, this time

640
00:28:54.880 --> 00:28:56.960
<v Speaker 1>representing a user in our system.

641
00:28:57.200 --> 00:29:01.400
<v Speaker 2>Right, so we'll have fields for username, email address, and

642
00:29:01.440 --> 00:29:02.680
<v Speaker 2>the all important password.

643
00:29:02.759 --> 00:29:06.039
<v Speaker 1>But here's where we have to be extra careful, right, Oh.

644
00:29:05.960 --> 00:29:08.000
<v Speaker 2>Yeah, extra careful with passwords.

645
00:29:08.240 --> 00:29:12.119
<v Speaker 1>Storing them in plaintext is a huge security risk.

646
00:29:12.279 --> 00:29:14.599
<v Speaker 2>Absolutely, never store passwords in plain text.

647
00:29:14.720 --> 00:29:16.680
<v Speaker 1>It's like leaving the keys to the Kingdom out in

648
00:29:16.720 --> 00:29:17.119
<v Speaker 1>the open.

649
00:29:17.359 --> 00:29:19.200
<v Speaker 2>Yeah, it's just asking for trouble.

650
00:29:19.440 --> 00:29:22.160
<v Speaker 1>So that's where password hashing comes in to save the day.

651
00:29:22.519 --> 00:29:24.119
<v Speaker 2>Password hashing to the rescue.

652
00:29:24.240 --> 00:29:27.119
<v Speaker 1>Instead of storing the actual password, we use a special

653
00:29:27.200 --> 00:29:31.079
<v Speaker 1>function to transform it into a scrambled, unreadable format.

654
00:29:31.279 --> 00:29:32.720
<v Speaker 2>We turn it into gobbledygook.

655
00:29:33.079 --> 00:29:36.400
<v Speaker 1>The book suggests using the b crypt create okay and

656
00:29:36.480 --> 00:29:38.759
<v Speaker 1>provides an example on page one seventy nine.

657
00:29:38.880 --> 00:29:41.519
<v Speaker 2>B crypt is a good choice. It's a very strong

658
00:29:41.599 --> 00:29:43.240
<v Speaker 2>hashing algorithm.

659
00:29:42.799 --> 00:29:46.119
<v Speaker 1>So even if someone gets their hands on those hashed passwords,

660
00:29:46.519 --> 00:29:47.920
<v Speaker 1>they're essentially useless.

661
00:29:48.000 --> 00:29:51.000
<v Speaker 2>Yeah, it's extremely difficult to reverse that hashing process.

662
00:29:51.079 --> 00:29:53.160
<v Speaker 1>Okay, So when a user tries to log in, we

663
00:29:53.240 --> 00:29:56.319
<v Speaker 1>take the password they enter, right, hash it using the

664
00:29:56.359 --> 00:29:59.920
<v Speaker 1>same algorithm, and compare the resulting hash to the ones

665
00:30:00.240 --> 00:30:03.039
<v Speaker 1>in the database Exactly, we're comparing the gobbledygook, and if

666
00:30:03.039 --> 00:30:06.440
<v Speaker 1>the hashes match, we know they've entered the correct password.

667
00:30:06.640 --> 00:30:08.240
<v Speaker 2>That's how we know they're who they say they are.

668
00:30:08.559 --> 00:30:11.160
<v Speaker 1>And if everything checks out, what happens then?

669
00:30:11.400 --> 00:30:14.640
<v Speaker 2>Okay? So if the credentials are valid, we generate a

670
00:30:14.720 --> 00:30:16.799
<v Speaker 2>JWT that Jason webtok.

671
00:30:16.440 --> 00:30:18.279
<v Speaker 1>Can we talked about before, the digital passport.

672
00:30:18.480 --> 00:30:20.519
<v Speaker 2>Right, it's their ticket to ride.

673
00:30:20.319 --> 00:30:23.960
<v Speaker 1>Containing information about the user and their session exactly. Okay,

674
00:30:24.000 --> 00:30:26.200
<v Speaker 1>So we send this token back to the client, who

675
00:30:26.200 --> 00:30:28.559
<v Speaker 1>typically stores it in their browser and includes it in

676
00:30:28.680 --> 00:30:29.960
<v Speaker 1>each subsequent request.

677
00:30:30.119 --> 00:30:31.839
<v Speaker 2>Right, It's like their badge of authentication.

678
00:30:32.079 --> 00:30:34.599
<v Speaker 1>So on the server side, we need middleware right that

679
00:30:34.720 --> 00:30:39.559
<v Speaker 1>intercepts those requests, verifies the JWT, and only allows the

680
00:30:39.599 --> 00:30:42.200
<v Speaker 1>request to proceed if everything checks out.

681
00:30:42.279 --> 00:30:44.039
<v Speaker 2>Yeah, the middleware is like the bouncer at the club

682
00:30:44.160 --> 00:30:47.640
<v Speaker 2>checking IDs, making sure everyone's got the right credentials.

683
00:30:47.079 --> 00:30:50.519
<v Speaker 1>And if the JWT is invalid or missing, boot them out.

684
00:30:50.640 --> 00:30:52.759
<v Speaker 1>We deny the request and send back an ERA.

685
00:30:52.759 --> 00:30:53.720
<v Speaker 2>You shall not pass.

686
00:30:54.039 --> 00:30:57.200
<v Speaker 1>It's all about adding those layers of protection to ensure

687
00:30:57.240 --> 00:31:01.759
<v Speaker 1>that only authorized users can access specific resources or perform

688
00:31:01.880 --> 00:31:03.680
<v Speaker 1>certain actions within our application.

689
00:31:04.640 --> 00:31:08.279
<v Speaker 2>Security is a never ending battle it is, but rust

690
00:31:08.359 --> 00:31:10.240
<v Speaker 2>gives us the tools to fight it effectively.

691
00:31:10.559 --> 00:31:13.119
<v Speaker 1>Now that we have user authentication in place, are we

692
00:31:13.240 --> 00:31:15.599
<v Speaker 1>ready to build those APIs we've been talking about.

693
00:31:15.920 --> 00:31:18.480
<v Speaker 2>Let's do APIs or the backbone of the modern web?

694
00:31:18.559 --> 00:31:18.920
<v Speaker 1>They are?

695
00:31:19.200 --> 00:31:19.519
<v Speaker 2>Yeah.

696
00:31:19.559 --> 00:31:22.279
<v Speaker 1>So RESTful APIs are a way to structure our web

697
00:31:22.359 --> 00:31:26.599
<v Speaker 1>services to make them easily accessible and usable by other applications, right.

698
00:31:26.519 --> 00:31:29.839
<v Speaker 2>Exactly, think mobile apps, third party integrations, all sorts of things.

699
00:31:29.960 --> 00:31:34.240
<v Speaker 1>The book focuses on using actis web to build RESTful APIs.

700
00:31:34.319 --> 00:31:34.960
<v Speaker 2>Good choice.

701
00:31:35.200 --> 00:31:38.079
<v Speaker 1>Actics is great for that it is, and it highlights

702
00:31:38.079 --> 00:31:42.319
<v Speaker 1>these important concepts like statelessness, caching, and of course logging

703
00:31:42.519 --> 00:31:46.680
<v Speaker 1>all the essentials. So statelessness means that each request is independent, right.

704
00:31:46.559 --> 00:31:49.359
<v Speaker 2>Right, Each request is treated in isolation.

705
00:31:49.039 --> 00:31:52.839
<v Speaker 1>Making it easier to handle a large number of requests concurrently.

706
00:31:53.079 --> 00:31:54.920
<v Speaker 2>Exactly, it's all about scalability.

707
00:31:55.000 --> 00:31:58.759
<v Speaker 1>Caching helps boost performance by storing frequently accessed.

708
00:31:58.359 --> 00:32:00.680
<v Speaker 2>Data right, so we don't have to hit the data every.

709
00:32:00.480 --> 00:32:02.839
<v Speaker 1>Time, reducing the load on our servers.

710
00:32:02.440 --> 00:32:03.839
<v Speaker 2>Ye, keep those servers happy.

711
00:32:03.960 --> 00:32:08.079
<v Speaker 1>And logging provides those valuable insights into what's happening within

712
00:32:08.160 --> 00:32:08.759
<v Speaker 1>our API.

713
00:32:09.000 --> 00:32:11.319
<v Speaker 2>Right, It's like having a window into your application.

714
00:32:11.079 --> 00:32:14.279
<v Speaker 1>Helping us track down those issues and monitor performance.

715
00:32:15.240 --> 00:32:16.160
<v Speaker 2>Gotta love logs.

716
00:32:16.400 --> 00:32:19.279
<v Speaker 1>The book even touches on techniques like code on demand,

717
00:32:20.160 --> 00:32:22.079
<v Speaker 1>which sounds pretty powerful.

718
00:32:22.400 --> 00:32:25.519
<v Speaker 2>Code on demand is really interesting, it is. Yeah, it

719
00:32:25.640 --> 00:32:29.839
<v Speaker 2>lets you send code from the server to the client okay,

720
00:32:29.880 --> 00:32:30.680
<v Speaker 2>to be executed.

721
00:32:31.039 --> 00:32:31.559
<v Speaker 1>Interesting.

722
00:32:31.640 --> 00:32:34.200
<v Speaker 2>Yeah, it can be really powerful, Okay, but it also

723
00:32:34.240 --> 00:32:36.039
<v Speaker 2>comes with some security risks.

724
00:32:36.119 --> 00:32:37.079
<v Speaker 1>So you got to be careful.

725
00:32:37.160 --> 00:32:38.160
<v Speaker 2>Oh yeah, definitely.

726
00:32:38.240 --> 00:32:39.640
<v Speaker 1>Okay, So let's talk about.

727
00:32:39.359 --> 00:32:41.960
<v Speaker 2>Testing, okay, testing one, two, three.

728
00:32:42.119 --> 00:32:45.119
<v Speaker 1>We build all this amazing functionality, but how do we

729
00:32:45.279 --> 00:32:48.400
<v Speaker 1>actually ensure that it works as expected?

730
00:32:48.480 --> 00:32:50.880
<v Speaker 2>Testing is crucial. Yeah, you got to make sure your

731
00:32:50.920 --> 00:32:52.759
<v Speaker 2>code actually does what you think it does.

732
00:32:53.200 --> 00:32:56.839
<v Speaker 1>So Rust has excellent support for both unit testing right

733
00:32:56.880 --> 00:32:59.880
<v Speaker 1>where you test individual components in isolation.

734
00:32:59.720 --> 00:33:02.240
<v Speaker 2>Ye break it down into smaller pieces.

735
00:33:01.880 --> 00:33:05.319
<v Speaker 1>And functional testing okay, where you test the application.

736
00:33:04.920 --> 00:33:07.000
<v Speaker 2>As a whole, so testing the whole system from end

737
00:33:07.039 --> 00:33:07.359
<v Speaker 2>to end.

738
00:33:07.480 --> 00:33:10.759
<v Speaker 1>The book dedicates an entire chapter to testing that important.

739
00:33:11.000 --> 00:33:15.680
<v Speaker 1>It walks through unit testing individual modules using Rust's built

740
00:33:15.680 --> 00:33:19.119
<v Speaker 1>in testing framework, and then it dives into functional testing

741
00:33:19.279 --> 00:33:21.279
<v Speaker 1>using tools like Postman and Newman.

742
00:33:21.680 --> 00:33:24.799
<v Speaker 2>Ah, Postman and Newman great tools for API testing, So

743
00:33:24.880 --> 00:33:28.559
<v Speaker 2>Postman is a popular tool for testing APIs. Yeah, it's

744
00:33:28.599 --> 00:33:29.599
<v Speaker 2>like the industry standard.

745
00:33:29.720 --> 00:33:33.960
<v Speaker 1>It allows you to create collections of requests, define assertions

746
00:33:34.000 --> 00:33:37.880
<v Speaker 1>to verify the responses, and even automate the execution of

747
00:33:37.920 --> 00:33:38.559
<v Speaker 1>those tests.

748
00:33:38.680 --> 00:33:40.680
<v Speaker 2>Yeah. You can even run those tests for the command

749
00:33:40.680 --> 00:33:43.640
<v Speaker 2>line using nimen oh wow, which is great for continuous

750
00:33:43.640 --> 00:33:44.759
<v Speaker 2>integration and delivery.

751
00:33:44.880 --> 00:33:47.599
<v Speaker 1>So you can essentially automate the testing of your entire

752
00:33:47.640 --> 00:33:51.279
<v Speaker 1>API pretty much. Yeah, ensuring that everything keeps working as

753
00:33:51.319 --> 00:33:53.319
<v Speaker 1>you continue to develop and add new features.

754
00:33:53.400 --> 00:33:54.640
<v Speaker 2>It's all about automation.

755
00:33:55.000 --> 00:33:58.240
<v Speaker 1>That's incredibly powerful. It is, so it takes a lot

756
00:33:58.279 --> 00:34:00.680
<v Speaker 1>of that manual effort and guesswork out of testing.

757
00:34:00.759 --> 00:34:03.200
<v Speaker 2>Yeah. It frees you up to focus on the fun stuff, right.

758
00:34:03.119 --> 00:34:05.559
<v Speaker 1>And it allows us to catch those errors early and

759
00:34:05.640 --> 00:34:08.199
<v Speaker 1>keep our application stable and reliable as it grows.

760
00:34:08.239 --> 00:34:08.760
<v Speaker 2>Exactly.

761
00:34:09.239 --> 00:34:10.840
<v Speaker 1>Wow. Rust truly seems to.

762
00:34:10.800 --> 00:34:13.679
<v Speaker 2>Have it all. It does it does from powerful.

763
00:34:13.280 --> 00:34:18.239
<v Speaker 1>Language features and robust libraries to comprehensive tooling and a

764
00:34:18.280 --> 00:34:19.760
<v Speaker 1>strong emphasis on testing.

765
00:34:19.840 --> 00:34:20.800
<v Speaker 2>It's the whole package.

766
00:34:21.000 --> 00:34:23.519
<v Speaker 1>It feels like it was designed with the developers in mind.

767
00:34:23.719 --> 00:34:26.679
<v Speaker 2>It was. It was definitely built by developers for developers.

768
00:34:26.840 --> 00:34:29.199
<v Speaker 1>So to our listeners, we hope this deep dive has

769
00:34:29.239 --> 00:34:31.480
<v Speaker 1>sparked your own curiosity about Rust.

770
00:34:31.800 --> 00:34:33.440
<v Speaker 2>Yeah, go out there and give it a try.

771
00:34:33.559 --> 00:34:36.400
<v Speaker 1>It's a language that's reshaping the landscape of web development.

772
00:34:36.519 --> 00:34:38.159
<v Speaker 1>It really is, and we can't wait to see what

773
00:34:38.199 --> 00:34:39.599
<v Speaker 1>incredible things you create with it.

774
00:34:39.719 --> 00:34:41.599
<v Speaker 2>Yeah, the possibilities are endless.

775
00:34:41.800 --> 00:34:44.880
<v Speaker 1>Until next time, Happy coding, Happy coding.