Node.js CRUD API Explained — and Why You Need Layered Architecture

[00:00:01]Hello everyone and welcome to a review of our first assignment.

[00:00:07]Our first assignment was to create a CRUD API.

[00:00:14]Here is the repository my colleague AIS created and I will upload it on the portal so all of you can access it.

[00:00:25]So here is the readme file. It uses as documentation for all of the endpoints that are created in this task. And I clone this repository on my locally and open it up with my text editor. I use cursor as my text editor. You may use anti-gravity or VS code or whatever text editor you like.

[00:00:56]So this is a small project and we put all the stuff inside one file because I want you to see that it's it can be done like that but also I would like to show you in this session uh why it's not the best idea sometimes.

[00:01:16]So yeah uh we can start uh from the top explaining all the stuff in this file.

[00:01:25]So basically on top of full files there's always these uh requires and or imports. Um require means go get me a tool and let me use it here. So basically it says uh get me express the tool someone built to create a web server.

[00:01:54]But I don't want to write that code once again. Please just reuse that code and uh by this line. Okay, we included express inside our app and we can reuse it. As you can see, we reused it here.

[00:02:11]So the same thing with swagger UI include swagger UI. Here we have dot slash open API JSON. This slash means that it's a file that's created in our repository. That's it's our own file. So yeah, here's a file. This is uh just for the scription uh that helps the swagger build the build the dogs page. What is doc page?

[00:02:42]This it's just for a better overview of our all of our APIs. So maybe it's best to show you how to start now the app. So in uh in order to start any of our apps on NodeJS, it's first important to download all the dependencies that our app has. And what are the dependencies?

[00:03:10]Dependencies are these packages here. So all of these packages were installed. we they are mentioned here in package.json JSON and you can see we have experts and swagger UI and so in order for us to start we have to type in npm. npm is node package manager. So let's say node package manager please install install or just e uh just I and it will install all of them. I installed them previously. So everything's up to date and then we are mpm start.

[00:03:52]Okay.

[00:03:54]Voila. Our server started. So how did it start? So first we have this con app equals express. This basically creates our app. From now on our app is server and it defined we defined port here port we use 300 I told you in previous lecture we can reuse any number it's just important that uh multiple different apps don't use the same port and uh and here we have app so this app use expresses JSON uh this uh it tells the app when request comes in carrying JSON read it for me. So without this line request body would be empty and post request would break. So uh it's important to include that one and on the bottom we can see okay app.listen we are starting this line actually starts the server. It means start waiting for requests on this port we defined at 3000 and yeah here is something called arrow function uh is small function we hand to listen.

[00:05:25]So uh it runs once the the m uh the once the server is ready uh this kind of run this when you're done it's called call back functions. So this we have here the callback function when the server is ready when it starts listening execute this function which will just log that like this that CR API is listening on port 3000. So this is we we can change this text and it'll be changed here next time we run the app.

[00:06:05]So okay now uh our app is listening and what we can do with it. Okay, if you open up local host host 3000 okay we already executed the first AP uh first API call and it's just on route just slash and here it is app.get slash request response response.json and here is the response. So this is basically for some probably for some dashboards if you want to add some initial data that you want. So and to to show which endpoints are publicly available. So uh /helt we you can see uh that the app that the server is live that it's working and it just returns the stats okay which is 200.

[00:07:02]After that we have tasks or let's see the docs okay we use swagger. So okay we have overview of all our endpoints.

[00:07:16]Uh if we go to fetch all the data all all the tasks we can go localhost tasks and we have three tasks in the beginning.

[00:07:35]Why do we have three tasks? because now we don't have the we don't use the uh database.

[00:07:46]Next week you will have you have two assignments where you're going to learn how to connect the database. One is SQL light and the second is uh dockerize posra SQL database. Uh but you will see they are pretty similar. It's just important for you to to understand what does it mean and what does it take to integrate something new.

[00:08:14]Here we sort all of our data inside the app memory which is okay we have seed tasks. So this these are the initial tasks that will be created upon starting the app. So when we started the app, we created the C tasks, created one variable task and we mapped all the C tasks there. Okay, now we have all tasks in one place. So if we call the function reset tasks, uh it will just push the C task, delete all of the task and uh put the C task inside this variable. So let's add one task because in using the browser we cannot just send the body with it. We are going to use swagger API swagger API. So we looking for post requests here is the tasks create task title by milk.

[00:09:22]Let's just execute this. We can change this to whatever we want. And we got the response to 101 which is response created which is good. New ID is generated. New title and then is false.

[00:09:38]So let's go through that route.

[00:09:43]What does what does this route do? So it first gets the request.

[00:09:53]Okay. Uh it gets the title out of the requests body and then we have this validation step.

[00:10:02]It checks if the title was undefined or if it was null or if it was empty. So then we have if if some of these are true if any of these are true we are going to get 40 stats code which means that the client made the problem. So that would be basically if we decided to do this and execute we will get this response title is required and cannot be empty. It's the same message. So so we can you can do the changes to these messages and it it's your job to make them as understandable and readable as possible.

[00:10:58]Then we create a new id based on the length of the how many tasks we have in this array.

[00:11:06]Then create the new object task which will be pushed in this u in this array and just return 2011 stats. So in the next assignments we will make changes to this to instead of this we are going to push this to our database.

[00:11:27]same we did with the so uh also one of the reasons why we have to use databases in first place is because this memory isn't um if we restart the server you will lose all of the memory you will lose everything so we don't have the milk one anymore if we go to get tasks. We don't have the new new item that we just created. So, let's recreate buy some milk.

[00:12:14]Okay. And now if we open up here test.

[00:12:18]Okay. We have this new also upon get requests. You can see here that there are some parameters that can can be used. Done. And search by string. Try it out. Milk. It will return only one that has milk word milk inside the title. How this works? If we open up get, so we use get tasks.

[00:12:50]We found this route.

[00:12:53]results equal tasks then filtering if requests has query done different from undefined. So if we go this okay we don't we have uh the done query parameter is undefined so this will be skipped but if it's present done equals true uh done equals true it will return only true only ones that are done. So here we have first handling if the value of parameter done is true or false because if someone sends like this true uh we are handling this and then we filter only the true ones uh the only done ones and we are good there. Also what you can do is you can send this response and so let's say false and search equals milk.

[00:14:21]So we have another step where we check if there's search variable search query parameter if it's defined if it's handled properly and then we get the response. So if we send this as empty there will be there's a validation step that says search must be not empty.

[00:14:47]Okay, but what uh if everything works, why is it problem to have everything stored in one place? So I created this image for you.

[00:15:01]Maybe it'll be easier for you to understand. But basically in this uh in this setup in this app we have four one route which is task and we have one two three four five different jobs it reads and also each of these functions.

[00:15:33]So each of these routes have different uh different steps. So this one has it reads the request.

[00:15:48]It uh gets the request body. It checks for the inputs.

[00:15:56]Is the title there? if it's empty the validation step three it does the thinking so it it picks the new ID it cleans up the title and then four it saves the data task tasks push it's that's saving data here and every other route does the same four jobs in their own way So for for a small to-do app this is fine but once the the app starts growing uh it this becomes a mess and big challenge for developers to m maintain and to make changes and updates and track where something might have gone wrong.

[00:16:52]So there's a idea that I want to share with you. It's called separation of concerns.

[00:17:02]So concern is just one kind of a job and handling the web requests is one job. The rules, the validation is another job. Saving the data is third job. So right now all three are tangled together in every function and you can't change any without yeah changing basically everything and you have to test one on its own. So let's separate them.

[00:17:43]same API exact same behavior just tidied. So each job has its own place and that's the layered architecture.

[00:17:55]So we will define we define here uh three main layers.

[00:18:04]So the first layer is the route layer. This layer will handle only the web requests.

[00:18:14]Read it, call someone and send back the answer. The server layer, service layer holds the rules, does the validation, does the thinking, the the business logic, generation of ids and stuff and then it it doesn't know not know anything about the the route that's calling it or the data.

[00:18:40]Data is the third layer we call it repository. And this layer it only works with data and it doesn't matter like which data will it use. It's b where the data will be stored. It's you it uses almost the same ways of working the same it it's basically almost all the same functions.

[00:19:05]And so if you change the database you will change only one layer and all the other layers remain untouched.

[00:19:14]So I prepared you the example of the layered architecture as well. So you can see that now indexjs is much smaller much much easier uh to understand.

[00:19:30]Uh here's yap.js JS and you can see upon creating the app now you have just all the routes here at one place. If you uh hold command and click here you can open up the the file that was referenced and here you can see that how all the routes for tasks are defined and you can see the difference how clean they are. So, so you can open the the the get tasks and you can see okay it just uses the list tasks function from the service and the service here is the task service and you can see the function implementation and okay this is the validation step and results are got you get the results from repoind all so repository function that's called find all which gets all the data. So I'm going to share with you this layered architecture example so you could uh go through it get to learn a bit more about how to how you can organize your code and try to implement this in your new assignments.

[00:20:55]This is a great way of doing stuff. It's really important to understand this because as I said previously, you are learning to organize your code and to you're learning how to read it and not just to write it because now the writing code is uh really pretty easy especially with the help of AI but organizing it and making it really accessible for everyone to navigate in and to make changes. That's where the skill is.

[00:21:41]So, I hope this video was helpful to you guys and yeah, uh see you in the next lecture. Please share your feedback with me. I'm really glad to hear what you think about this internship and how can I help you more with it.

[00:22:03]Bye.