WEBVTT

1
00:00:00.040 --> 00:00:02.279
<v Speaker 1>Hey everyone, and welcome to another deep dive.

2
00:00:02.439 --> 00:00:03.720
<v Speaker 2>Always fun to do these.

3
00:00:03.960 --> 00:00:07.759
<v Speaker 1>Today we're diving into ember data. It's a JavaScript library

4
00:00:07.799 --> 00:00:11.679
<v Speaker 1>that really helps with managing data in web applications.

5
00:00:11.839 --> 00:00:13.400
<v Speaker 2>Yeah, for sure, we're going to.

6
00:00:13.400 --> 00:00:17.199
<v Speaker 1>Be looking at excerpts from pro ember Data. Getting mber

7
00:00:17.280 --> 00:00:20.160
<v Speaker 1>Data to Work with Your API by David Tang sounds

8
00:00:20.199 --> 00:00:23.120
<v Speaker 1>good and basically our mission today is try and figure

9
00:00:23.120 --> 00:00:27.640
<v Speaker 1>out what is ember data all about, what it's key components,

10
00:00:28.120 --> 00:00:30.879
<v Speaker 1>and how does it make talking to APIs a much

11
00:00:30.920 --> 00:00:32.640
<v Speaker 1>smoother and easier experience.

12
00:00:32.840 --> 00:00:35.759
<v Speaker 2>Yeah, it's a really powerful tool. I think that's for sure.

13
00:00:36.359 --> 00:00:40.520
<v Speaker 2>Without something like ember Data, developers would have to wrestle

14
00:00:40.560 --> 00:00:42.880
<v Speaker 2>with a lot of manual beta handling, right, and that

15
00:00:42.920 --> 00:00:46.719
<v Speaker 2>can quickly become really complex and error prone.

16
00:00:46.759 --> 00:00:49.520
<v Speaker 1>Absolutely. Okay, well let's jump into it. Let's start with

17
00:00:49.560 --> 00:00:53.200
<v Speaker 1>the basics. Ok. What's the big idea behind mber Data's architecture.

18
00:00:53.600 --> 00:00:57.840
<v Speaker 2>So at its core, mber Data acts as a bridge

19
00:00:58.000 --> 00:01:01.880
<v Speaker 2>between your front end application and the back end API.

20
00:01:02.560 --> 00:01:07.159
<v Speaker 1>It simplifies those data interactions much like a universal travel

21
00:01:07.200 --> 00:01:11.439
<v Speaker 1>adapter helps you plug your devices into different outlets around

22
00:01:11.439 --> 00:01:11.799
<v Speaker 1>the world.

23
00:01:11.879 --> 00:01:15.000
<v Speaker 2>I like that analogy, sooth. It's adapting our front end

24
00:01:15.040 --> 00:01:18.079
<v Speaker 2>to work with all these different APIs, no matter how

25
00:01:18.640 --> 00:01:21.239
<v Speaker 2>how they're structured or what their quirks are exactly.

26
00:01:21.599 --> 00:01:24.280
<v Speaker 1>Yeah. And one of the central concepts in EMBER data

27
00:01:24.439 --> 00:01:25.000
<v Speaker 1>is the store.

28
00:01:25.280 --> 00:01:25.640
<v Speaker 2>Okay.

29
00:01:25.760 --> 00:01:30.000
<v Speaker 1>It's essentially the brain of your applications data management system.

30
00:01:30.120 --> 00:01:30.359
<v Speaker 2>Okay.

31
00:01:30.480 --> 00:01:33.480
<v Speaker 1>Think of it as like a central repository where all

32
00:01:33.480 --> 00:01:38.239
<v Speaker 1>of your data lives. It ensures consistency and it prevents duplication.

33
00:01:38.599 --> 00:01:41.040
<v Speaker 2>So the store is really important because it's preventing us

34
00:01:41.040 --> 00:01:44.159
<v Speaker 2>from having multiple copies of the same data floating.

35
00:01:43.840 --> 00:01:48.519
<v Speaker 1>Around exactly precisely. The store uses what's called an identity

36
00:01:48.560 --> 00:01:51.640
<v Speaker 1>map to keep track of all of the data records,

37
00:01:52.120 --> 00:01:55.920
<v Speaker 1>guaranteeing that you're always working with a single authoritative source

38
00:01:55.920 --> 00:01:56.400
<v Speaker 1>of truth.

39
00:01:56.920 --> 00:01:57.879
<v Speaker 2>That makes a lot of sense.

40
00:01:58.120 --> 00:02:00.400
<v Speaker 1>Yeah, Now, how does MBER data actually cannet to all

41
00:02:00.439 --> 00:02:02.879
<v Speaker 1>these different APIs. They're not all built the same way.

42
00:02:02.959 --> 00:02:07.120
<v Speaker 2>That's where adapters come in. They handle the specific details

43
00:02:07.200 --> 00:02:11.319
<v Speaker 2>of communicating with a particular API, like figuring out how

44
00:02:11.319 --> 00:02:15.719
<v Speaker 2>to send requests and receve responses in the correct format.

45
00:02:15.960 --> 00:02:18.120
<v Speaker 1>So the adapter is kind of like the translator. Yes,

46
00:02:18.120 --> 00:02:21.120
<v Speaker 1>it's making sure that our MBER app can speak to

47
00:02:21.159 --> 00:02:23.319
<v Speaker 1>all these different exactly ATI dialects.

48
00:02:23.360 --> 00:02:24.159
<v Speaker 2>ATI dialects.

49
00:02:24.199 --> 00:02:27.599
<v Speaker 1>Yeah, okay, what about the data itself? How does mber

50
00:02:27.680 --> 00:02:31.240
<v Speaker 1>data actually represent all these different types of information?

51
00:02:31.479 --> 00:02:35.479
<v Speaker 2>So, just like a database schema, mber data uses models

52
00:02:35.919 --> 00:02:39.400
<v Speaker 2>to represent the structure of your data. Each model has

53
00:02:39.639 --> 00:02:45.159
<v Speaker 2>attributes okay, with specific data types like strings, numbers, or dates.

54
00:02:45.280 --> 00:02:48.960
<v Speaker 1>So attributes are like defining the fields or columns in

55
00:02:48.960 --> 00:02:50.479
<v Speaker 1>a database table. Yeah, exactly.

56
00:02:51.080 --> 00:02:54.240
<v Speaker 2>And each attribute can have what's called a transform associated

57
00:02:54.280 --> 00:02:57.400
<v Speaker 2>with it, which ensures that the data is properly formatted

58
00:02:57.599 --> 00:03:00.719
<v Speaker 2>both when sending it to the API and it back.

59
00:03:00.840 --> 00:03:05.240
<v Speaker 1>So transforms are really important for maintaining consistency. Yes, like

60
00:03:05.319 --> 00:03:07.960
<v Speaker 1>making sure dates are format the right way before we

61
00:03:08.000 --> 00:03:08.879
<v Speaker 1>send them to the API.

62
00:03:09.080 --> 00:03:11.719
<v Speaker 2>Exactly. Now, the book that we're looking at today actually

63
00:03:11.719 --> 00:03:15.319
<v Speaker 2>dives into several different types of adapters. Each adapter has

64
00:03:15.360 --> 00:03:18.520
<v Speaker 2>its own strengths, and it's kind of suited for specific

65
00:03:18.639 --> 00:03:22.879
<v Speaker 2>API styles okay. One very common adapter is the rest adapter.

66
00:03:23.080 --> 00:03:27.039
<v Speaker 1>Okay, So if I'm working with just a standard RESTful API,

67
00:03:27.319 --> 00:03:28.759
<v Speaker 1>RESTADA is probably what I want to go with.

68
00:03:28.919 --> 00:03:31.719
<v Speaker 2>Yeah, most likely. Yeah, But let's say you're working with

69
00:03:31.719 --> 00:03:37.400
<v Speaker 2>an API that strictly adheres to the json dot API specification. Okay,

70
00:03:37.759 --> 00:03:40.960
<v Speaker 2>that's a specification that's known for its strong emphasis on

71
00:03:41.120 --> 00:03:42.800
<v Speaker 2>convention and consistency.

72
00:03:43.199 --> 00:03:45.360
<v Speaker 1>Ah, so it's like a little more rigorous than just

73
00:03:45.439 --> 00:03:47.120
<v Speaker 1>a typical rest API.

74
00:03:47.240 --> 00:03:49.960
<v Speaker 2>It is. Yeah, and for those scenarios you would use

75
00:03:50.000 --> 00:03:53.240
<v Speaker 2>the Jason APA adapter. It's designed to handle all the

76
00:03:53.280 --> 00:03:58.240
<v Speaker 2>specific nuances of Jason dot apia like it's strict format

77
00:03:58.280 --> 00:04:03.240
<v Speaker 2>for URL's diference for pat cch over put for updates,

78
00:04:03.759 --> 00:04:07.599
<v Speaker 2>and built in support for efficiently loading relationships between data.

79
00:04:07.840 --> 00:04:10.919
<v Speaker 1>Gotcha, So rest adapter for common rest APIs, it's Jason

80
00:04:10.960 --> 00:04:14.639
<v Speaker 1>ap adapter for following the Jason dot apispeck exactly. Okay.

81
00:04:14.759 --> 00:04:18.560
<v Speaker 2>You also have the Active Model adapter, which is specifically

82
00:04:18.560 --> 00:04:21.600
<v Speaker 2>designed to work seamlessly with APIs that are built using

83
00:04:21.680 --> 00:04:24.079
<v Speaker 2>Ruby on Rails Active Model framework.

84
00:04:24.160 --> 00:04:27.439
<v Speaker 1>Cool. So that handles all the sending of data. Now,

85
00:04:27.439 --> 00:04:31.399
<v Speaker 1>what about receiving data back from the API? I understand

86
00:04:31.519 --> 00:04:35.000
<v Speaker 1>Mber Data uses something called serializers exactly. Yeah.

87
00:04:35.040 --> 00:04:39.199
<v Speaker 2>Serializers translate the data received from the API into a

88
00:04:39.279 --> 00:04:43.639
<v Speaker 2>format that mber data can understand. They handle both serialization,

89
00:04:43.959 --> 00:04:47.279
<v Speaker 2>which is preparing data to be sent out, and normalization,

90
00:04:47.399 --> 00:04:50.160
<v Speaker 2>which is taking that incoming data and kind of fitting

91
00:04:50.199 --> 00:04:51.439
<v Speaker 2>it into the MBER data store.

92
00:04:51.759 --> 00:04:54.199
<v Speaker 1>So it's this two way translation process to make sure

93
00:04:54.199 --> 00:04:56.879
<v Speaker 1>that our front end and the API can speak to

94
00:04:56.920 --> 00:05:00.199
<v Speaker 1>each other exactly clearly. What are some of the the

95
00:05:00.240 --> 00:05:03.120
<v Speaker 1>built in serializers that mber data offers.

96
00:05:03.600 --> 00:05:06.600
<v Speaker 2>So the json serializer is the most basic one, okay.

97
00:05:06.879 --> 00:05:10.839
<v Speaker 2>It works well with simple API responses where the JSON

98
00:05:10.959 --> 00:05:14.519
<v Speaker 2>keys directly map to your ember model attributes.

99
00:05:14.560 --> 00:05:15.560
<v Speaker 1>Let's appreciate forward.

100
00:05:15.680 --> 00:05:19.639
<v Speaker 2>Yeah, okay. What about if we have a more complicated API, Yeah,

101
00:05:19.680 --> 00:05:23.480
<v Speaker 2>what about then you might consider using the rest serializer.

102
00:05:24.040 --> 00:05:26.920
<v Speaker 2>It adds a little bit more structure to the data

103
00:05:27.000 --> 00:05:29.680
<v Speaker 2>by using root keys that correspond to your model names.

104
00:05:29.879 --> 00:05:30.360
<v Speaker 1>Gotcha.

105
00:05:30.399 --> 00:05:34.079
<v Speaker 2>It also supports sideloading, which allows you to include related

106
00:05:34.160 --> 00:05:37.600
<v Speaker 2>data in a single response, which reduces the need for

107
00:05:37.800 --> 00:05:39.199
<v Speaker 2>multiple API calls.

108
00:05:39.319 --> 00:05:41.680
<v Speaker 1>So it helps to streamline data retrieval and it probably

109
00:05:41.680 --> 00:05:42.839
<v Speaker 1>improves performance.

110
00:05:42.519 --> 00:05:43.120
<v Speaker 2>Y exactly.

111
00:05:43.160 --> 00:05:43.439
<v Speaker 1>Okay.

112
00:05:43.439 --> 00:05:45.160
<v Speaker 2>And then you have the third one, which is the

113
00:05:45.240 --> 00:05:48.240
<v Speaker 2>Jason a P serializer. Okay, And this is specifically designed

114
00:05:48.240 --> 00:05:52.480
<v Speaker 2>to handle responses that strictly follow the json dot API specification.

115
00:05:53.000 --> 00:05:57.959
<v Speaker 2>It expects a very specific format for resources, relationships and sideloading.

116
00:05:58.160 --> 00:06:01.759
<v Speaker 1>Gotcha. So json a P serial if our API is

117
00:06:01.800 --> 00:06:05.920
<v Speaker 1>designed according to json dot API exactly. Okay. Cool. So

118
00:06:06.240 --> 00:06:08.240
<v Speaker 1>now one of the things that I'm seeing here is

119
00:06:09.160 --> 00:06:14.040
<v Speaker 1>mber data is really powerful because it's so flexible it is,

120
00:06:14.439 --> 00:06:16.519
<v Speaker 1>And the book really spends a lot of time talking

121
00:06:16.519 --> 00:06:21.399
<v Speaker 1>about how you can customize adapters and serializers to handle

122
00:06:21.439 --> 00:06:25.759
<v Speaker 1>APIs that don't necessarily follow these standard conventions exactly. What

123
00:06:25.839 --> 00:06:28.240
<v Speaker 1>are some common scenarios where we might need to kind

124
00:06:28.279 --> 00:06:30.120
<v Speaker 1>of roll off our sleeves and do some customization.

125
00:06:30.480 --> 00:06:35.800
<v Speaker 2>Well, for instance, some APIs might use singular nouns in

126
00:06:35.839 --> 00:06:39.480
<v Speaker 2>their URLs instead of the standard plural form, or they

127
00:06:39.560 --> 00:06:42.800
<v Speaker 2>might have naming inconsistencies between their Jason keys.

128
00:06:42.720 --> 00:06:45.839
<v Speaker 1>Right, because APIs will often have their own little works

129
00:06:45.839 --> 00:06:49.600
<v Speaker 1>and naming conventions. Yeah, so how do we handle those situations?

130
00:06:49.879 --> 00:06:54.480
<v Speaker 2>We can guide mber data by overwriting specific methods in

131
00:06:54.519 --> 00:06:58.800
<v Speaker 2>our adapters and serializers. For example, if an API uses

132
00:06:58.920 --> 00:07:04.040
<v Speaker 2>companied as a foreign key in the response, but your

133
00:07:04.160 --> 00:07:08.240
<v Speaker 2>ember model is expecting a relationship named company, we can

134
00:07:08.319 --> 00:07:11.319
<v Speaker 2>actually tell ember data how to map that foreign key

135
00:07:12.000 --> 00:07:13.680
<v Speaker 2>to the appropriate relationship.

136
00:07:13.920 --> 00:07:16.560
<v Speaker 1>It's like we're bridging the gap between what the API

137
00:07:16.720 --> 00:07:19.680
<v Speaker 1>gives us exactly what Ember data is expecting.

138
00:07:19.360 --> 00:07:23.319
<v Speaker 2>Exactly, okay, And these customizations can actually get quite complex,

139
00:07:23.839 --> 00:07:28.120
<v Speaker 2>especially when you're dealing with nested data structures or non

140
00:07:28.240 --> 00:07:32.399
<v Speaker 2>standard error responses. The book does a great job of

141
00:07:32.480 --> 00:07:35.199
<v Speaker 2>walking through those situations and providing solutions.

142
00:07:35.319 --> 00:07:37.879
<v Speaker 1>Okay, I think that's a really good overview the kind

143
00:07:37.920 --> 00:07:40.519
<v Speaker 1>of the foundational concepts here. Yeah, maybe we should pause

144
00:07:40.560 --> 00:07:41.160
<v Speaker 1>here for a second.

145
00:07:41.279 --> 00:07:43.680
<v Speaker 2>Yeah, let's take a break and let's all sink in. Yeah,

146
00:07:43.800 --> 00:07:44.360
<v Speaker 2>good idea.

147
00:07:44.480 --> 00:07:47.319
<v Speaker 1>Okay, sounds good. All right, so welcome back. Yeah, I'm

148
00:07:47.319 --> 00:07:50.839
<v Speaker 1>excited to dig into some real world examples here meet

149
00:07:51.079 --> 00:07:54.839
<v Speaker 1>and actually see how all these ember data customizations work

150
00:07:54.959 --> 00:07:55.560
<v Speaker 1>in code.

151
00:07:55.879 --> 00:07:58.800
<v Speaker 2>Yeah, the book has some great hands on scenarios, and

152
00:07:58.839 --> 00:08:02.319
<v Speaker 2>I think walking through those really solidify our understanding.

153
00:08:02.759 --> 00:08:05.439
<v Speaker 1>So let's start with one that I found pretty interesting. Okay,

154
00:08:05.680 --> 00:08:10.240
<v Speaker 1>it's the books example of actually using local storage as

155
00:08:10.279 --> 00:08:12.879
<v Speaker 1>a data source. Yeah, that seems like a kind of

156
00:08:13.000 --> 00:08:15.439
<v Speaker 1>unconventional use case for mber data.

157
00:08:15.519 --> 00:08:18.120
<v Speaker 2>It is, it is, but it's a great illustration of

158
00:08:18.160 --> 00:08:22.759
<v Speaker 2>how adaptable mber data can be. So instead of interacting

159
00:08:22.879 --> 00:08:26.319
<v Speaker 2>with a remote API, we can actually use this adapter

160
00:08:26.439 --> 00:08:30.240
<v Speaker 2>system to store and retrieve data directly in the user's browser.

161
00:08:30.399 --> 00:08:34.759
<v Speaker 1>So no network requests, yeah, just data manipulation locally. So

162
00:08:35.080 --> 00:08:37.799
<v Speaker 1>what are the key differences when we're setting up mber

163
00:08:37.919 --> 00:08:39.919
<v Speaker 1>data to use local storage.

164
00:08:40.000 --> 00:08:42.639
<v Speaker 2>Yeah, so the core concepts are the same. Okay, we

165
00:08:42.679 --> 00:08:46.559
<v Speaker 2>still have models, adapters, and serializers. Okay, the key difference

166
00:08:46.679 --> 00:08:50.399
<v Speaker 2>is how the adapter actually interacts with the data source. Okay,

167
00:08:50.639 --> 00:08:54.879
<v Speaker 2>so instead of making these AJAX calls, our custom adapter

168
00:08:55.120 --> 00:08:59.039
<v Speaker 2>for local storage is going to use methods like local

169
00:08:59.120 --> 00:09:03.000
<v Speaker 2>storage dot item, local storage, dot set item, and things

170
00:09:03.080 --> 00:09:07.639
<v Speaker 2>like that to actually manipulate data in the browser's storage.

171
00:09:07.759 --> 00:09:11.240
<v Speaker 1>Interesting. Yeah, but you know, local storage doesn't have like

172
00:09:12.039 --> 00:09:15.440
<v Speaker 1>the concept of these auto generated ideas like a database would.

173
00:09:15.879 --> 00:09:19.200
<v Speaker 1>So how do we handle that when we're creating new records.

174
00:09:19.399 --> 00:09:23.360
<v Speaker 2>That's a great point, and the book actually outlines a

175
00:09:23.399 --> 00:09:26.480
<v Speaker 2>pretty clever approach. Basically, what you can do is you

176
00:09:26.519 --> 00:09:31.519
<v Speaker 2>can simulate auto incrementing IDs okay by sorting the existing

177
00:09:31.600 --> 00:09:34.360
<v Speaker 2>records in local storage by their ideas and then just

178
00:09:34.600 --> 00:09:37.279
<v Speaker 2>assigning the new record and ID that's one greater than

179
00:09:37.320 --> 00:09:38.639
<v Speaker 2>the highest existing idea.

180
00:09:38.799 --> 00:09:40.840
<v Speaker 1>Okay, that's neat. Yeah, so we're kind of maintaining this

181
00:09:40.879 --> 00:09:44.480
<v Speaker 1>sequence even just local storage. Yeah. Now, another thing that

182
00:09:44.519 --> 00:09:48.159
<v Speaker 1>I noticed is that local storage treats everything as strings,

183
00:09:48.840 --> 00:09:54.399
<v Speaker 1>but Ember data expects specific data types for attributes. So

184
00:09:54.399 --> 00:09:57.000
<v Speaker 1>how do we make sure that the data is formatic correctly?

185
00:09:57.080 --> 00:09:59.080
<v Speaker 2>So that's where serializers come into play again.

186
00:09:59.159 --> 00:10:00.120
<v Speaker 1>Okay, we would create.

187
00:10:00.159 --> 00:10:04.360
<v Speaker 2>A custom serializer okay that basically handles the conversion between

188
00:10:04.559 --> 00:10:09.120
<v Speaker 2>JavaScript objects and the stringified format used by local storage.

189
00:10:09.480 --> 00:10:13.960
<v Speaker 2>So it's basically like a translator making sure that the data.

190
00:10:13.759 --> 00:10:15.279
<v Speaker 1>Is the data is formatted correctly.

191
00:10:15.279 --> 00:10:16.240
<v Speaker 2>It is formatted correctly.

192
00:10:16.320 --> 00:10:19.840
<v Speaker 1>Yeah, and there's integrity yeah okay cool. Yeah, So that

193
00:10:19.919 --> 00:10:21.200
<v Speaker 1>example I think is really cool.

194
00:10:21.279 --> 00:10:22.519
<v Speaker 2>Yeah, it's a fun one because.

195
00:10:22.279 --> 00:10:26.000
<v Speaker 1>It shows how adaptable the adapter and serializer system is.

196
00:10:26.279 --> 00:10:28.720
<v Speaker 1>It really does in ember data. Yeah, but let's go

197
00:10:28.759 --> 00:10:31.120
<v Speaker 1>back to those nested resource paths. Yeah we were talking

198
00:10:31.120 --> 00:10:35.480
<v Speaker 1>about earlier. The book mentioned something called relationship links, right,

199
00:10:35.759 --> 00:10:37.519
<v Speaker 1>could you elaborate a little bit on what those are?

200
00:10:37.600 --> 00:10:41.519
<v Speaker 2>Certainly, so, relationship links are a way for APIs to

201
00:10:41.519 --> 00:10:48.120
<v Speaker 2>actually provide direct URLs to related resources within a jason response. Okay,

202
00:10:48.240 --> 00:10:51.200
<v Speaker 2>So imagine a scenario where you're fetching a blog post.

203
00:10:51.559 --> 00:10:54.840
<v Speaker 2>Instead of including all of the author's data within the

204
00:10:54.919 --> 00:10:59.080
<v Speaker 2>post's response, the API might just provide a link that

205
00:10:59.159 --> 00:11:01.600
<v Speaker 2>allows you to fetch the author's details separately.

206
00:11:01.720 --> 00:11:03.840
<v Speaker 1>Okay, So it's kind of a way to optimize the

207
00:11:03.919 --> 00:11:04.600
<v Speaker 1>data transfer.

208
00:11:04.679 --> 00:11:06.480
<v Speaker 2>Yeah, it's all about efficiency.

209
00:11:06.000 --> 00:11:08.720
<v Speaker 1>And not repeat things unnecessarily.

210
00:11:08.799 --> 00:11:11.559
<v Speaker 2>And the good news is the rest adapter has built

211
00:11:11.559 --> 00:11:15.759
<v Speaker 2>in support for handling those relationship links, making it really

212
00:11:15.799 --> 00:11:18.720
<v Speaker 2>easy to fetch that related data on demand.

213
00:11:18.919 --> 00:11:19.200
<v Speaker 1>Cool.

214
00:11:19.480 --> 00:11:23.360
<v Speaker 2>Now, not all APIs are designed to provide those convenient links.

215
00:11:23.519 --> 00:11:25.919
<v Speaker 1>So what happens when we run into a situation is

216
00:11:26.360 --> 00:11:30.480
<v Speaker 1>the API is using nested resource paths, but it doesn't

217
00:11:30.480 --> 00:11:32.720
<v Speaker 1>give us those explicit relationship links.

218
00:11:32.799 --> 00:11:37.080
<v Speaker 2>So the book actually provides a solution for this common scenario.

219
00:11:37.279 --> 00:11:43.440
<v Speaker 2>It can override specific normalization methods in our serializers to

220
00:11:43.600 --> 00:11:47.480
<v Speaker 2>kind of guide ember Data on how to construct those

221
00:11:47.519 --> 00:11:52.120
<v Speaker 2>appropriate URLs for fetching the related data.

222
00:11:52.200 --> 00:11:54.960
<v Speaker 1>So we're giving mber data this little Yeah, it's like

223
00:11:55.000 --> 00:11:58.360
<v Speaker 1>a roadmap, roadmap showing it how to navigate through the

224
00:11:58.399 --> 00:11:59.919
<v Speaker 1>nested structure. Yep, okay.

225
00:12:00.080 --> 00:12:03.799
<v Speaker 2>And so this customization basically ensures that ember data can

226
00:12:03.879 --> 00:12:08.240
<v Speaker 2>correctly fetch and associate related data even when the API

227
00:12:08.320 --> 00:12:13.320
<v Speaker 2>doesn't explicitly provide those relationships in the response.

228
00:12:13.000 --> 00:12:16.159
<v Speaker 1>Clearly spelled out exactly. Okay. Cool, And this leads us

229
00:12:16.240 --> 00:12:19.720
<v Speaker 1>very nicely to our real world example here. Yeah, consuming

230
00:12:19.759 --> 00:12:20.639
<v Speaker 1>the Reddit API.

231
00:12:20.960 --> 00:12:23.360
<v Speaker 2>Yes, the Reddit API now, reddit.

232
00:12:23.159 --> 00:12:27.000
<v Speaker 1>It's fun is known for its let's say unique unique

233
00:12:27.039 --> 00:12:28.080
<v Speaker 1>yeah api structure.

234
00:12:28.159 --> 00:12:29.399
<v Speaker 2>Yeah, it's a great test case.

235
00:12:29.200 --> 00:12:32.000
<v Speaker 1>So I'm really curious to see how ember data handles this.

236
00:12:32.080 --> 00:12:34.480
<v Speaker 2>It really demonstrates ember Data's flexibility.

237
00:12:34.720 --> 00:12:36.799
<v Speaker 1>Okay, So the book walks us.

238
00:12:36.679 --> 00:12:40.840
<v Speaker 2>Through creating custom adapters and serializers to interact with the

239
00:12:40.879 --> 00:12:45.799
<v Speaker 2>Reddit API, specifically fetching posts from a subreddit and retrieving

240
00:12:46.519 --> 00:12:47.679
<v Speaker 2>subreddit details.

241
00:12:47.720 --> 00:12:51.639
<v Speaker 1>So we're dealing with nested endpoints, asynchronous relationship exactly, all

242
00:12:51.639 --> 00:12:53.840
<v Speaker 1>those things like typical of a complex API.

243
00:12:54.080 --> 00:12:58.480
<v Speaker 2>Yeah, exactly. And one key takeaway from this example is

244
00:12:58.519 --> 00:13:02.519
<v Speaker 2>that we can create specialized adapters for different aspects of

245
00:13:02.519 --> 00:13:06.120
<v Speaker 2>an API. So in this case, we create separate adapters

246
00:13:06.159 --> 00:13:10.840
<v Speaker 2>for posts and subreddit details, but both of them extend

247
00:13:10.919 --> 00:13:14.159
<v Speaker 2>from this base Reddit adapter that handles kind of the

248
00:13:14.159 --> 00:13:15.080
<v Speaker 2>shared configuration.

249
00:13:15.279 --> 00:13:17.440
<v Speaker 1>So that's a nice way to modularize the code and

250
00:13:17.480 --> 00:13:19.399
<v Speaker 1>keep things organized exactly. Okay.

251
00:13:19.440 --> 00:13:23.799
<v Speaker 2>Yeah, and the Reddit API example also involves serializer customization

252
00:13:23.879 --> 00:13:26.840
<v Speaker 2>as well, because we need to tailor our serializers to

253
00:13:26.919 --> 00:13:32.919
<v Speaker 2>handle the specific format of reddits responses, which involves extracting

254
00:13:33.320 --> 00:13:36.639
<v Speaker 2>relevant data from these nested structures and then mapping it

255
00:13:36.720 --> 00:13:41.480
<v Speaker 2>correctly to our ember models. The book demonstrates the use

256
00:13:41.559 --> 00:13:45.440
<v Speaker 2>of methods like extracted attribute.

257
00:13:45.159 --> 00:13:48.399
<v Speaker 1>And normalized find record response for this purpose.

258
00:13:48.480 --> 00:13:53.559
<v Speaker 2>So it's kind of a combination of adapter and serializer magic.

259
00:13:53.440 --> 00:13:59.279
<v Speaker 1>Exactly working together. Yeah, to tame that Reddit API beast. Okay,

260
00:13:59.600 --> 00:14:03.399
<v Speaker 1>As with any real world API integration, there's bound to

261
00:14:03.440 --> 00:14:05.600
<v Speaker 1>be a few unexpected hiccups along the way.

262
00:14:06.240 --> 00:14:09.639
<v Speaker 2>What kind of hiccups did the Reddit API throw at us?

263
00:14:09.879 --> 00:14:13.200
<v Speaker 1>Well? One issue that the book highlights is that you

264
00:14:13.279 --> 00:14:16.519
<v Speaker 1>might get a warning message that can come up because

265
00:14:16.639 --> 00:14:21.759
<v Speaker 1>of a mismatch between the requested subreddit ID and the

266
00:14:21.840 --> 00:14:24.000
<v Speaker 1>ID that's returned in the API response.

267
00:14:24.200 --> 00:14:26.120
<v Speaker 2>An ID mismatch that could.

268
00:14:26.080 --> 00:14:29.879
<v Speaker 1>Yeah, that can lead to all sorts of confusion and errors. Yeah,

269
00:14:30.039 --> 00:14:33.639
<v Speaker 1>but the book provides a simple fix for this. We

270
00:14:33.759 --> 00:14:38.159
<v Speaker 1>basically update the ID within the normalized fine record response

271
00:14:38.279 --> 00:14:40.440
<v Speaker 1>method to ensure that there's consistency.

272
00:14:40.480 --> 00:14:41.519
<v Speaker 2>So it's a small detail.

273
00:14:41.600 --> 00:14:44.000
<v Speaker 1>Yeah, it's a small thing. It can save you a

274
00:14:44.039 --> 00:14:46.360
<v Speaker 1>lot of headaches. It's one of those things that if

275
00:14:46.399 --> 00:14:48.759
<v Speaker 1>you don't catch it early on, exactly, it'll come back

276
00:14:48.799 --> 00:14:52.480
<v Speaker 1>and bite you. Okay, So the Reddit API example, I

277
00:14:52.519 --> 00:14:56.000
<v Speaker 1>think really shows the power of ember Data. It does

278
00:14:56.200 --> 00:14:59.320
<v Speaker 1>even when we have these really kind of intricate API

279
00:14:59.440 --> 00:15:04.440
<v Speaker 1>structures and all these unexpected quirks, we could still leverage

280
00:15:04.480 --> 00:15:09.039
<v Speaker 1>all the flexibility to create this really smooth and reliable

281
00:15:09.639 --> 00:15:10.799
<v Speaker 1>data interaction layer.

282
00:15:10.960 --> 00:15:14.639
<v Speaker 2>Yeah, and that actually leads us nicely to our last

283
00:15:14.879 --> 00:15:20.200
<v Speaker 2>big topic, which is polymorphic relationships, where a single relationship

284
00:15:20.279 --> 00:15:22.039
<v Speaker 2>can hold records of different types.

285
00:15:22.200 --> 00:15:24.480
<v Speaker 1>Right, so we briefly talked about this before, Yes we did.

286
00:15:24.559 --> 00:15:28.799
<v Speaker 1>Can we actually see how these polymorphic relationships are implemented

287
00:15:29.360 --> 00:15:32.039
<v Speaker 1>in code using the rest serializer?

288
00:15:32.200 --> 00:15:34.480
<v Speaker 2>Absolutely? Okay, So let's go back to the example we

289
00:15:34.559 --> 00:15:38.120
<v Speaker 2>talked about earlier of a user having multiple purchase products,

290
00:15:38.600 --> 00:15:41.480
<v Speaker 2>which could be courses or books. So that of many

291
00:15:41.519 --> 00:15:44.679
<v Speaker 2>relationship needs to be able to accommodate both of those

292
00:15:44.679 --> 00:15:45.440
<v Speaker 2>product types.

293
00:15:45.799 --> 00:15:47.960
<v Speaker 1>So it's a relationship where the type isn't.

294
00:15:47.720 --> 00:15:49.600
<v Speaker 2>Fixed exactly, the type is not fixed.

295
00:15:49.639 --> 00:15:49.879
<v Speaker 1>Okay.

296
00:15:49.960 --> 00:15:54.360
<v Speaker 2>So ember Data handles this beautifully using the polymorphic option

297
00:15:55.080 --> 00:15:57.960
<v Speaker 2>when we define that relationship in our model. So in

298
00:15:58.000 --> 00:16:01.919
<v Speaker 2>our user model, we would define the purchase products relationship

299
00:16:02.039 --> 00:16:07.120
<v Speaker 2>like this at has polymorphic as sink it o true

300
00:16:07.159 --> 00:16:08.639
<v Speaker 2>purchased products.

301
00:16:09.039 --> 00:16:12.240
<v Speaker 1>So the polymorphic that's the key that tells ember data

302
00:16:12.840 --> 00:16:15.919
<v Speaker 1>that this relationship that it can hold can hold records

303
00:16:15.919 --> 00:16:19.960
<v Speaker 1>of any type that inherits from our base product model.

304
00:16:20.080 --> 00:16:23.120
<v Speaker 2>Yeah, so both the course and book models could be

305
00:16:23.159 --> 00:16:25.639
<v Speaker 2>part of this purchase products relationship as long as they

306
00:16:25.679 --> 00:16:27.639
<v Speaker 2>both extend that product model.

307
00:16:28.120 --> 00:16:29.039
<v Speaker 1>That's really elegant.

308
00:16:29.159 --> 00:16:30.120
<v Speaker 2>Yeah, that's pretty cool.

309
00:16:30.679 --> 00:16:35.399
<v Speaker 1>So how does mber data actually know which specific model

310
00:16:35.480 --> 00:16:39.559
<v Speaker 1>to use when it's fetching data for that relationship?

311
00:16:39.799 --> 00:16:44.480
<v Speaker 2>So by default, the rest serializer looks for a key

312
00:16:44.600 --> 00:16:48.480
<v Speaker 2>named product type in the API response to determine the

313
00:16:48.600 --> 00:16:51.240
<v Speaker 2>type of each product. So let's imagine an API end

314
00:16:51.240 --> 00:16:54.840
<v Speaker 2>point that returns all of a user's purchase products. The

315
00:16:54.879 --> 00:16:59.360
<v Speaker 2>response might look something like this purchase products one type

316
00:17:00.159 --> 00:17:06.519
<v Speaker 2>course title introduction to mber data type book title pro

317
00:17:06.759 --> 00:17:07.599
<v Speaker 2>ember data.

318
00:17:07.720 --> 00:17:11.440
<v Speaker 1>Okay, so the type property there is indicating whether it's

319
00:17:11.480 --> 00:17:14.680
<v Speaker 1>a course or a book. So ember data is using

320
00:17:14.720 --> 00:17:17.640
<v Speaker 1>that informations to know which model.

321
00:17:17.319 --> 00:17:20.079
<v Speaker 2>To stantiate the appropriate marmali.

322
00:17:20.599 --> 00:17:25.200
<v Speaker 1>But what if the API doesn't follow that product type convention?

323
00:17:26.079 --> 00:17:27.480
<v Speaker 1>What if he uses like a different key.

324
00:17:27.759 --> 00:17:30.599
<v Speaker 2>Yeah, so that's where customers like to make it altogether.

325
00:17:31.559 --> 00:17:34.880
<v Speaker 2>If the API uses a different key, we can simply

326
00:17:35.000 --> 00:17:39.839
<v Speaker 2>override the key for polymorphic type method in our serializer

327
00:17:40.359 --> 00:17:41.559
<v Speaker 2>to tell Ember data.

328
00:17:41.880 --> 00:17:44.119
<v Speaker 1>Hey, this is the key we're telling Ember data.

329
00:17:44.359 --> 00:17:47.599
<v Speaker 2>You need to look for it exactly. And if the

330
00:17:47.680 --> 00:17:51.559
<v Speaker 2>API uses like a completely different way of representing these

331
00:17:51.599 --> 00:17:56.119
<v Speaker 2>polymorphic relationships, we have the flexibility to override the extra

332
00:17:56.319 --> 00:18:00.640
<v Speaker 2>polymorphic relationship method and handle those customs scenarios.

333
00:18:00.880 --> 00:18:05.160
<v Speaker 1>So, no matter how the API structures those relationships exactly,

334
00:18:05.279 --> 00:18:08.440
<v Speaker 1>Amber Data gives us the tools, the tools to adapt

335
00:18:08.480 --> 00:18:11.359
<v Speaker 1>and interpret them correctly. Yep, and that's true for both

336
00:18:11.599 --> 00:18:12.519
<v Speaker 1>has made.

337
00:18:12.200 --> 00:18:14.839
<v Speaker 2>The same principles belongs to the apply to polymorphic belongs

338
00:18:14.839 --> 00:18:15.839
<v Speaker 2>to relationships as well.

339
00:18:15.880 --> 00:18:19.880
<v Speaker 1>Okay, it's all about having that flexibility to map these

340
00:18:19.880 --> 00:18:22.359
<v Speaker 1>different API structures exactly into.

341
00:18:22.160 --> 00:18:23.480
<v Speaker 2>Our Ember models exactly.

342
00:18:23.720 --> 00:18:26.720
<v Speaker 1>Okay. Cool, So I feel like we really Yeah, we

343
00:18:26.839 --> 00:18:29.880
<v Speaker 1>dug deep, dug deep into the nuts and bolts here. Yeah,

344
00:18:29.960 --> 00:18:32.400
<v Speaker 1>I'm starting to feel much more confident. That's great to

345
00:18:32.440 --> 00:18:34.720
<v Speaker 1>hear and Amberdida's capabilities.

346
00:18:35.079 --> 00:18:37.799
<v Speaker 2>Yeah, I think we've earned a short break okay before

347
00:18:37.839 --> 00:18:38.680
<v Speaker 2>we wrap things up.

348
00:18:38.759 --> 00:18:39.279
<v Speaker 1>Sounds good.

349
00:18:39.480 --> 00:18:41.559
<v Speaker 2>So when we return, we'll just share a couple of

350
00:18:41.599 --> 00:18:45.599
<v Speaker 2>final thoughts and leave you with some resources to continue. Okay,

351
00:18:45.920 --> 00:18:47.359
<v Speaker 2>your Mber Data exploration.

352
00:18:47.599 --> 00:18:50.000
<v Speaker 1>Okay, so we're back for the final part of our

353
00:18:50.200 --> 00:18:54.920
<v Speaker 1>Mber data deep dive. Yeah, we've gone through a lot. Yeah,

354
00:18:55.279 --> 00:18:58.359
<v Speaker 1>we went through those core con steps info, we delved

355
00:18:58.359 --> 00:19:02.640
<v Speaker 1>into customizations. We even tackle the Reddit api. We did.

356
00:19:02.920 --> 00:19:03.000
<v Speaker 2>So.

357
00:19:03.240 --> 00:19:06.559
<v Speaker 1>Hopefully you're feeling empowered now, I hope so to handle

358
00:19:06.599 --> 00:19:09.640
<v Speaker 1>all these data interactions in your Ember apps.

359
00:19:09.839 --> 00:19:11.200
<v Speaker 2>Yeah, for sure, with.

360
00:19:11.200 --> 00:19:12.240
<v Speaker 1>A little more confidence.

361
00:19:12.319 --> 00:19:12.960
<v Speaker 2>Absolutely.

362
00:19:13.039 --> 00:19:17.079
<v Speaker 1>Now before we wrap up any parting words of wisdom

363
00:19:17.559 --> 00:19:20.000
<v Speaker 1>for our listeners out there, Yeah, I would say you're

364
00:19:20.039 --> 00:19:21.160
<v Speaker 1>ready to just become.

365
00:19:21.000 --> 00:19:23.079
<v Speaker 2>One of the most important things.

366
00:19:22.880 --> 00:19:25.079
<v Speaker 1>Ember data masters to remember.

367
00:19:24.799 --> 00:19:28.839
<v Speaker 2>Is to embrace that flexibility that Mber data offers. Okay,

368
00:19:29.240 --> 00:19:33.920
<v Speaker 2>don't hesitate to customize those adapters and serializers to perfectly

369
00:19:33.960 --> 00:19:36.680
<v Speaker 2>match the structure and conventions of your API.

370
00:19:36.920 --> 00:19:40.359
<v Speaker 1>So customization is really like having It's like having a

371
00:19:40.400 --> 00:19:41.680
<v Speaker 1>set of precision tools.

372
00:19:41.720 --> 00:19:44.279
<v Speaker 2>It's a good set of tools, yeah, that you can

373
00:19:44.400 --> 00:19:49.000
<v Speaker 2>use to really tailor Examber data to your exact needs.

374
00:19:49.200 --> 00:19:54.079
<v Speaker 1>Yeah, and remember through testing, right is crucial whenever you're customizing, Yes,

375
00:19:54.440 --> 00:19:59.079
<v Speaker 1>test those adapters and serializers both in isolation and through

376
00:19:59.119 --> 00:20:01.960
<v Speaker 1>the Ember Data st just to make sure.

377
00:20:02.240 --> 00:20:04.440
<v Speaker 2>Yeah, to make sure everything's playing nicely.

378
00:20:04.200 --> 00:20:07.240
<v Speaker 1>Everything integrates smoothly and works as expected.

379
00:20:07.359 --> 00:20:09.799
<v Speaker 2>Testing is our safety net, Yes, it is. It's making

380
00:20:09.880 --> 00:20:15.079
<v Speaker 2>sure that those custom data interactions are actually robust and reliable.

381
00:20:15.319 --> 00:20:17.559
<v Speaker 2>Exactly what resources would you recommend?

382
00:20:17.799 --> 00:20:20.440
<v Speaker 1>Okay? Well, obviously, who want to learn even more?

383
00:20:20.960 --> 00:20:23.680
<v Speaker 2>The book that we've been using as our guide pro

384
00:20:23.839 --> 00:20:26.400
<v Speaker 2>Ember Data by David Tang.

385
00:20:26.519 --> 00:20:29.720
<v Speaker 1>It's been our trustee companion for this whole deep dive

386
00:20:29.880 --> 00:20:33.359
<v Speaker 1>for sure. Are there other resources? Yeah? The official you'd recommend?

387
00:20:33.640 --> 00:20:36.839
<v Speaker 2>Ember Data documentation is always a good reference. It's a

388
00:20:36.880 --> 00:20:41.279
<v Speaker 2>great place to find detailed API info and some guides. Okay,

389
00:20:41.519 --> 00:20:45.119
<v Speaker 2>And don't underestimate the power of the Ember community. They

390
00:20:45.160 --> 00:20:46.519
<v Speaker 2>are incredibly supportive.

391
00:20:46.599 --> 00:20:47.960
<v Speaker 1>The Ember community is and.

392
00:20:48.000 --> 00:20:49.920
<v Speaker 2>Always willing to share knowledge.

393
00:20:49.559 --> 00:20:53.799
<v Speaker 1>The fantastic resource true forums and blog posts and conferences.

394
00:20:54.039 --> 00:20:56.039
<v Speaker 1>Any final thoughts before we sign.

395
00:20:55.799 --> 00:20:59.440
<v Speaker 2>Off, just remember that mastering data management in your Ember

396
00:20:59.519 --> 00:21:02.759
<v Speaker 2>application can really be a game changer.

397
00:21:03.000 --> 00:21:03.400
<v Speaker 1>Yeah.

398
00:21:03.480 --> 00:21:08.279
<v Speaker 2>It streamlines development, reduces complexity, and ultimately helps you to

399
00:21:08.319 --> 00:21:10.799
<v Speaker 2>create more robust and efficient application.

400
00:21:11.000 --> 00:21:13.319
<v Speaker 1>I think that's a great point to end on. Well,

401
00:21:13.400 --> 00:21:15.599
<v Speaker 1>it's been a pleasure exploring the world of Ember data

402
00:21:15.720 --> 00:21:16.319
<v Speaker 1>with you today.

403
00:21:16.519 --> 00:21:18.519
<v Speaker 2>Likewise, the pleasure was aline to.

404
00:21:18.519 --> 00:21:20.720
<v Speaker 1>Our listeners out there. Thank you so much for joining

405
00:21:20.759 --> 00:21:23.880
<v Speaker 1>us on this data driven adventure. Thanks everyone, Until next time,

406
00:21:23.920 --> 00:21:24.559
<v Speaker 1>happy coding,