Original subtitles

1 1

So we already implemented 2

2

a part of the Forkify application. 3

3

But at this point, it has no structure whatsoever. 4

4

And so now it's time to talk about the project architecture, 5

5

but also about software architecture more in general. 6

6

Now, we touched on this already 7

7

in the Mapty application a little bit earlier. 8

8

But in this lecture, let's now go a little bit deeper. 9

9

And first of all, why do we even need 10

10

an architecture when we build software? 11

11

Well, there are actually multiple reasons. 12

12

First, the architecture will give our project 13

13

the structure in which we can then write the code. 14

14

So just like a house, software also needs a structure. 15

15

Now in software, structure basically means 16

16

how we organize and divide the code 17

17

into different modules, classes, and functions. 18

18

So all these will basically hold our code 19

19

together and give it structure. 20

20

The next reason is maintainability. 21

21

So when we build a project, 22

22

we always need to think about the future 23

23

and keep in mind that the project is never really done. 24

24

It is never finished. 25

25

We will always need to change things in the future 26

26

and we will need to maintain the project. 27

27

And that only works if the project is nicely structured. 28

28

Plus, we might even want to add new features to the project, 29

29

which brings us to expandability. 30

30

So expandability is basically 31

31

the ability to easily add new features in the future. 32

32

And once again, that is only possible with a good structure, 33

33

and a good overall architecture. 34

34

So the perfect architecture is basically one 35

35

that allows for all these three aspects 36

36

of structure maintainability, and expandability. 37

37

Now, in order to achieve that perfect architecture, 38

38

we can of course create our own architecture from scratch. 39

39

And that's exactly what we did in the Mapty project. 40

40

However, that only works 41

41

with a really small project like that one. 42

42

But when the project grows more complex, 43

43

then it's going to be very hard 44

44

to achieve a good architecture completely on our own. 45

45

And so instead, we can opt for a well established 46

46

architecture pattern that developers 47

47

have been using for years, or even for decades. 48

48

And examples of that are model view controller, 49

49

model view presenter, flux, and many other architectures. 50

50

And so that is actually what we're going to do 51

51

in the Forkify project, 52

52

because it's a bit more complex than the Mapty project. 53

53

Now these days, in modern web development, 54

54

many developers actually use a framework like react, 55

55

Angular, Vue or Svelte 56

56

to take care of the architecture for them. 57

57

And so in this case, developers don't have to think 58

58

a lot about architectures on their own. 59

59

And probably this is actually 60

60

a good idea at a certain point, 61

61

especially for large scale applications. 62

62

However, and this is key, as I said many times before, 63

63

it is very important that you really know JavaScript, 64

64

before switching to some of these frameworks. 65

65

And in my opinion, that includes knowing 66

66

how to implement an architecture by yourself. 67

67

And so that's what I will teach you with this project, 68

68

among many other things of course. 69

69

And so this will make it so much easier for you 70

70

to learn React, or Vue or whatever framework 71

71

that you choose later down the road. 72

72

Now no matter where the architecture comes from, 73

73

and who develops it, 74

74

there are some components that any architecture must have. 75

75

And that is business logic, 76

76

state, an HTTP library, application logic, 77

77

and presentation logic. 78

78

So business logic is basically all the code 79

79

that solves the actual business problem. 80

80

So that's code that is directly related 81

81

to what the business does and to what it needs. 82

82

So if your business is what's up, 83

83

then your business logic will include sending messages. 84

84

Now if your business is a bank, 85

85

then one of the many parts of business logic 86

86

will be to store transactions. 87

87

But if you business is a budget manager, 88

88

then your business logic will certainly 89

89

include calculating taxes. 90

90

So you get the point. 91

91

So essentially, business logic is the logic 92

92

that is really related to solve the problem 93

93

that the business set out to solve in the first place. 94

94

Next is the state which is one of the most important aspects 95

95

of any web application. 96

96

So the application state is essentially 97

97

what stores all the data about 98

98

the application that is running in the browser. 99

99

So the data about the applications front end basically. 100

100

So the state should store any data 101

101

that you might fetch from an API 102

102

or data that the user inputs, 103

103

or what page the user is currently viewing and so on. 104

104

And this data should be 105

105

the so called single source of truth, 106

106

which should be kept in sync with the user interface. 107

107

So that means that if some data changes in the state, 108

108

then the user interface should reflect that. 109

109

And the same is true the other way around. 110

110

So if something changes in the UI, 111

111

then the state should also change. 112

112

Now storing and displaying data 113

113

and keeping everything in sync 114

114

is one of the most difficult tasks 115

115

when building web applications. 116

116

And that's why there are actually 117

117

many state management libraries like Redux or MobX. 118

118

But in this project, we will keep things very simple 119

119

and use a simple object to store our entire state. 120

120

Next, the HTTP library is simply responsible 121

121

for making and receiving AJAX requests. 122

122

And we have been doing that using the fetch function 123

123

and so that's what we will keep doing here. 124

124

And most real world applications of course, 125

125

need some interaction with the web. 126

126

And so that's why this is an aspect to keep in mind. 127

127

Now about the presentation logic, 128

128

this is the code that is only concerned 129

129

about the implementation of the application itself. 130

130

So it's more the technical aspects of the application, 131

131

which are not directly related 132

132

to the underlying business problem. 133

133

So for example, application logic 134

134

includes handling of UI events and navigation on the page. 135

135

That's the reason why this component 136

136

is many times also called a router. 137

137

So basically mapping actions to the users navigation. 138

138

Finally, the presentation logic, 139

139

which is also called the UI layer, 140

140

is of course all about the visible part of the application. 141

141

So essentially, we can say that the presentation logic 142

142

is responsible for displaying 143

143

the application state on the user interface, 144

144

in order to keep everything in sync. 145

145

Now any good architecture 146

146

has a way of separating all these components. 147

147

So instead of mixing everything together in one big file, 148

148

and in one big mess. 149

149

And so let's now take a look at a well established 150

150

architecture pattern that we're going to use 151

151

in this project. 152

152

And that is the model view controller architecture. 153

153

So basically, this architecture contains three big parts, 154

154

which are the model, the view and the controller. 155

155

Now the view is of course, for the presentation logic. 156

156

So it's the part of the application interacting 157

157

with the user. 158

158

The model is all about the applications data. 159

159

And so that's why it usually contains 160

160

the state and also the business logic 161

161

that manipulates the state. 162

162

So these two should be kept closely together. 163

163

Now, the model is also what contains the HTTP library, 164

164

that might get some data from the web. 165

165

So like from some API or some back end. 166

166

And so this is of course also about the data, 167

167

and so it also goes into the model. 168

168

Finally, the controller 169

169

is what contains the application logic. 170

170

And it kind of sits between the model and the view. 171

171

So it basically creates a bridge 172

172

between the model and a view which in fact, 173

173

should know nothing about each other. 174

174

So again, the model and the view 175

175

will exist completely independent from one another, 176

176

and not even knowing that the other one exists, basically. 177

177

And in fact, one of the big goals 178

178

of the MVC pattern so of this model view controller 179

179

architecture is to actually 180

180

separate business logic from application logic, 181

181

which makes developing the application so much easier. 182

182

But as a consequence, 183

183

we then need something to connect these two parts. 184

184

And so that is the controller. 185

185

Now let's actually take a look 186

186

at a typical flow of actions and of data 187

187

as soon as some event happens 188

188

on the user interface for example like a click. 189

189

So to start, it's going to be the controller 190

190

who will handle that event, 191

191

because handling an event 192

192

is doing something in the application. 193

193

And that is clearly part of the application logic. 194

194

Now, this handling might involve 195

195

updating the user interface and also ask the model 196

196

for some data. 197

197

So we can say that the controller dispatches tasks 198

198

to model and to the view or in other words, 199

199

it controls and orchestrates this entire action. 200

200

And in fact, the whole application itself. 201

201

Now asking the model for some data might, 202

202

of course involve doing an AJAX request to the web. 203

203

And so that's exactly what the model does. 204

204

Then, when the data arrives, 205

205

the controller takes the data and sends it to the view. 206

206

And so finally to finish the view, 207

207

will render that data to the user interface, 208

208

and finish this whole cycle. 209

209

Now in this diagram, you see two types of arrows. 210

210

So the dotted arrows represent data flow 211

211

between the different parts, 212

212

while the solid arrows represent 213

213

actual function calls and module imports. 214

214

So analyzing this, we can see that it's only the controller 215

215

who imports and calls functions from the model, 216

216

and from the view, but never the other way around. 217

217

And so as I mentioned before, the model and view 218

218

are in fact completely standalone and completely isolated. 219

219

So again, they don't import each other, 220

220

and they don't even import the controller. 221

221

And in fact, they don't even know 222

222

that the controller exists. 223

223

All they do is to basically just sit there 224

224

waiting to get some instructions from the controller. 225

225

And this part is pretty important to understand. 226

226

So take some time to really analyze this. 227

227

Now, there are actually different ways 228

228

of implementing the MVC pattern, 229

229

where some are more complex than others. 230

230

But this one is my favorite way of doing it, 231

231

because I think it makes the most sense. 232

232

But anyway, let's know see this MVC architecture 233

233

applied to the part of the Forkify 234

234

application that we already implemented. 235

235

And so this is a flowchart of loading 236

236

and rendering a recipe that we already implemented. 237

237

And then down there, there's also a reminder 238

238

of the MVC diagram that we just analyzed. 239

239

So in this flowchart, handling these events 240

240

is associated to the controller. 241

241

Then loading the recipe happens in the model. 242

242

So the controller basically calls 243

243

some function that is in the model. 244

244

And then the model asynchronously 245

245

gets the recipe data from the API. 246

246

And once that data has arrived, 247

247

the controller asks for that data, receives it, 248

248

sends it to the view, which will then ultimately 249

249

render the recipe on the screen. 250

250

And that's it. 251

251

So that's what every step of the flowchart 252

252

is associated to in the MVC architecture. 253

253

But this is still quite abstract. 254

254

Because remember, the flowchart 255

255

is simply what we will implement, not how we will do that. 256

256

And so let's go even deeper, 257

257

and actually take a look at a detailed 258

258

implementation diagram of or MVC architecture. 259

259

And again, this is only about loading 260

260

and rendering a recipe. 261

261

And let's start by noticing how both the model 262

262

and controller are implemented in a module, 263

263

while the recipe view is actually a class. 264

264

And we will explore the reasons for this 265

265

when we actually write the code. 266

266

But now once again, let's analyze 267

267

the same data and actions flow, 268

268

but this time in this real implementation. 269

269

So when the user clicks on a search result, 270

270

there is a control recipes function in the controller 271

271

and this is the one that will handle this event. 272

272

And how exactly that happens doesn't matter for now. 273

273

So we will come back to this later. 274

274

What matters is that this controller 275

275

will instruct the recipe view to render 276

276

a loading spinner while the user interface 277

277

waits for the data to arrive. 278

278

In the meantime, the controller 279

279

also called the load recipes function in the model 280

280

to fetch the recipe data from the Forkify API. 281

281

Now the model also contains a big state object 282

282

that we export from the model. 283

283

And this state will contain all sorts of data, 284

284

like the current recipe, search results, bookmarks, etc. 285

285

But anyway, as the data arrives, 286

286

it will be stored in this state object. 287

287

And the controller then reaches into the state object, 288

288

grabs the recipe data, 289

289

and finally calls the render method 290

290

on the recipe view with that data. 291

291

So in order to finally render 292

292

the recipe to the user interface. 293

293

So basically the exact same steps as before, 294

294

but this time actually implemented in our code. 295

295

well, at least in theory and so next up, 296

296

let's actually go from theory 297

297

to practice and implement this architecture in our code.