Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
1
00:00:01,140 --> 00:00:02,880
So we already implemented
2
2
00:00:02,880 --> 00:00:05,840
a part of the Forkify application.
3
3
00:00:05,840 --> 00:00:10,320
But at this point, it has no structure whatsoever.
4
4
00:00:10,320 --> 00:00:14,690
And so now it's time to talk about the project architecture,
5
5
00:00:14,690 --> 00:00:19,490
but also about software architecture more in general.
6
6
00:00:19,490 --> 00:00:21,600
Now, we touched on this already
7
7
00:00:21,600 --> 00:00:25,070
in the Mapty application a little bit earlier.
8
8
00:00:25,070 --> 00:00:28,793
But in this lecture, let's now go a little bit deeper.
9
9
00:00:30,310 --> 00:00:32,960
And first of all, why do we even need
10
10
00:00:32,960 --> 00:00:35,653
an architecture when we build software?
11
11
00:00:36,500 --> 00:00:39,900
Well, there are actually multiple reasons.
12
12
00:00:39,900 --> 00:00:43,200
First, the architecture will give our project
13
13
00:00:43,200 --> 00:00:47,350
the structure in which we can then write the code.
14
14
00:00:47,350 --> 00:00:52,350
So just like a house, software also needs a structure.
15
15
00:00:52,690 --> 00:00:55,900
Now in software, structure basically means
16
16
00:00:55,900 --> 00:00:58,750
how we organize and divide the code
17
17
00:00:58,750 --> 00:01:03,190
into different modules, classes, and functions.
18
18
00:01:03,190 --> 00:01:06,070
So all these will basically hold our code
19
19
00:01:06,070 --> 00:01:09,020
together and give it structure.
20
20
00:01:09,020 --> 00:01:11,543
The next reason is maintainability.
21
21
00:01:12,550 --> 00:01:14,800
So when we build a project,
22
22
00:01:14,800 --> 00:01:17,690
we always need to think about the future
23
23
00:01:17,690 --> 00:01:22,290
and keep in mind that the project is never really done.
24
24
00:01:22,290 --> 00:01:24,200
It is never finished.
25
25
00:01:24,200 --> 00:01:27,440
We will always need to change things in the future
26
26
00:01:27,440 --> 00:01:30,570
and we will need to maintain the project.
27
27
00:01:30,570 --> 00:01:35,400
And that only works if the project is nicely structured.
28
28
00:01:35,400 --> 00:01:40,180
Plus, we might even want to add new features to the project,
29
29
00:01:40,180 --> 00:01:42,073
which brings us to expandability.
30
30
00:01:43,370 --> 00:01:46,470
So expandability is basically
31
31
00:01:46,470 --> 00:01:51,300
the ability to easily add new features in the future.
32
32
00:01:51,300 --> 00:01:55,730
And once again, that is only possible with a good structure,
33
33
00:01:55,730 --> 00:01:58,550
and a good overall architecture.
34
34
00:01:58,550 --> 00:02:01,891
So the perfect architecture is basically one
35
35
00:02:01,891 --> 00:02:05,440
that allows for all these three aspects
36
36
00:02:05,440 --> 00:02:10,440
of structure maintainability, and expandability.
37
37
00:02:10,590 --> 00:02:14,280
Now, in order to achieve that perfect architecture,
38
38
00:02:14,280 --> 00:02:19,130
we can of course create our own architecture from scratch.
39
39
00:02:19,130 --> 00:02:23,310
And that's exactly what we did in the Mapty project.
40
40
00:02:23,310 --> 00:02:25,110
However, that only works
41
41
00:02:25,110 --> 00:02:28,810
with a really small project like that one.
42
42
00:02:28,810 --> 00:02:31,620
But when the project grows more complex,
43
43
00:02:31,620 --> 00:02:33,510
then it's going to be very hard
44
44
00:02:33,510 --> 00:02:37,720
to achieve a good architecture completely on our own.
45
45
00:02:37,720 --> 00:02:41,930
And so instead, we can opt for a well established
46
46
00:02:41,930 --> 00:02:44,470
architecture pattern that developers
47
47
00:02:44,470 --> 00:02:48,640
have been using for years, or even for decades.
48
48
00:02:48,640 --> 00:02:52,480
And examples of that are model view controller,
49
49
00:02:52,480 --> 00:02:57,480
model view presenter, flux, and many other architectures.
50
50
00:02:58,000 --> 00:03:00,960
And so that is actually what we're going to do
51
51
00:03:00,960 --> 00:03:02,900
in the Forkify project,
52
52
00:03:02,900 --> 00:03:07,200
because it's a bit more complex than the Mapty project.
53
53
00:03:07,200 --> 00:03:10,390
Now these days, in modern web development,
54
54
00:03:10,390 --> 00:03:14,900
many developers actually use a framework like react,
55
55
00:03:14,900 --> 00:03:18,200
Angular, Vue or Svelte
56
56
00:03:18,200 --> 00:03:21,900
to take care of the architecture for them.
57
57
00:03:21,900 --> 00:03:24,710
And so in this case, developers don't have to think
58
58
00:03:24,710 --> 00:03:27,690
a lot about architectures on their own.
59
59
00:03:27,690 --> 00:03:29,580
And probably this is actually
60
60
00:03:29,580 --> 00:03:32,240
a good idea at a certain point,
61
61
00:03:32,240 --> 00:03:36,200
especially for large scale applications.
62
62
00:03:36,200 --> 00:03:40,970
However, and this is key, as I said many times before,
63
63
00:03:40,970 --> 00:03:44,400
it is very important that you really know JavaScript,
64
64
00:03:44,400 --> 00:03:47,920
before switching to some of these frameworks.
65
65
00:03:47,920 --> 00:03:50,700
And in my opinion, that includes knowing
66
66
00:03:50,700 --> 00:03:54,260
how to implement an architecture by yourself.
67
67
00:03:54,260 --> 00:03:57,680
And so that's what I will teach you with this project,
68
68
00:03:57,680 --> 00:04:00,670
among many other things of course.
69
69
00:04:00,670 --> 00:04:04,200
And so this will make it so much easier for you
70
70
00:04:04,200 --> 00:04:08,300
to learn React, or Vue or whatever framework
71
71
00:04:08,300 --> 00:04:11,200
that you choose later down the road.
72
72
00:04:11,200 --> 00:04:14,410
Now no matter where the architecture comes from,
73
73
00:04:14,410 --> 00:04:16,150
and who develops it,
74
74
00:04:16,150 --> 00:04:20,920
there are some components that any architecture must have.
75
75
00:04:20,920 --> 00:04:23,280
And that is business logic,
76
76
00:04:23,280 --> 00:04:27,770
state, an HTTP library, application logic,
77
77
00:04:27,770 --> 00:04:30,140
and presentation logic.
78
78
00:04:30,140 --> 00:04:33,520
So business logic is basically all the code
79
79
00:04:33,520 --> 00:04:36,770
that solves the actual business problem.
80
80
00:04:36,770 --> 00:04:39,950
So that's code that is directly related
81
81
00:04:39,950 --> 00:04:43,860
to what the business does and to what it needs.
82
82
00:04:43,860 --> 00:04:46,870
So if your business is what's up,
83
83
00:04:46,870 --> 00:04:50,950
then your business logic will include sending messages.
84
84
00:04:50,950 --> 00:04:53,450
Now if your business is a bank,
85
85
00:04:53,450 --> 00:04:56,600
then one of the many parts of business logic
86
86
00:04:56,600 --> 00:04:59,370
will be to store transactions.
87
87
00:04:59,370 --> 00:05:02,810
But if you business is a budget manager,
88
88
00:05:02,810 --> 00:05:05,210
then your business logic will certainly
89
89
00:05:05,210 --> 00:05:07,750
include calculating taxes.
90
90
00:05:07,750 --> 00:05:09,682
So you get the point.
91
91
00:05:09,682 --> 00:05:14,230
So essentially, business logic is the logic
92
92
00:05:14,230 --> 00:05:17,340
that is really related to solve the problem
93
93
00:05:17,340 --> 00:05:21,272
that the business set out to solve in the first place.
94
94
00:05:21,272 --> 00:05:26,272
Next is the state which is one of the most important aspects
95
95
00:05:26,790 --> 00:05:29,290
of any web application.
96
96
00:05:29,290 --> 00:05:32,350
So the application state is essentially
97
97
00:05:32,350 --> 00:05:34,530
what stores all the data about
98
98
00:05:34,530 --> 00:05:37,750
the application that is running in the browser.
99
99
00:05:37,750 --> 00:05:41,783
So the data about the applications front end basically.
100
100
00:05:42,670 --> 00:05:45,600
So the state should store any data
101
101
00:05:45,600 --> 00:05:47,981
that you might fetch from an API
102
102
00:05:47,981 --> 00:05:49,693
or data that the user inputs,
103
103
00:05:49,693 --> 00:05:54,693
or what page the user is currently viewing and so on.
104
104
00:05:55,000 --> 00:05:56,650
And this data should be
105
105
00:05:56,650 --> 00:05:59,560
the so called single source of truth,
106
106
00:05:59,560 --> 00:06:03,900
which should be kept in sync with the user interface.
107
107
00:06:03,900 --> 00:06:07,820
So that means that if some data changes in the state,
108
108
00:06:07,820 --> 00:06:11,730
then the user interface should reflect that.
109
109
00:06:11,730 --> 00:06:14,240
And the same is true the other way around.
110
110
00:06:14,240 --> 00:06:16,774
So if something changes in the UI,
111
111
00:06:16,774 --> 00:06:19,820
then the state should also change.
112
112
00:06:19,820 --> 00:06:22,650
Now storing and displaying data
113
113
00:06:22,650 --> 00:06:24,880
and keeping everything in sync
114
114
00:06:24,880 --> 00:06:27,180
is one of the most difficult tasks
115
115
00:06:27,180 --> 00:06:29,520
when building web applications.
116
116
00:06:29,520 --> 00:06:31,364
And that's why there are actually
117
117
00:06:31,364 --> 00:06:36,364
many state management libraries like Redux or MobX.
118
118
00:06:36,820 --> 00:06:40,730
But in this project, we will keep things very simple
119
119
00:06:40,730 --> 00:06:45,440
and use a simple object to store our entire state.
120
120
00:06:45,440 --> 00:06:49,283
Next, the HTTP library is simply responsible
121
121
00:06:49,283 --> 00:06:53,440
for making and receiving AJAX requests.
122
122
00:06:53,440 --> 00:06:56,590
And we have been doing that using the fetch function
123
123
00:06:56,590 --> 00:06:59,730
and so that's what we will keep doing here.
124
124
00:06:59,730 --> 00:07:02,640
And most real world applications of course,
125
125
00:07:02,640 --> 00:07:04,800
need some interaction with the web.
126
126
00:07:04,800 --> 00:07:08,780
And so that's why this is an aspect to keep in mind.
127
127
00:07:08,780 --> 00:07:11,450
Now about the presentation logic,
128
128
00:07:11,450 --> 00:07:14,570
this is the code that is only concerned
129
129
00:07:14,570 --> 00:07:18,550
about the implementation of the application itself.
130
130
00:07:18,550 --> 00:07:22,480
So it's more the technical aspects of the application,
131
131
00:07:22,480 --> 00:07:24,670
which are not directly related
132
132
00:07:24,670 --> 00:07:27,420
to the underlying business problem.
133
133
00:07:27,420 --> 00:07:30,100
So for example, application logic
134
134
00:07:30,100 --> 00:07:35,100
includes handling of UI events and navigation on the page.
135
135
00:07:35,560 --> 00:07:37,800
That's the reason why this component
136
136
00:07:37,800 --> 00:07:40,750
is many times also called a router.
137
137
00:07:40,750 --> 00:07:45,270
So basically mapping actions to the users navigation.
138
138
00:07:45,270 --> 00:07:47,680
Finally, the presentation logic,
139
139
00:07:47,680 --> 00:07:50,093
which is also called the UI layer,
140
140
00:07:50,093 --> 00:07:54,563
is of course all about the visible part of the application.
141
141
00:07:55,630 --> 00:07:59,480
So essentially, we can say that the presentation logic
142
142
00:07:59,480 --> 00:08:01,890
is responsible for displaying
143
143
00:08:01,890 --> 00:08:05,012
the application state on the user interface,
144
144
00:08:05,012 --> 00:08:07,893
in order to keep everything in sync.
145
145
00:08:08,731 --> 00:08:12,250
Now any good architecture
146
146
00:08:12,250 --> 00:08:15,860
has a way of separating all these components.
147
147
00:08:15,860 --> 00:08:20,420
So instead of mixing everything together in one big file,
148
148
00:08:20,420 --> 00:08:22,860
and in one big mess.
149
149
00:08:22,860 --> 00:08:25,770
And so let's now take a look at a well established
150
150
00:08:25,770 --> 00:08:28,330
architecture pattern that we're going to use
151
151
00:08:28,330 --> 00:08:29,653
in this project.
152
152
00:08:30,520 --> 00:08:35,000
And that is the model view controller architecture.
153
153
00:08:35,000 --> 00:08:39,420
So basically, this architecture contains three big parts,
154
154
00:08:39,420 --> 00:08:43,390
which are the model, the view and the controller.
155
155
00:08:43,390 --> 00:08:47,300
Now the view is of course, for the presentation logic.
156
156
00:08:47,300 --> 00:08:50,590
So it's the part of the application interacting
157
157
00:08:50,590 --> 00:08:51,713
with the user.
158
158
00:08:52,570 --> 00:08:56,250
The model is all about the applications data.
159
159
00:08:56,250 --> 00:08:58,743
And so that's why it usually contains
160
160
00:08:58,743 --> 00:09:02,120
the state and also the business logic
161
161
00:09:02,120 --> 00:09:04,130
that manipulates the state.
162
162
00:09:04,130 --> 00:09:07,700
So these two should be kept closely together.
163
163
00:09:07,700 --> 00:09:12,150
Now, the model is also what contains the HTTP library,
164
164
00:09:12,150 --> 00:09:15,150
that might get some data from the web.
165
165
00:09:15,150 --> 00:09:18,450
So like from some API or some back end.
166
166
00:09:18,450 --> 00:09:22,350
And so this is of course also about the data,
167
167
00:09:22,350 --> 00:09:25,490
and so it also goes into the model.
168
168
00:09:25,490 --> 00:09:27,030
Finally, the controller
169
169
00:09:27,030 --> 00:09:30,020
is what contains the application logic.
170
170
00:09:30,020 --> 00:09:34,100
And it kind of sits between the model and the view.
171
171
00:09:34,100 --> 00:09:36,640
So it basically creates a bridge
172
172
00:09:36,640 --> 00:09:40,100
between the model and a view which in fact,
173
173
00:09:40,100 --> 00:09:42,860
should know nothing about each other.
174
174
00:09:42,860 --> 00:09:45,660
So again, the model and the view
175
175
00:09:45,660 --> 00:09:49,340
will exist completely independent from one another,
176
176
00:09:49,340 --> 00:09:54,140
and not even knowing that the other one exists, basically.
177
177
00:09:54,140 --> 00:09:56,590
And in fact, one of the big goals
178
178
00:09:56,590 --> 00:10:00,960
of the MVC pattern so of this model view controller
179
179
00:10:00,960 --> 00:10:03,400
architecture is to actually
180
180
00:10:03,400 --> 00:10:07,200
separate business logic from application logic,
181
181
00:10:07,200 --> 00:10:11,630
which makes developing the application so much easier.
182
182
00:10:11,630 --> 00:10:13,060
But as a consequence,
183
183
00:10:13,060 --> 00:10:16,920
we then need something to connect these two parts.
184
184
00:10:16,920 --> 00:10:18,883
And so that is the controller.
185
185
00:10:20,032 --> 00:10:23,680
Now let's actually take a look
186
186
00:10:23,680 --> 00:10:27,300
at a typical flow of actions and of data
187
187
00:10:27,300 --> 00:10:28,815
as soon as some event happens
188
188
00:10:28,815 --> 00:10:33,730
on the user interface for example like a click.
189
189
00:10:33,730 --> 00:10:37,230
So to start, it's going to be the controller
190
190
00:10:37,230 --> 00:10:39,350
who will handle that event,
191
191
00:10:39,350 --> 00:10:40,970
because handling an event
192
192
00:10:40,970 --> 00:10:43,660
is doing something in the application.
193
193
00:10:43,660 --> 00:10:48,150
And that is clearly part of the application logic.
194
194
00:10:48,150 --> 00:10:50,140
Now, this handling might involve
195
195
00:10:50,140 --> 00:10:54,010
updating the user interface and also ask the model
196
196
00:10:54,010 --> 00:10:55,940
for some data.
197
197
00:10:55,940 --> 00:10:59,980
So we can say that the controller dispatches tasks
198
198
00:10:59,980 --> 00:11:04,160
to model and to the view or in other words,
199
199
00:11:04,160 --> 00:11:08,580
it controls and orchestrates this entire action.
200
200
00:11:08,580 --> 00:11:12,220
And in fact, the whole application itself.
201
201
00:11:12,220 --> 00:11:15,310
Now asking the model for some data might,
202
202
00:11:15,310 --> 00:11:19,510
of course involve doing an AJAX request to the web.
203
203
00:11:19,510 --> 00:11:22,960
And so that's exactly what the model does.
204
204
00:11:22,960 --> 00:11:24,920
Then, when the data arrives,
205
205
00:11:24,920 --> 00:11:29,430
the controller takes the data and sends it to the view.
206
206
00:11:29,430 --> 00:11:32,220
And so finally to finish the view,
207
207
00:11:32,220 --> 00:11:35,600
will render that data to the user interface,
208
208
00:11:35,600 --> 00:11:37,573
and finish this whole cycle.
209
209
00:11:38,480 --> 00:11:42,593
Now in this diagram, you see two types of arrows.
210
210
00:11:42,593 --> 00:11:46,630
So the dotted arrows represent data flow
211
211
00:11:46,630 --> 00:11:48,570
between the different parts,
212
212
00:11:48,570 --> 00:11:50,920
while the solid arrows represent
213
213
00:11:50,920 --> 00:11:54,720
actual function calls and module imports.
214
214
00:11:54,720 --> 00:11:58,710
So analyzing this, we can see that it's only the controller
215
215
00:11:58,710 --> 00:12:02,470
who imports and calls functions from the model,
216
216
00:12:02,470 --> 00:12:06,300
and from the view, but never the other way around.
217
217
00:12:06,300 --> 00:12:10,210
And so as I mentioned before, the model and view
218
218
00:12:10,210 --> 00:12:15,210
are in fact completely standalone and completely isolated.
219
219
00:12:15,375 --> 00:12:19,710
So again, they don't import each other,
220
220
00:12:19,710 --> 00:12:22,340
and they don't even import the controller.
221
221
00:12:22,340 --> 00:12:24,750
And in fact, they don't even know
222
222
00:12:24,750 --> 00:12:26,980
that the controller exists.
223
223
00:12:26,980 --> 00:12:29,830
All they do is to basically just sit there
224
224
00:12:29,830 --> 00:12:33,696
waiting to get some instructions from the controller.
225
225
00:12:33,696 --> 00:12:37,680
And this part is pretty important to understand.
226
226
00:12:37,680 --> 00:12:40,693
So take some time to really analyze this.
227
227
00:12:41,530 --> 00:12:43,820
Now, there are actually different ways
228
228
00:12:43,820 --> 00:12:46,630
of implementing the MVC pattern,
229
229
00:12:46,630 --> 00:12:49,340
where some are more complex than others.
230
230
00:12:49,340 --> 00:12:52,350
But this one is my favorite way of doing it,
231
231
00:12:52,350 --> 00:12:55,600
because I think it makes the most sense.
232
232
00:12:55,600 --> 00:12:59,670
But anyway, let's know see this MVC architecture
233
233
00:12:59,670 --> 00:13:02,310
applied to the part of the Forkify
234
234
00:13:02,310 --> 00:13:05,223
application that we already implemented.
235
235
00:13:07,010 --> 00:13:09,820
And so this is a flowchart of loading
236
236
00:13:09,820 --> 00:13:13,920
and rendering a recipe that we already implemented.
237
237
00:13:13,920 --> 00:13:16,900
And then down there, there's also a reminder
238
238
00:13:16,900 --> 00:13:20,910
of the MVC diagram that we just analyzed.
239
239
00:13:20,910 --> 00:13:23,970
So in this flowchart, handling these events
240
240
00:13:23,970 --> 00:13:27,048
is associated to the controller.
241
241
00:13:27,048 --> 00:13:31,178
Then loading the recipe happens in the model.
242
242
00:13:31,178 --> 00:13:34,010
So the controller basically calls
243
243
00:13:34,010 --> 00:13:36,720
some function that is in the model.
244
244
00:13:36,720 --> 00:13:38,870
And then the model asynchronously
245
245
00:13:38,870 --> 00:13:41,803
gets the recipe data from the API.
246
246
00:13:42,710 --> 00:13:45,060
And once that data has arrived,
247
247
00:13:45,060 --> 00:13:48,706
the controller asks for that data, receives it,
248
248
00:13:48,706 --> 00:13:52,600
sends it to the view, which will then ultimately
249
249
00:13:52,600 --> 00:13:55,140
render the recipe on the screen.
250
250
00:13:55,140 --> 00:13:57,030
And that's it.
251
251
00:13:57,030 --> 00:13:59,980
So that's what every step of the flowchart
252
252
00:13:59,980 --> 00:14:04,104
is associated to in the MVC architecture.
253
253
00:14:04,104 --> 00:14:07,330
But this is still quite abstract.
254
254
00:14:07,330 --> 00:14:09,770
Because remember, the flowchart
255
255
00:14:09,770 --> 00:14:14,740
is simply what we will implement, not how we will do that.
256
256
00:14:14,740 --> 00:14:17,150
And so let's go even deeper,
257
257
00:14:17,150 --> 00:14:19,750
and actually take a look at a detailed
258
258
00:14:19,750 --> 00:14:24,150
implementation diagram of or MVC architecture.
259
259
00:14:24,150 --> 00:14:26,750
And again, this is only about loading
260
260
00:14:26,750 --> 00:14:29,070
and rendering a recipe.
261
261
00:14:29,070 --> 00:14:32,050
And let's start by noticing how both the model
262
262
00:14:32,050 --> 00:14:35,990
and controller are implemented in a module,
263
263
00:14:35,990 --> 00:14:40,030
while the recipe view is actually a class.
264
264
00:14:40,030 --> 00:14:42,257
And we will explore the reasons for this
265
265
00:14:42,257 --> 00:14:44,700
when we actually write the code.
266
266
00:14:44,700 --> 00:14:47,310
But now once again, let's analyze
267
267
00:14:47,310 --> 00:14:49,800
the same data and actions flow,
268
268
00:14:49,800 --> 00:14:53,600
but this time in this real implementation.
269
269
00:14:53,600 --> 00:14:56,747
So when the user clicks on a search result,
270
270
00:14:56,747 --> 00:15:00,850
there is a control recipes function in the controller
271
271
00:15:00,850 --> 00:15:04,570
and this is the one that will handle this event.
272
272
00:15:04,570 --> 00:15:08,490
And how exactly that happens doesn't matter for now.
273
273
00:15:08,490 --> 00:15:11,070
So we will come back to this later.
274
274
00:15:11,070 --> 00:15:13,340
What matters is that this controller
275
275
00:15:13,340 --> 00:15:16,490
will instruct the recipe view to render
276
276
00:15:16,490 --> 00:15:19,470
a loading spinner while the user interface
277
277
00:15:19,470 --> 00:15:22,090
waits for the data to arrive.
278
278
00:15:22,090 --> 00:15:24,200
In the meantime, the controller
279
279
00:15:24,200 --> 00:15:27,356
also called the load recipes function in the model
280
280
00:15:27,356 --> 00:15:32,356
to fetch the recipe data from the Forkify API.
281
281
00:15:32,480 --> 00:15:35,945
Now the model also contains a big state object
282
282
00:15:35,945 --> 00:15:38,760
that we export from the model.
283
283
00:15:38,760 --> 00:15:42,320
And this state will contain all sorts of data,
284
284
00:15:42,320 --> 00:15:47,320
like the current recipe, search results, bookmarks, etc.
285
285
00:15:47,440 --> 00:15:50,720
But anyway, as the data arrives,
286
286
00:15:50,720 --> 00:15:54,190
it will be stored in this state object.
287
287
00:15:54,190 --> 00:15:58,160
And the controller then reaches into the state object,
288
288
00:15:58,160 --> 00:16:00,190
grabs the recipe data,
289
289
00:16:00,190 --> 00:16:02,520
and finally calls the render method
290
290
00:16:02,520 --> 00:16:06,070
on the recipe view with that data.
291
291
00:16:06,070 --> 00:16:08,000
So in order to finally render
292
292
00:16:08,000 --> 00:16:11,220
the recipe to the user interface.
293
293
00:16:11,220 --> 00:16:15,140
So basically the exact same steps as before,
294
294
00:16:15,140 --> 00:16:18,810
but this time actually implemented in our code.
295
295
00:16:18,810 --> 00:16:22,530
well, at least in theory and so next up,
296
296
00:16:22,530 --> 00:16:24,660
let's actually go from theory
297
297
00:16:24,660 --> 00:16:28,810
to practice and implement this architecture in our code.
26433
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.