WEBVTT 1 00:00:01.140 --> 00:00:02.880 So we already implemented 2 00:00:02.880 --> 00:00:05.840 a part of the Forkify application. 3 00:00:05.840 --> 00:00:10.320 But at this point, it has no structure whatsoever. 4 00:00:10.320 --> 00:00:14.690 And so now it's time to talk about the project architecture, 5 00:00:14.690 --> 00:00:19.490 but also about software architecture more in general. 6 00:00:19.490 --> 00:00:21.600 Now, we touched on this already 7 00:00:21.600 --> 00:00:25.070 in the Mapty application a little bit earlier. 8 00:00:25.070 --> 00:00:28.793 But in this lecture, let's now go a little bit deeper. 9 00:00:30.310 --> 00:00:32.960 And first of all, why do we even need 10 00:00:32.960 --> 00:00:35.653 an architecture when we build software? 11 00:00:36.500 --> 00:00:39.900 Well, there are actually multiple reasons. 12 00:00:39.900 --> 00:00:43.200 First, the architecture will give our project 13 00:00:43.200 --> 00:00:47.350 the structure in which we can then write the code. 14 00:00:47.350 --> 00:00:52.350 So just like a house, software also needs a structure. 15 00:00:52.690 --> 00:00:55.900 Now in software, structure basically means 16 00:00:55.900 --> 00:00:58.750 how we organize and divide the code 17 00:00:58.750 --> 00:01:03.190 into different modules, classes, and functions. 18 00:01:03.190 --> 00:01:06.070 So all these will basically hold our code 19 00:01:06.070 --> 00:01:09.020 together and give it structure. 20 00:01:09.020 --> 00:01:11.543 The next reason is maintainability. 21 00:01:12.550 --> 00:01:14.800 So when we build a project, 22 00:01:14.800 --> 00:01:17.690 we always need to think about the future 23 00:01:17.690 --> 00:01:22.290 and keep in mind that the project is never really done. 24 00:01:22.290 --> 00:01:24.200 It is never finished. 25 00:01:24.200 --> 00:01:27.440 We will always need to change things in the future 26 00:01:27.440 --> 00:01:30.570 and we will need to maintain the project. 27 00:01:30.570 --> 00:01:35.400 And that only works if the project is nicely structured. 28 00:01:35.400 --> 00:01:40.180 Plus, we might even want to add new features to the project, 29 00:01:40.180 --> 00:01:42.073 which brings us to expandability. 30 00:01:43.370 --> 00:01:46.470 So expandability is basically 31 00:01:46.470 --> 00:01:51.300 the ability to easily add new features in the future. 32 00:01:51.300 --> 00:01:55.730 And once again, that is only possible with a good structure, 33 00:01:55.730 --> 00:01:58.550 and a good overall architecture. 34 00:01:58.550 --> 00:02:01.891 So the perfect architecture is basically one 35 00:02:01.891 --> 00:02:05.440 that allows for all these three aspects 36 00:02:05.440 --> 00:02:10.440 of structure maintainability, and expandability. 37 00:02:10.590 --> 00:02:14.280 Now, in order to achieve that perfect architecture, 38 00:02:14.280 --> 00:02:19.130 we can of course create our own architecture from scratch. 39 00:02:19.130 --> 00:02:23.310 And that's exactly what we did in the Mapty project. 40 00:02:23.310 --> 00:02:25.110 However, that only works 41 00:02:25.110 --> 00:02:28.810 with a really small project like that one. 42 00:02:28.810 --> 00:02:31.620 But when the project grows more complex, 43 00:02:31.620 --> 00:02:33.510 then it's going to be very hard 44 00:02:33.510 --> 00:02:37.720 to achieve a good architecture completely on our own. 45 00:02:37.720 --> 00:02:41.930 And so instead, we can opt for a well established 46 00:02:41.930 --> 00:02:44.470 architecture pattern that developers 47 00:02:44.470 --> 00:02:48.640 have been using for years, or even for decades. 48 00:02:48.640 --> 00:02:52.480 And examples of that are model view controller, 49 00:02:52.480 --> 00:02:57.480 model view presenter, flux, and many other architectures. 50 00:02:58.000 --> 00:03:00.960 And so that is actually what we're going to do 51 00:03:00.960 --> 00:03:02.900 in the Forkify project, 52 00:03:02.900 --> 00:03:07.200 because it's a bit more complex than the Mapty project. 53 00:03:07.200 --> 00:03:10.390 Now these days, in modern web development, 54 00:03:10.390 --> 00:03:14.900 many developers actually use a framework like react, 55 00:03:14.900 --> 00:03:18.200 Angular, Vue or Svelte 56 00:03:18.200 --> 00:03:21.900 to take care of the architecture for them. 57 00:03:21.900 --> 00:03:24.710 And so in this case, developers don't have to think 58 00:03:24.710 --> 00:03:27.690 a lot about architectures on their own. 59 00:03:27.690 --> 00:03:29.580 And probably this is actually 60 00:03:29.580 --> 00:03:32.240 a good idea at a certain point, 61 00:03:32.240 --> 00:03:36.200 especially for large scale applications. 62 00:03:36.200 --> 00:03:40.970 However, and this is key, as I said many times before, 63 00:03:40.970 --> 00:03:44.400 it is very important that you really know JavaScript, 64 00:03:44.400 --> 00:03:47.920 before switching to some of these frameworks. 65 00:03:47.920 --> 00:03:50.700 And in my opinion, that includes knowing 66 00:03:50.700 --> 00:03:54.260 how to implement an architecture by yourself. 67 00:03:54.260 --> 00:03:57.680 And so that's what I will teach you with this project, 68 00:03:57.680 --> 00:04:00.670 among many other things of course. 69 00:04:00.670 --> 00:04:04.200 And so this will make it so much easier for you 70 00:04:04.200 --> 00:04:08.300 to learn React, or Vue or whatever framework 71 00:04:08.300 --> 00:04:11.200 that you choose later down the road. 72 00:04:11.200 --> 00:04:14.410 Now no matter where the architecture comes from, 73 00:04:14.410 --> 00:04:16.150 and who develops it, 74 00:04:16.150 --> 00:04:20.920 there are some components that any architecture must have. 75 00:04:20.920 --> 00:04:23.280 And that is business logic, 76 00:04:23.280 --> 00:04:27.770 state, an HTTP library, application logic, 77 00:04:27.770 --> 00:04:30.140 and presentation logic. 78 00:04:30.140 --> 00:04:33.520 So business logic is basically all the code 79 00:04:33.520 --> 00:04:36.770 that solves the actual business problem. 80 00:04:36.770 --> 00:04:39.950 So that's code that is directly related 81 00:04:39.950 --> 00:04:43.860 to what the business does and to what it needs. 82 00:04:43.860 --> 00:04:46.870 So if your business is what's up, 83 00:04:46.870 --> 00:04:50.950 then your business logic will include sending messages. 84 00:04:50.950 --> 00:04:53.450 Now if your business is a bank, 85 00:04:53.450 --> 00:04:56.600 then one of the many parts of business logic 86 00:04:56.600 --> 00:04:59.370 will be to store transactions. 87 00:04:59.370 --> 00:05:02.810 But if you business is a budget manager, 88 00:05:02.810 --> 00:05:05.210 then your business logic will certainly 89 00:05:05.210 --> 00:05:07.750 include calculating taxes. 90 00:05:07.750 --> 00:05:09.682 So you get the point. 91 00:05:09.682 --> 00:05:14.230 So essentially, business logic is the logic 92 00:05:14.230 --> 00:05:17.340 that is really related to solve the problem 93 00:05:17.340 --> 00:05:21.272 that the business set out to solve in the first place. 94 00:05:21.272 --> 00:05:26.272 Next is the state which is one of the most important aspects 95 00:05:26.790 --> 00:05:29.290 of any web application. 96 00:05:29.290 --> 00:05:32.350 So the application state is essentially 97 00:05:32.350 --> 00:05:34.530 what stores all the data about 98 00:05:34.530 --> 00:05:37.750 the application that is running in the browser. 99 00:05:37.750 --> 00:05:41.783 So the data about the applications front end basically. 100 00:05:42.670 --> 00:05:45.600 So the state should store any data 101 00:05:45.600 --> 00:05:47.981 that you might fetch from an API 102 00:05:47.981 --> 00:05:49.693 or data that the user inputs, 103 00:05:49.693 --> 00:05:54.693 or what page the user is currently viewing and so on. 104 00:05:55.000 --> 00:05:56.650 And this data should be 105 00:05:56.650 --> 00:05:59.560 the so called single source of truth, 106 00:05:59.560 --> 00:06:03.900 which should be kept in sync with the user interface. 107 00:06:03.900 --> 00:06:07.820 So that means that if some data changes in the state, 108 00:06:07.820 --> 00:06:11.730 then the user interface should reflect that. 109 00:06:11.730 --> 00:06:14.240 And the same is true the other way around. 110 00:06:14.240 --> 00:06:16.774 So if something changes in the UI, 111 00:06:16.774 --> 00:06:19.820 then the state should also change. 112 00:06:19.820 --> 00:06:22.650 Now storing and displaying data 113 00:06:22.650 --> 00:06:24.880 and keeping everything in sync 114 00:06:24.880 --> 00:06:27.180 is one of the most difficult tasks 115 00:06:27.180 --> 00:06:29.520 when building web applications. 116 00:06:29.520 --> 00:06:31.364 And that's why there are actually 117 00:06:31.364 --> 00:06:36.364 many state management libraries like Redux or MobX. 118 00:06:36.820 --> 00:06:40.730 But in this project, we will keep things very simple 119 00:06:40.730 --> 00:06:45.440 and use a simple object to store our entire state. 120 00:06:45.440 --> 00:06:49.283 Next, the HTTP library is simply responsible 121 00:06:49.283 --> 00:06:53.440 for making and receiving AJAX requests. 122 00:06:53.440 --> 00:06:56.590 And we have been doing that using the fetch function 123 00:06:56.590 --> 00:06:59.730 and so that's what we will keep doing here. 124 00:06:59.730 --> 00:07:02.640 And most real world applications of course, 125 00:07:02.640 --> 00:07:04.800 need some interaction with the web. 126 00:07:04.800 --> 00:07:08.780 And so that's why this is an aspect to keep in mind. 127 00:07:08.780 --> 00:07:11.450 Now about the presentation logic, 128 00:07:11.450 --> 00:07:14.570 this is the code that is only concerned 129 00:07:14.570 --> 00:07:18.550 about the implementation of the application itself. 130 00:07:18.550 --> 00:07:22.480 So it's more the technical aspects of the application, 131 00:07:22.480 --> 00:07:24.670 which are not directly related 132 00:07:24.670 --> 00:07:27.420 to the underlying business problem. 133 00:07:27.420 --> 00:07:30.100 So for example, application logic 134 00:07:30.100 --> 00:07:35.100 includes handling of UI events and navigation on the page. 135 00:07:35.560 --> 00:07:37.800 That's the reason why this component 136 00:07:37.800 --> 00:07:40.750 is many times also called a router. 137 00:07:40.750 --> 00:07:45.270 So basically mapping actions to the users navigation. 138 00:07:45.270 --> 00:07:47.680 Finally, the presentation logic, 139 00:07:47.680 --> 00:07:50.093 which is also called the UI layer, 140 00:07:50.093 --> 00:07:54.563 is of course all about the visible part of the application. 141 00:07:55.630 --> 00:07:59.480 So essentially, we can say that the presentation logic 142 00:07:59.480 --> 00:08:01.890 is responsible for displaying 143 00:08:01.890 --> 00:08:05.012 the application state on the user interface, 144 00:08:05.012 --> 00:08:07.893 in order to keep everything in sync. 145 00:08:08.731 --> 00:08:12.250 Now any good architecture 146 00:08:12.250 --> 00:08:15.860 has a way of separating all these components. 147 00:08:15.860 --> 00:08:20.420 So instead of mixing everything together in one big file, 148 00:08:20.420 --> 00:08:22.860 and in one big mess. 149 00:08:22.860 --> 00:08:25.770 And so let's now take a look at a well established 150 00:08:25.770 --> 00:08:28.330 architecture pattern that we're going to use 151 00:08:28.330 --> 00:08:29.653 in this project. 152 00:08:30.520 --> 00:08:35.000 And that is the model view controller architecture. 153 00:08:35.000 --> 00:08:39.420 So basically, this architecture contains three big parts, 154 00:08:39.420 --> 00:08:43.390 which are the model, the view and the controller. 155 00:08:43.390 --> 00:08:47.300 Now the view is of course, for the presentation logic. 156 00:08:47.300 --> 00:08:50.590 So it's the part of the application interacting 157 00:08:50.590 --> 00:08:51.713 with the user. 158 00:08:52.570 --> 00:08:56.250 The model is all about the applications data. 159 00:08:56.250 --> 00:08:58.743 And so that's why it usually contains 160 00:08:58.743 --> 00:09:02.120 the state and also the business logic 161 00:09:02.120 --> 00:09:04.130 that manipulates the state. 162 00:09:04.130 --> 00:09:07.700 So these two should be kept closely together. 163 00:09:07.700 --> 00:09:12.150 Now, the model is also what contains the HTTP library, 164 00:09:12.150 --> 00:09:15.150 that might get some data from the web. 165 00:09:15.150 --> 00:09:18.450 So like from some API or some back end. 166 00:09:18.450 --> 00:09:22.350 And so this is of course also about the data, 167 00:09:22.350 --> 00:09:25.490 and so it also goes into the model. 168 00:09:25.490 --> 00:09:27.030 Finally, the controller 169 00:09:27.030 --> 00:09:30.020 is what contains the application logic. 170 00:09:30.020 --> 00:09:34.100 And it kind of sits between the model and the view. 171 00:09:34.100 --> 00:09:36.640 So it basically creates a bridge 172 00:09:36.640 --> 00:09:40.100 between the model and a view which in fact, 173 00:09:40.100 --> 00:09:42.860 should know nothing about each other. 174 00:09:42.860 --> 00:09:45.660 So again, the model and the view 175 00:09:45.660 --> 00:09:49.340 will exist completely independent from one another, 176 00:09:49.340 --> 00:09:54.140 and not even knowing that the other one exists, basically. 177 00:09:54.140 --> 00:09:56.590 And in fact, one of the big goals 178 00:09:56.590 --> 00:10:00.960 of the MVC pattern so of this model view controller 179 00:10:00.960 --> 00:10:03.400 architecture is to actually 180 00:10:03.400 --> 00:10:07.200 separate business logic from application logic, 181 00:10:07.200 --> 00:10:11.630 which makes developing the application so much easier. 182 00:10:11.630 --> 00:10:13.060 But as a consequence, 183 00:10:13.060 --> 00:10:16.920 we then need something to connect these two parts. 184 00:10:16.920 --> 00:10:18.883 And so that is the controller. 185 00:10:20.032 --> 00:10:23.680 Now let's actually take a look 186 00:10:23.680 --> 00:10:27.300 at a typical flow of actions and of data 187 00:10:27.300 --> 00:10:28.815 as soon as some event happens 188 00:10:28.815 --> 00:10:33.730 on the user interface for example like a click. 189 00:10:33.730 --> 00:10:37.230 So to start, it's going to be the controller 190 00:10:37.230 --> 00:10:39.350 who will handle that event, 191 00:10:39.350 --> 00:10:40.970 because handling an event 192 00:10:40.970 --> 00:10:43.660 is doing something in the application. 193 00:10:43.660 --> 00:10:48.150 And that is clearly part of the application logic. 194 00:10:48.150 --> 00:10:50.140 Now, this handling might involve 195 00:10:50.140 --> 00:10:54.010 updating the user interface and also ask the model 196 00:10:54.010 --> 00:10:55.940 for some data. 197 00:10:55.940 --> 00:10:59.980 So we can say that the controller dispatches tasks 198 00:10:59.980 --> 00:11:04.160 to model and to the view or in other words, 199 00:11:04.160 --> 00:11:08.580 it controls and orchestrates this entire action. 200 00:11:08.580 --> 00:11:12.220 And in fact, the whole application itself. 201 00:11:12.220 --> 00:11:15.310 Now asking the model for some data might, 202 00:11:15.310 --> 00:11:19.510 of course involve doing an AJAX request to the web. 203 00:11:19.510 --> 00:11:22.960 And so that's exactly what the model does. 204 00:11:22.960 --> 00:11:24.920 Then, when the data arrives, 205 00:11:24.920 --> 00:11:29.430 the controller takes the data and sends it to the view. 206 00:11:29.430 --> 00:11:32.220 And so finally to finish the view, 207 00:11:32.220 --> 00:11:35.600 will render that data to the user interface, 208 00:11:35.600 --> 00:11:37.573 and finish this whole cycle. 209 00:11:38.480 --> 00:11:42.593 Now in this diagram, you see two types of arrows. 210 00:11:42.593 --> 00:11:46.630 So the dotted arrows represent data flow 211 00:11:46.630 --> 00:11:48.570 between the different parts, 212 00:11:48.570 --> 00:11:50.920 while the solid arrows represent 213 00:11:50.920 --> 00:11:54.720 actual function calls and module imports. 214 00:11:54.720 --> 00:11:58.710 So analyzing this, we can see that it's only the controller 215 00:11:58.710 --> 00:12:02.470 who imports and calls functions from the model, 216 00:12:02.470 --> 00:12:06.300 and from the view, but never the other way around. 217 00:12:06.300 --> 00:12:10.210 And so as I mentioned before, the model and view 218 00:12:10.210 --> 00:12:15.210 are in fact completely standalone and completely isolated. 219 00:12:15.375 --> 00:12:19.710 So again, they don't import each other, 220 00:12:19.710 --> 00:12:22.340 and they don't even import the controller. 221 00:12:22.340 --> 00:12:24.750 And in fact, they don't even know 222 00:12:24.750 --> 00:12:26.980 that the controller exists. 223 00:12:26.980 --> 00:12:29.830 All they do is to basically just sit there 224 00:12:29.830 --> 00:12:33.696 waiting to get some instructions from the controller. 225 00:12:33.696 --> 00:12:37.680 And this part is pretty important to understand. 226 00:12:37.680 --> 00:12:40.693 So take some time to really analyze this. 227 00:12:41.530 --> 00:12:43.820 Now, there are actually different ways 228 00:12:43.820 --> 00:12:46.630 of implementing the MVC pattern, 229 00:12:46.630 --> 00:12:49.340 where some are more complex than others. 230 00:12:49.340 --> 00:12:52.350 But this one is my favorite way of doing it, 231 00:12:52.350 --> 00:12:55.600 because I think it makes the most sense. 232 00:12:55.600 --> 00:12:59.670 But anyway, let's know see this MVC architecture 233 00:12:59.670 --> 00:13:02.310 applied to the part of the Forkify 234 00:13:02.310 --> 00:13:05.223 application that we already implemented. 235 00:13:07.010 --> 00:13:09.820 And so this is a flowchart of loading 236 00:13:09.820 --> 00:13:13.920 and rendering a recipe that we already implemented. 237 00:13:13.920 --> 00:13:16.900 And then down there, there's also a reminder 238 00:13:16.900 --> 00:13:20.910 of the MVC diagram that we just analyzed. 239 00:13:20.910 --> 00:13:23.970 So in this flowchart, handling these events 240 00:13:23.970 --> 00:13:27.048 is associated to the controller. 241 00:13:27.048 --> 00:13:31.178 Then loading the recipe happens in the model. 242 00:13:31.178 --> 00:13:34.010 So the controller basically calls 243 00:13:34.010 --> 00:13:36.720 some function that is in the model. 244 00:13:36.720 --> 00:13:38.870 And then the model asynchronously 245 00:13:38.870 --> 00:13:41.803 gets the recipe data from the API. 246 00:13:42.710 --> 00:13:45.060 And once that data has arrived, 247 00:13:45.060 --> 00:13:48.706 the controller asks for that data, receives it, 248 00:13:48.706 --> 00:13:52.600 sends it to the view, which will then ultimately 249 00:13:52.600 --> 00:13:55.140 render the recipe on the screen. 250 00:13:55.140 --> 00:13:57.030 And that's it. 251 00:13:57.030 --> 00:13:59.980 So that's what every step of the flowchart 252 00:13:59.980 --> 00:14:04.104 is associated to in the MVC architecture. 253 00:14:04.104 --> 00:14:07.330 But this is still quite abstract. 254 00:14:07.330 --> 00:14:09.770 Because remember, the flowchart 255 00:14:09.770 --> 00:14:14.740 is simply what we will implement, not how we will do that. 256 00:14:14.740 --> 00:14:17.150 And so let's go even deeper, 257 00:14:17.150 --> 00:14:19.750 and actually take a look at a detailed 258 00:14:19.750 --> 00:14:24.150 implementation diagram of or MVC architecture. 259 00:14:24.150 --> 00:14:26.750 And again, this is only about loading 260 00:14:26.750 --> 00:14:29.070 and rendering a recipe. 261 00:14:29.070 --> 00:14:32.050 And let's start by noticing how both the model 262 00:14:32.050 --> 00:14:35.990 and controller are implemented in a module, 263 00:14:35.990 --> 00:14:40.030 while the recipe view is actually a class. 264 00:14:40.030 --> 00:14:42.257 And we will explore the reasons for this 265 00:14:42.257 --> 00:14:44.700 when we actually write the code. 266 00:14:44.700 --> 00:14:47.310 But now once again, let's analyze 267 00:14:47.310 --> 00:14:49.800 the same data and actions flow, 268 00:14:49.800 --> 00:14:53.600 but this time in this real implementation. 269 00:14:53.600 --> 00:14:56.747 So when the user clicks on a search result, 270 00:14:56.747 --> 00:15:00.850 there is a control recipes function in the controller 271 00:15:00.850 --> 00:15:04.570 and this is the one that will handle this event. 272 00:15:04.570 --> 00:15:08.490 And how exactly that happens doesn't matter for now. 273 00:15:08.490 --> 00:15:11.070 So we will come back to this later. 274 00:15:11.070 --> 00:15:13.340 What matters is that this controller 275 00:15:13.340 --> 00:15:16.490 will instruct the recipe view to render 276 00:15:16.490 --> 00:15:19.470 a loading spinner while the user interface 277 00:15:19.470 --> 00:15:22.090 waits for the data to arrive. 278 00:15:22.090 --> 00:15:24.200 In the meantime, the controller 279 00:15:24.200 --> 00:15:27.356 also called the load recipes function in the model 280 00:15:27.356 --> 00:15:32.356 to fetch the recipe data from the Forkify API. 281 00:15:32.480 --> 00:15:35.945 Now the model also contains a big state object 282 00:15:35.945 --> 00:15:38.760 that we export from the model. 283 00:15:38.760 --> 00:15:42.320 And this state will contain all sorts of data, 284 00:15:42.320 --> 00:15:47.320 like the current recipe, search results, bookmarks, etc. 285 00:15:47.440 --> 00:15:50.720 But anyway, as the data arrives, 286 00:15:50.720 --> 00:15:54.190 it will be stored in this state object. 287 00:15:54.190 --> 00:15:58.160 And the controller then reaches into the state object, 288 00:15:58.160 --> 00:16:00.190 grabs the recipe data, 289 00:16:00.190 --> 00:16:02.520 and finally calls the render method 290 00:16:02.520 --> 00:16:06.070 on the recipe view with that data. 291 00:16:06.070 --> 00:16:08.000 So in order to finally render 292 00:16:08.000 --> 00:16:11.220 the recipe to the user interface. 293 00:16:11.220 --> 00:16:15.140 So basically the exact same steps as before, 294 00:16:15.140 --> 00:16:18.810 but this time actually implemented in our code. 295 00:16:18.810 --> 00:16:22.530 well, at least in theory and so next up, 296 00:16:22.530 --> 00:16:24.660 let's actually go from theory 297 00:16:24.660 --> 00:16:28.810 to practice and implement this architecture in our code.