Introduction

After this video you'll be able to add an MVC model view controller structure to your node applications. This is actually two classes combined into one video of our free 30-week software engineering bootcamp. If you've ever wanted to learn how to code you found the right place. We are 38,000 strong on Discord so if you have any questions that come up as you watch the video we'll I'll be happy to answer them. That's leonnoel.com slash discord. See you soon. Yeah, hey, good morning, good afternoon, good evening, no matter where you're coming from. Hope you all are doing well. Hey, does this work? Hope you all are doing well. Hey, welcome back. Another week, another dollar. Let's get it done. Hey, you got speed. Hey, what's going on?

Rascal2 with the raid. Thank you for coming through with the crew. What's going on, everybody? Hey, hey Thompson in the house. Hey, got to meet some of you out the meetups. I love it. I love seeing everybody's seeing each other at meetups. I got to go to meet us. I got to go outside. You know how I am. I'm online, but now I got to go outside. What's going on everybody. Welcome back. Welcome back tonight. We get into some M V C adding some much needed architecture to our crud to applications, our full stack applications.

It's one of the most important things we'll cover as we get to the tail end of program. So quick things, no slides for tonight. We're jumping right into code. So no worry about having slides or anything like that. We have one image I'm going to share with you and the starter code is on our Discord. If you're new around these parts, you can do exclamation point Discord and that'll get you all the code that you need for today. Hey, what's going on? So since there's no slides, I'm going to ask everyone, please check in exclamation point, check in. If you have not already, uh, that does not check you in, but it gives you the link, uh, for tonight's tweet. Go ahead and like, retweet that for me, please. Uh, and if you haven't already, if you need to catch up, if you're to catch up crew. Class 44 and 45 are now on YouTube. I would appreciate folks giving that a thumbs up just to help with the algorithm. It's been a while since we posted the YouTube. Let's make sure that that video doesn't tank.

I'm good to see everybody. Hope you all had a wonderful weekend. Hey, what's going on, everybody? As always, I always like to start off with a few questions. Let's give folks a few seconds to get in here. You have some questions. I got some Go ahead and shoot off your questions here in chat. Happy to answer. Do we fork the code for class tonight? That's up to you. You can always fork and clone it down if you want. That way you have like your own version if you want. Eventually I'm gonna ask you to add on to this. So if you want your own version, that's okay. It's okay just to clone down to.

Will baby learn coding too, if they want, I hope they do, but that'll be up to them. Is that cold brew coffee? No, it's, um, it's, uh, it's like an honored Palmer in a can. Yeah. Uh, what version are you using? Yeah, this is the MVC version. Uh, the link to the code is in today's discord message in the following materials channel We need 100 days meetup convention, you know there's a lot of things that I want to start like Once we get to the end of this cohort and I have a chance to really kind of have some more time to to To invest in things that aren't in class. That's one of the things people have asked for a long time I think that could be fun to do something or maybe like attached to another convention that's already happening but have our own meetup Yeah, I think that'd be fun. Yeah. So I'm about it. There's a lot of other big projects too that I want to get going. I've been working shop in this idea called a hundred maintainers. So there's a lot of projects that I think could really benefit the community. A lot of tools and resources that I think could be really helpful. And so I would love to find a way to have folks that want to contribute through writing code and helping build those projects have an avenue to do that, which is another thing that people kind of ask for.

So lots of stuff to do, yeah. And it's also been really cool seeing so many folks build so many wonderful things for 100 devs. I want a way to like highlight them and make them feel a little special. So 100 maintainers is coming soon. Lots of little things that I wanna be able to have some time to focus on, which I think will be fun. What about translating to other languages? So I would be down. One of the problems, though, is that I wouldn't want folks to not get the support that they need. So our Discord is English, right? And that's just because we can provide consistent moderation in English and consistent support in English. My worry about translating to other languages, which I've definitely talk to like folks that wanted to help translate everything is that then they wouldn't get the same level of support. So something maybe way down the line, once we have more folks and more folks that want to help out in different languages could be, could be a real possibility. Yeah. But for now, probably not a little too much for us to take on. Leon, will we ever move on to other programming languages?

No, cause this isn't a coding bootcamp. This is a getting a job bootcamp. And right now the stuff I'm teaching is going to open up the most doors for you to get a job. Now, a lot of my students go on to learn other languages entirely during the job hunt. A lot of my students will go on to use complete different languages on the job. Um, but what you realize early on is that the languages that you learn right now really have no impact on your job opportunities. A lot of folks think that if they have to learn like the specific set of languages, they have to learn these very specific set of skills. But time and time again, it's not true. If you know the fundamentals, you have really strong projects and you show the ability to learn quickly. Uh, anyone can bang out a few tutorials over the weekend to add that skill to their, to their application. Should they need that on their resume or on their portfolio for that specific job? So by the time you leave a hundred devs, you're lean mean interviewing machines. And part of that is the ability to pick up new things very quickly so you can talk about them in the interviews so when we get to the hunt that's gonna be something we talk a lot about you're gonna Customize each of your applications to the company that you're applying if they are using PHP Then your application is gonna have some PHP on it, right? Even though it's not something that we touched during this program Also, each of your localities are completely different. The job market in each city is completely different There are some things that are really popping off in certain areas that aren't in others And so you're gonna add those little cherries on top.

And so that's something we'll talk a lot about I'm gonna show you how to do that quickly easily I'm gonna show you how to do that when we get there, but we're not there yet We got we got fundamental stuff core stuff to be focusing on that's gonna help you with any interview Not just kind of like a very specific really niche set of skills. And so that's what we're gonna build up to And the other thing too is like, right now I've helped students like in my day job in Boston, Philadelphia, Pittsburgh, even New York. Then I've helped hundreds of other folks get jobs around the world. And if you have a fundamental base of how you go about the application process, it really doesn't matter what you know. It really doesn't if you go about applying the right way if you go about the hunt the right way It kind of doesn't really matter your technical skills all that much So we'll get there. We're not there yet. Mm-hmm Do one or two more questions and then we'll jump in Best dad jokes since you've been, since you've been a dad, a lot of people blew up my Twitter DMS with dad jokes. I appreciate y'all. Thank you. Um, also, uh, I figured out like using, uh, the voice input on my iPhone has been a game changer. Uh, if you notice I reply to every ask Leon message. So if you ever, ever have a question that only I can answer, right. You ever have a question that only you think only I could answer, um, you, we have the ask Leon chat on discord. Sometimes it got really backed up, but I just cranked through over two nights, just using the voice input on my, uh, on my iPhone. And so if the, the responses seemed a little weird, there wasn't punctuation.

Uh, that was cause I was using voice to text, but I cranked through like 200 messages on um discord and then like a whole bunch of twitter dms and so uh yeah it was fun i had a lot of a lot of dad jokes um one was um i had a job crushing cans it was soda pressing that's what you came here for folks that's what you came here for All right, I can't see the question. Does anyone have trouble running today's code on the server? Yes, you should not be able to run my code because your IP address will not be whitelisted on my MongoDB instance. So even though I have the ENV file in there, it's not something you're gonna have to get, you're not gonna be able to get that running. You're gonna have to connect your own MongoDB instance, like your own Mongo Atlas instance for it to work fully. Cool. All right, folks, let's get into this. Lot of fun stuff to cover tonight. But the big thing that we are covering is MVC, Model View Controller. When we first started, when we first started 100 devs, there was one overarching pattern that we always used, right? What was that pattern that enabled us to work with other developers? What was that pattern that was our guiding light in the beginning? Yeah, it was separation of concerns. So this idea that we were gonna keep our HTML separate from our CSS. We're going to keep our JavaScript separate from either of those things, and we wouldn't mix it.

And the reason why we did that, right? The reason why we did that is so that when we were working with other developers, they knew where to go to make changes, right? So if they wanted to make something pink, they went to the CSS. If they wanted to add another paragraph, they went to the HTML. If they wanted to make something wiggle, they went to the JavaScript. and if all our developers are following those separation of concerns, it made our job as developers easier and enabled us to have a little bit of abstraction, right? A little bit of abstraction, meaning that we could focus on just the HTML and not worry about breaking the JavaScript. Now MVZ model view controller brings that same level of ability to work with other developers. It brings the same level of organization to our backend code. Right now we're doing stuff that's a hot mess, right? For the longest time when we first started out, right? When we first started out with our backend node code, we had all of our node in one big file. We had our HTTP module, we had our FS module, and there was a lot of stuff in that one file. What would be a major problem of having all that code in one file? It worked, we could build a full stack web application, but what was some of the problems with having all of that in one file?

Yeah, it was messy. It was hard to debug. One edit could break it, right? Hard to maintain, right? And so there's a lot of things here, right? If all of our code was in one file, it's really hard for us as a development team to work together to build stuff, right? We're always afraid that our one change which will break everything else. Also, we don't have the ability to hand off different parts of the project to different members of our team. And so as we get to the end of program with 100 devs, we're gonna be building a lot of big meaty projects. So we built a to-do list, which is a great kind of example of how things work, but we're gonna move into building social networking apps. We're gonna build an Instagram-like clone together with all the bits and bobs. And then you're going to have some projects where you're building full stack apps together as a team, right? Developers very rarely work alone, and so we have to practice those skills as what it means to work as a development team. And so MVC, Model View Controller, brings a level of organizational to our code that enables us to work well with other developers, to make changes and not lose sleep at the end of the night and to know where to go when we want to make those changes at the end of the day, right? And so just like separation of concerns helped us on the front end, MVC is going to help us on the back end.

Cool. So I love this image. It's from the Goat Traverse Media. It's from one of their original videos that I had you watch. If you have not watched their video that I gave you for homework, You must watch that video. It's super important. You have to watch that video. So I love this image from them from them We're gonna use it for the first walk through MVC And then we have a little bit more of a complex one that we're gonna walk through so shout out to the goat So many wonderful videos so many great videos on MVC specifically as well So definitely give those a watch as well. Now. I'm gonna give a warning before we jump into it Tonight is about seeing and understanding the why, why we make certain decisions, why we do certain things. I don't need you to walk away with the raw, knowing how to build and knowing the exact code, right? That's not the goal tonight. The goal tonight is to understand why, to ask lots of good questions about why we do things this way, what we might benefit from by doing it this way, but the nitty gritty details, it is not for right now. Right now, we are gonna have office hours on Sunday. So anything that doesn't make sense tonight, no worries.

Come back on Sunday. We're gonna take as long as we need to make sure everything sinks in and that we can actually follow all the nitty gritty. I am going to be jumping around a lot. I'm gonna be showing you a lot of different Legos that we have to build together. If you haven't done the homework, if you haven't taken a peek at this code, it can be a little overwhelming at first. That's okay. Give me a chance to walk through it, ask questions. We're gonna take our time and we're gonna come back on Sunday and do it from scratch. Meaning we'll type everything out. We'll see it line by line, okay? You have to give yourself some grace with this level of organization. We're taking something simple and adding some complexity so that in the long run, we can be more organized and be able to make the changes that we want to change and be able to work with the team members we want to work with. So okay, it's okay. A lot of times it can be overwhelming for the first run through, that's okay. We're gonna come back on Sunday and do it again.

But my goal is to get the why to you and for you to understand at a high level concept what MVC can do for you. Cool. We ready? All righty, so I have a very simple application. Here I have my application running on localhost 2121 and I can refresh this page and it takes me to this wonderful homepage. I also have the ability, right? I also have the ability to click on new to-do lists and be taken to a different page that has my actual to-do list on it. So what you might have noticed, and it's a little hard to see, it's a little tiny, up here, the route is to-dos, and on localhost 2121, it's just my root route. So now we have a little bit more advanced routing, right? We have a little bit more advanced routing, meaning that we can have like our homepage, right? And we can have our to-dos. More pain, go take a nap. You don't have to be here. Catch the VOD, go to sleep. If you're sleeping, go to sleep.

Anybody here that's sleeping, go to sleep. You don't have to, watch the VOD. Take care of yourself. Why are you here? Go take care of yourself. Health first. All right, so we have two different routes, right? We have two different routes. We have our homepage, right? And we have our to-dos. Now, the wonderful thing here is we are gonna set up our code to start listening for all these different routes, to start listening for all these different types of requests and we're gonna add organization to walk through them. Now with MVC, we have a very common pattern. We have our users that are our client-side devices and these client-side devices are going to make requests. So far, we've seen a structure that looks like this. We had our client-side device on the left and we said we made requests to our server and sometimes that server would make requests to our, let's say, database if need be, right?

And so for all the applications we've seen so far that were full stack applications, we had clients making requests, our servers were set up to hear those requests, and then the server had some code running on it, right? The server had some code running on it that could hear those requests, and then know what to do. What was that code that could listen for our requests and know what to do that was coded to know what we do? Yeah, that was our API. Our API was set up to listen for those requests and then know what to do. It really doesn't change when we introduce MVC. When we introduce MVC, it's just a little bit more layers in who's hearing the request, who's handling the request, and then what happens. But the same idea exists. Our client side devices are making requests to our servers, our servers hear those requests, and then a bunch of different stuff can happen. The problem right now is the server side that's listening for those requests, all that code was really just in one file, right? It was in one location. And when you start to work with more and more people, what are some problems we're gonna run into by having our API in one singular file, all the server stuff in one singular file, everything that needs to happen server side in one file, what are some problems that we're gonna run into? Organization could be a problem. Confusion on how, on how to change things absolutely can be a problem. Never find anything when it's too big, no encapsulation.

Ooh, love it. Yeah. Too much overload. There's too much going on. And right now, when it's just you, right? When you're just by yourself, and it's just you working on an application, you can work through the muck, right? No problem, work through the muck, you'll get through it. But when you are working with a team, you need to be able to hand off different pieces, right? You need to be able to hand off different pieces for different people to work on at the same time. If all your code is in one singular file, then it's not only like hard to walk through everything, but how are you gonna make changes at the same time? Also, what if something breaks? It breaks all the other code. And so while this has worked so far with our server having all the kind of code in one location, one file, we really need to move away from that so that it's easier for us to work on the same projects together. It's easier to debug and find our errors. It's easier for when something breaks, it doesn't break the entire project, and that we can start having some interchangeability in our code base, which I'll explain in a second.

Cool. So to get around having all of our code in this singular location, our singular server.js file, we're gonna introduce an architecture paradigm, a way of organizing our code that makes it easy to do all the things we just talked about. So we still have our client-side device. And this person right here represents our client-side device. They are using a browser, whether it be Chrome, Firefox, Safari, whatever you want it to be, they're using a client-side device. Now, they are going to make requests from this client side device. And as that request comes to our server, there is gonna be some code that's listening for this request and knows where to go next, right? So the router is kind of the first touch point. The request has left the client side. the router hears the request and the router wants to hand off that request to a controller. And you can think of a controller as just someone in the middle, a middle person, right? Somebody that's gonna hear a specific request and then know what to do with that request. To either maybe hand off that request directly to a view, they maybe hand that request off to a model, which we'll talk about in a second. and it's gonna know what to do. Kind of what our API has been doing, right?

Like it knows what to do. We're adding another level here. So our clients make a request. The first touch point is gonna be a router and the router is gonna hand off that request to a specific middle person. That middle person then knows what to do with that request. So you can see our applications starting to have a bunch of controllers that are all coded, right? That are all coded to do different things. A bunch of Smurfs sitting on the block that all know what to do when certain requests come in from the client. Cool. A traffic Smurf. Exactly. You can think of our controllers as traffic Smurfs. Now, the beautiful thing about this is sometimes our web applications are gonna wanna do simple stuff and sometimes our web applications are gonna wanna do some pretty complex stuff. Let's think about this very first thing that I did here, where I was just on the main page, I refreshed the page. What type of request did I just make from my client side device.

I made a get request to my server. Now, what do we know? What is the thing that's going to be expecting that get request? What's the part of my code that we're now gonna have? We're gonna see the code in a bit, but let's talk higher level. What's the thing that's gonna hear that get request and know what to do? API's right, like that's what we're still building here, but we're adding another layer here, the router. The router's gonna be the first thing that hears that request come through. The router hears that request and they go, hmm, you made a get request on the root route. I know what controller you should go talk to. So the routers really good at like looking at the URL, right? The routers really good at looking at the URL. And when I refresh the page, I made a get request to my server, right? Exactly. I made a get request to my server.

I made a get request to my server. And the router was like, you know what? I know somebody that can handle that for you, right? You're trying to go to the root route. You're trying to make a get request. I know just the person to handle this request. And so there was a Smurf that was in charge of hearing any get requests that are on the default route, right? I'm in charge of hearing any Git requests on the default route. So the router heard the request coming through and said, you know what? I know who to talk to. Go talk to this Smurf. Their sole job is to handle any request that is a Git request on the default route. Cool. Now, this Smurf could do a bunch of stuff. This Smurf could, if it needed to, use our model to go and talk to the database.

Our Smurf could generate some HTML with our views, right? And so if we look at the refreshing of this page, what does this Smurf need to do? Does this Smurf, I keep clicking on the, I'm just gonna close these. Does this Smurf need to talk to our database at all? I'm just trying to refresh the main page here, right? Refresh the main page here. Does my Smurf need to go talk to the database? Absolutely not. There's no data that I'm pulling from my database. That is just some straight HTML that I need. So my smurf is going to go directly to my views and I am still using EJS so it's gonna generate some HTML via EJS right and once it has that HTML my smurf can respond back to my client with that HTML, right? So the client, the user, refreshed the page. The router was like, yo, I know which Smurf is ready to handle that request. There was a Smurf or controller that was set up to handle get request on the main route, and that Smurfs sole job was to just go and deal with our view engine, which in this case is EJS to get some HTML. And once it has that HTML, that Smurf responded with it, right?

So this MVC architecture is gonna come down to a few key pieces. the router, hearing the requests coming in, and knowing which controller or Smurf is set up to handle those requests. You can imagine our application having a lot of Smurfs, all that are set up to handle different types of requests. Some might be set up to hear a get on the main route. Some may be set up to hear a post on the main route. Some may be set up to hear a delete on the other route, right? Like all these different smurfs can be set up to handle different types of requests that are coming their way. And each smurf or each controller gets to decide what it's going to do, right? Sometimes they're just going to use our views, which in this case is our EJS to generate and render out some HTML. Sometimes our Smurfs will need to talk to our models and our models are the only thing that can talk to our database. Let me say that again. our model is the only thing that can talk to our database. So requests will come in from the client side to our server. Our router will hear those requests coming in, know which controller to talk to, and sometimes the controller will use EJS, our view engine. Sometimes the controller will talk to the model and the model will talk to the database, right?

But it's up to us to code out what the controller does. And the beauty of this, right? The beauty of this is if we separate out our concerns, if we have a controller that has the ability to talk to the views, that has the ability to talk to our models, and they are all separate, that gives us the ability to do some really, really cool things. So right now, for my views, I am using EJS. It's in the game. What are some other things that we could use to handle our views? What are some other things we could use to handle our views? Handlebars, pug, react. So let me put some of these down here. your handlebars, pug, react, right? All of these different things can be written to handle our views. How about our database? We're using MongoDB, but what else could we use? What else could we use? SQL, right?

like Postgres, SQL, whatever, right? Anybody has like a really cool one. MariaDB, Firebase, yeah, let's put it on there. Firebase, MariaDB, CouchDB, whatever, right? So we could use all these different types of view engines or things to handle our views, whether it's the EJS that we're using, Handlebars, Pug, React, we could use different types of databases, SQL, MongoDB, Firebase, ReDB, CouchBee, it doesn't matter. If we build our application with an MVC structure, does it matter what we use to render our views? Like if we decide to change from EJS to Pug, does any other part of our application have to change? No. And if we decide to change from MongoDB to SQL, does any other part of our application have to change? No. And exactly, and that's the beauty of it. If we follow MVC, Model View Controller, and we separate out all of our concerns, we abstract out all of our concerns, right? It doesn't matter what we use to handle our views. It doesn't matter what we use to handle our models, like that can talk to our database. We can swap out whatever the heck we want, and our applications still work, right?

So, what I want us to think through is, all right, if we're gonna build an application, right? If we're gonna build an application, and right now our applications use EJS, our applications use MongoDB, And we build out some really good applications like we build out our to-do list, we build out our Instagram clone, we build out our couple big projects that we'll do as a team. And you have an interview with a company that uses Pug. Pug, what do you do over the weekend? What do you do over the weekend? Learn pug and then just change the views, right? If you, right, if you are going to apply to a company that uses Postgres, right? That uses Postgres, you take the weekend, you learn enough Postgres, and do you have to rebuild an entire application? Do you have to rebuild an entire application? No! So you just swap out the piece here that they need to see, or you just swap out the piece here that they need to see, right? And so the beauty is if you can learn MVC, if the concepts can make sense, if you understand how to build out this layer of abstraction you get a whole new level of flexibility, a whole new level of modularity that serves you so well going into the hunt. So tonight, I'm gonna walk through our to-do list using MVC with EJS, MongoDB and Mongoose for handling our models, but know that we could swap out any of these pieces to do whatever the heck we want. And so that's why I don't think it's worth it to over invest in one area. We can learn the core, build out a bunch of projects together that use this core.

You understand the core. And then when you have to make these little changes or tweaks, you do it. So we'll start off by building the to-do list and our Instagram clone using EJS. And then we're gonna put this in the practice because we're gonna swap out our views for React, right? We'll redo it with React. And then if we have a little bit of time at the end, we'll do it again, but we'll swap out Postgres. But we're still reusing the stuff as needed. Cool, so that's the goal. The idea of MVC is that it brings this level of modularity, abstraction, but once you understand these concepts, it is a game changer for your job search, right? For the hunt, cool. Let's think about another request here. Just to think through it, we're gonna dig into some of these concepts deeper, right? We're gonna dig into some of these concepts deeper. Don't worry, like, yeah, I don't really understand what a model is. That's all right, we're gonna see that in a bit, right?

For now, know that the router is the thing that's listening for the requests, right? And the router takes those requests and knows which controller to hand that request to. Each controller knows what it needs to do. Sometimes the controller will go and talk to our model, which can then get some data from our database. And then once the controller has that data, what it can do is pass that data to the view. The view can use that data to help build out the HTML and then the controller can send that HTML back to the client. So a lot of times the controller is talking to a model, getting some data, then passing that data to the view so we can build out the HTML. Once it has that file, it can respond back to the browser. Will there be more than one controller? Yes. Every big thing that we have to do will be handled by a different controller. So you can think about every single request that we make to our server having its own controller. So right now, when we refreshed our page, we made a request, right? We made a request and our router heard that request and knew which controller to go talk to, right? When we are on our to-do list, there are so many other requests that can be made.

One, we just made a get request by loading this page. We can delete stuff, we can post stuff, we can update stuff, all of which are requests, all of which are gonna have their own controllers. Now, once we understand that everything's gonna have like its own controller, we can also start organizing our controllers. So I'm gonna have a bunch of controllers just for my to-do list. The controllers that handle the creating, the reading, the updating, deleting, thing, but I also might have controllers that just handle like the home page and like the basic HTML stuff, right? So we're going to see that in our code today that yes, there's so many different controllers that we're going to have. We can also organize those controllers based on the different parts of our apps. So I'm going to have like my home controllers and I'm going to have my to do controllers and connecting all those pieces is what we're going to work on. Yeah. Dumpster dev. So the controllers akin to each API logic. Yeah, it's starting to the controllers. The thing that can be our API and know what it needs to do. Does it need to go talk to our views? Does it need to go talk to our models which can talk to our database?

The controller we write to know what to do for each of those scenarios, for each of those requests. We used to know HTML, exactly. We used to not know HTML, exactly. Y'all have come so far. Like I said, this is a big topic. There's a lot of little pieces we have to connect. And so what I want you to do is just realize, all right, right, these are Legos. We're learning how to put all these different Legos together. That's okay if it feels a little overwhelming at first. We're going to walk through it step-by-step to see how it all comes through. What's the point of the router? The router is just so that we can organize all the different requests that are coming in. There's a lot of different requests that are coming in, and we want to be able to pass those requests off to individual controllers. So some people put the controllers able to hear the requests. I like one more level of abstraction because what'll often happen is I wanna be able to think about all the requests that are coming in independent of what needs to happen when that request comes in, right?

Like hearing the request and knowing what to do are two different bits in my mind, right? So the router is an actual router. Exactly, it just routes that request to the right controller. Yeah. Does it matter which browser the client uses? No, it doesn't matter which browser the client uses because it's always the same kind of requests. When I refresh this page, I have made a get request on my root route. Does it matter if that request came from Firefox, Safari, Chrome, it doesn't matter. It's still the same kind of request. Yeah, so these requests are coming from the client side and those requests are making it to our server, right? Are making it to our server. The first thing that's gonna hear that request is the router and the router knows which Smurf, which middle person to hand that request off to, right? Cool. So MVC is server-side then. Yes, this is all about organizing our server-side.

That's all this is. It's just adding a level of organization to our server-side code so that we can work more efficiently as a team, know where to go to fix bugs when they happen, and to add a level of modularity so that if we get disgusted with EJS, we can switch to something else and the rest of our code base still works. All right. How many routers can a major site have? A lot, like a lot, a lot. There was this, hold on real quick, I'll show you this. It's called Hackathon Starter Kit, I believe it was called. And the cool thing about the Hackathon Starter Kit was that it had like a really good, it was like a really good boilerplate for starting an application. Like if you were going to a hackathon, and I just had everything already done for you. And so let me just show you this real quick because they've thought through it. So here is their router and controllers all in one page because you gotta think about it. Every single request, every single request needs to have its own, like we hear the request and then what controller do we use? Here's the request, what controller do we use, right? Here's the request, here's the controller that we use, right? And so think about all the things you can do on a normal web application, right?

We can go to the main page, we can log in, we can log out, we can reset, sign up, log in, right? All these different routes that we're listening for and all the different controllers that we're using. controller. That's going to happen a lot. And then look, even for our API, like all the different routes for our different APIs that we could use, right? It just, it just can be really, it can be overwhelming. I think this looks really beautiful and elegant, but that's kind of what we're getting ourself into. I'm not going to start you with that. We're going to have some really simple code to look at. That's a little overwhelming, right? But that's the idea. every single request that can be made in our application, every single request, right? It needs to be heard by the router and passed off to the right controller, right? And then those controllers know what to do. That's the API code that we're writing, right?

Knows that whether to just hand stuff straight off to EJS and render the view or to talk to our model, which can then talk to the database and all that fun stuff. Cool. Now, we are today going to see high level, right? This is a really meaty topic. There's a lot for me to show you. There's a lot for us to discuss. Like I said, we're going to come back Sunday and see it all again. There's a lot of big words, a lot of big terms that I'm not going to use tonight. I'm going to skip them. And the reason why I want to skip those big terms is not to confuse you, right? to not overwhelming a lot of folks, but because I also want you to do something for homework. For homework, I want you, right, I want you to build a lecture on MVC. So we've already talked a lot about MVC, Model View Controller. I want you to build a lecture, slides. If you had to explain what NBC was to someone else, and you had to do it lecture style like I do for you each each and every single night.

I want you to walk through it. Now the reason why I asked you to do that is because this is such a fundamental part of the rest of program and the rest of your career as a software engineer that I really want you to nerd out over some of the details to really understand what a model is to really understand what views are to really understand what a controller is. And one of the best ways to really understand something is to teach it to someone else. So to get that into our brain, right? To get that into our brain, I need you to build an MVC lecture. So that's what you're gonna be doing. So hopefully you're taking some questions tonight, right? Hopefully you are going to internalize some of this, but the idea is to take what we learned tonight and build a lecture to help make it stick in your brain to be able to explain it to someone else that'll walk through it. So at some points, I'm gonna give you a cheeky smile. That's on you, that's your job, right? Because I'm gonna skip over a couple big things, right? That I want you to figure out a way to define and explain on your own in your lecture. Now, I'm a terrible teacher though. But no, you're not, because here's the thing, everyone explains stuff differently, right? Everyone explains things differently.

And you have to find your voice in explaining things. Because guess what you're going to have to do on the job? On the job, you're going to have to explain your code. And one of the hardest things we can do, one of the hardest things we have to do is get used to explaining things and coming to those conclusions on our own. Right. And so we're going to cover a lot of stuff tonight. I need you to not really like to, to, to, to lean on yourself. Right. Right. To lean on yourself tonight, tomorrow into Thursday, to figure out how to explain these things in your own voice, right? To in your own voice is the really important bit here. Not on me, not on somebody else, but to really internalize, all right, MVC is something really important. I need to explain this to other stakeholders. I need to explain this to other individuals. How can I do that, right?

We have to start practicing this, right? we have to start practicing this. It's something that you have to get better at. It's something that you have to start doing. And so tonight, after we end, I'm gonna ask you to build out this lecture so you can get used to explaining things. Now, the easy thing to do would be to run off, right? And watch a bunch of videos and then just copy what they say, right? Now, I'm not saying don't watch the videos. I'm not saying don't consume other content, but it has to come from you, your own voice, right? And so with this hard topic, with this difficult topic, practice explaining it to someone else, right? In your own voice, on your own. This is one of the few things where I say you have to work on it on your own. Don't work with others on this thing. Take the time, push yourself, understand it. But we got plenty of stuff to cover tonight.

We're gonna walk through MVC plenty of times. You're gonna see the code. We're going to see it in action and I'll send them. We're going to walk through it again, but know that your work is to build a lecture, explaining it to others. Cool. Now I'm going to ask for these slides. I think I said Thursday, but I'll, I'll actually ask for them on Tuesday. So I'll give you a week to work on this. Uh, and then I'll collect all the different, um, I'll collect all your different, your different lectures, right? I'll ask for you to submit your lecture and then from these lectures I'll randomly pick one and as long as it's good as long as you put effort into it Right as long as you put time and energy into it and it was good That person that wins I will personally help you on the hunt So I'm gonna help you find the companies you should apply to I'm going to work through your story I'm gonna work through your resume your portfolio. I'm gonna work through your 100 hours project. We're gonna spend a significant amount of time Making sure that you're set up a hundred percent for the hunt. So there's there's a pretty big incentive on the line for getting this lecture done, so Trust me on this It's one of those things that seems like an odd request but please trust me that you want to do this exercise. It will help you not only understand MVC, but get you used to something that you're going to have to do on the job. A lot of times, especially as entry-level engineers, you get assigned a ticket, something you have to do, you do it, and then at the end of the day, you have to say what you did.

At the end of the week, during your retrospective, to say what you built. You have to get used to like learning quickly, understanding complex stuff, and then communicating that to others. It's an invaluable skill that's gonna help your first 30 days, 90 days on the job, right? It's huge, you have to do it. Alrighty, so let's go ahead and we're at the top of the hour so we're gonna take our break. When we come back from break, we're going to talk through MVC again. We're going to see code so we can start to see like, all right, you're talking about routers, you're talking about smurfs. I need to see it. When we come back, I'm going to show it to you. We're going to walk through it so you can see what's actually happening in our code base. If you need the code exclamation point discord and the following materials, there is the code. All right, folks, let's put five minutes on the clock. Should we include a script with the slides? That's up to Depends on how deep you want to go into it, all right? Depends on how deep you want to go into it.

But I think the more you put into these kind of, some folks see them as silly, but I've, I'm telling you, the folks that put time into this assignment, they just, it just clicks more than it does with others, right? So it's up to you the length, it's up to you how much effort you want to put into it, but how could you convey MVC to someone else? All right, that's the goal. Oh, all right, folks, come on back. Somebody re-teamed two more minutes, but we'll apply that to the next one because the timer had already started. Lost says, I can't wait to see these. I know, I'm excited. Cool. All right. So we talked a lot about this idea of different requests coming in. So I am going to talk through the first request that is coming in. We're gonna see all the pieces And then we'll come back to our lovely MVC to see if it makes sense to us to see if we are what actually happened here. How did it work? How did it work right? So let's talk through what happens here.

When I refresh the page here, I have made a git request. A git request. All right. So if we look at our code base, we have a lot of new code here. There's lots of new files and folders, There's lots of bits and bobs here that we're gonna have to talk through. But before I go through all these individual pieces, let's just, let's see if we can follow through what just happened there. So what we know with MVC is that we refresh the page. What type of request did we just make and what was the route? What type of request did we make and what was the route? Yeah, it was a give request and it was on the home route. Now, let me show you a nifty line of code. Look at this line of code right here. App.use forward slash home routes. So right here you can see I'm setting up my code to have two base routes. Either the default kind of like root route, in which case I would use all of my home routes.

And I have my slash to dos, right? So without even having to look at the rest of my application, right? We can look into the future here, right? We know that all of my like root routes will probably be in home routes and anything to do with my to-do list will probably have the slash to-dos route in it right so there are two different urls when i say route we don't have to get twisted here i mean the url like if we look at the url here we can see that i am on localhost 21, 21, right? 21, 21, 21, 21, 21. And that would be the root route or the default. However, when I click over to my to-do list, look how the route changes. Now we are on slash to-dos. They are two different routes, two different URLs that are gonna help us as we build out this project. All right, so we refresh the page and we made a request on the default route. Since I am on the default route, the router I am going to use is called Home Routes. Now, all the stuff I am about to show you, I gotta get big for this. All the stuff I am about to show you, you already know I am showing you variables, I am showing you objects and that's a maybe a function and that's it, right? And so yes, there's layers. Yes, there's Legos that we have to do, but these layers are important because it gives us structure, organization and the modularity to our code.

So it seems like we're doing some extra skips and jumps, but those extra skips and jumps enable us to break up our code into different pieces, right? And then we can all work on those pieces individually. And when we have a problem or a bug, we go straight to those pieces and we're not dealing with one giant, massive file. So when I see... All right, Siri, Siri trying to give me God, I'm taking this off, I gotta switch that. All right, there we go. When that get request comes in, right? When that get request comes in on that default route, I'm gonna use home routes. Now, what is home routes? without looking anywhere else in my code. What the heck is home routes? Just look at it. What is it? Don't overthink it. What is home routes?

It's a variable. It's a variable. Home routes is a variable. And that variable is holding something, right? We don't know what it's holding yet, but it's just a variable that's holding something. So let's go ahead and look at this home routes variable. If we look up here, home routes equals require routes slash home. So we have this ability to require, right? We have this ability to require, and what we have to do is we have to chase down this path. So I have to go look in my routes folder, and then I have to find home. So to figure out what home route is going to hold, right? To figure out what it's going to hold, I have to chase this down. So over here I have my routes folder, and then I have home. You can see my home JS here. Cool, so let's click on that.

Inside my home.js, you can see that it exports this router, right? It exports this router. So what's happening is the stuff that is here is being exported. It's being spit out, right? It's being spit out. So when I see this require here, routes home, what I am really doing is I am catching what was spit out of that home.js file. And this is what was spit out. So it was really just a fancy way, right? It's just a really fancy way of running the code that's in this file. That's all it is. It's just a really fancy way of running the code that's in this file. So when we refresh the page, like an import, exactly, exactly. So when we refresh the page, right, we refresh the page, that sent a get request on the root route. All right, let's take a look. Root route, use home routes, all right.

To know what home routes does, we have to come up here and we require, go into the routes folder, find home, right? Whatever gets spit out is what's gonna go here, right? Is gonna go here, right? Is gonna go here. Now, when we look at it, there's not too much going on here but there is one thing that's happening. What type of request did we make again? Right? What type of request did we make again when we refreshed the page? All right, so it was a get request on the main route. And what does the router do? The router does what? The router goes and gets the what? The router goes and hands off the request to the what? the controller that's right here, right? It hands off that request to the controller that's right here.

So our controller is right here, right? Nasty redeemed a spicy rant on the topic of their choice. Nasty, what is the topic of your choice? That was 100,000 channel points. I'm keeping an eye out for your response. You gotta give me a response or I'm gonna keep going. What's the topic of your choice? I didn't see them, uh, I didn't see them post it scam. Thank you for the posture check. First try slow mode. Yeah, no, it was a, it was a hundred thousand channel points, which you get by just being here. All right, I see. I'm going to keep moving on. I don't see your, I don't see your response. Um, so if you, uh, send me a, uh, a message, we'll do it.

Uh, next stream, maybe they accidentally hit it. That would suck. All right. I'm going to keep going. It was a mistake. It was a mistake. There's no way for me to give you the points back. Like I don't have the ability to do that. That's a Twitch thing. But we'll make it right send me a send me a message on Twitch. We'll figure out something else So if you wanted to use your points for something else Send me a send me a mod mail send me a mod mail and discord and we'll figure out what you need All right Let's get back to what we were doing That sucks, I'm sorry All right, let's take a peek We refresh the page, right? We refresh the page. You got got. That made a get request, right? We made a get request, right?

If we look at our server.js file, we set it up so that all of the root route requests use the home routes file. So home routes was telling us to go into the routes folder, find home, that's what we did. And boom, here is the router for the home routes, right? So now we got to check the create, read, post, delete, right? Was it a get, a post, a put, or a delete? It was a get on that route. So here is the controller that I want you to use, right? Now we could look at the Todos router. Look at this Todos router. The Todos router is gonna have a lot more stuff that can happen, right? If we look at the to-dos router, we can see the default route. We can see that we want to create a to-do for like the post, a put to market complete, a put to market incomplete, a delete request to delete the to-do, right? So the router for the to-dos has a lot more work to do, right? Whereas the router for the home, well, there's really like only one type of request here, right? There's really only one type of request here that can happen, and that's that get request.

So our router's really not doing too much heavy lifting. Now, somebody asked, Leon, why don't you just keep the routers here in the server.js? And that's because I want my server.js to be separate from my router, right? My server.js can sometimes get pretty bloated. There's a lot of stuff I need for like configuring the server. So I'd rather have my router be a separate piece, right? And a lot of times I wind up having my router handle all these different pieces of my project. And so I like to have them separate. Now, some folks will keep them all together. Some folks will separate them out. I find when I separate it out, it does help me debug a little bit faster and know exactly where I'm going. I also want folks to be able to look at my code and really have a good idea of what's happening just by looking at the code, right? Cool. All right. So we have that get request come in, home routes, why can't I say it after I say home?

Home routes, right, which we required, is set up to use this home controller. Now it's the same thing, right? It's the same thing. This type of require syntax we're gonna see over and over again. So for home controller to do its thing, it had to go to our controllers and find home, right? So if we look, I have a controllers folder, right? And inside of that is our home controller. If we look at our home controller, it exports a what? Now don't worry about this. I know we're jumping into this a little bit, but what is this file export? It exports an object. It's an object. So that makes git index a what? Ooh, who remembers? Who remembers?

Who remembers? Yeah, that makes git index a method, right? It's a method. And the reason we know it's a method is because it's tied to a function, right? So here is a function, right? It's a function and a function that's part of an object we call a method, right? It's a function that's part of the object, so we call it a method, right? Key value pair two, that is true, yep. And so getIndex is a method because it's tied to this function. And what the heck, right? What the heck does this function do? Yeah, it renders out our index.ejs, right? It renders out our index.ejs. So let's walk through all of this. All right, we refresh the page.

When I refresh the page, what has my client done? My client has refreshed the page, So that has made a what when the client refreshes the page from their client-side device. They have made a what? They have made a get request exactly a get request That get request makes its way to our server and the first thing that we set up on our server is a router that hears that request and and our router knows what controller to go talk to. So we have a controller called our home controller, and the router says, hey, go talk to the home controller, all right? Go talk to the home controller, all right? And the home controller is like, all right, well, I can do some stuff. What do you want me to do? Well, in this instance, since we have made a get request on the default route, what I want you to do, right, what I want you to do is to go and render out some EJS. take your EJS, right? Take your EJS, spit out some HTML, and then I want you to respond with that HTML back to the client. So my user, all they did was refresh the page. When they refresh the page, right? When they refresh the page, that made a request to our router. Our router, the sole job of the router is to know which controller to hand that request off to.

Because we could have so many different kinds of requests. Gets, puts, puts, posts, deletes, whatever, it doesn't matter, right? So many different kinds of requests that could be passed through. and the router knows what controller is in charge of handling that request, right? So it hands the route, that request off to the controller. The controller is like, oh, I hear that request. All right, since I hear that request, I know what to do. I'm gonna go to my views and I'm gonna ask the views to render out some EJS and when it renders out the EJS that's going to give us some HTML and then the controller is going to respond with that HTML back to the client. So request comes in, the request is passed to the controller from the router, the controller says all right I know what to do in this instance, let's go to our EJS, spit out some EJS, get that HTML, and respond back to the client, right? So a lot of steps are happening here, right? Lot of steps are happening here, right? What if a router doesn't have a particular method or controller set up? Then it wouldn't work, right? Like if the router's not set up to handle that control, Like if it doesn't know what controller to hand it off to then maybe nothing would happen Eventually we'll have like a 404 for everything Yeah So if the router doesn't have a controller to pass stuff off to it'll have a 404 controller And the sole job of the 404 controller will be to serve up the 404 page. That would be it Does MVC affect the user experience?

Is it any slower than how we're doing it? I mean, if we think about it, like at like a, an actual, like what's happening in the machinery type of thing, then yes, there has to be some sort of delay. It will ever be like, we're talking about speed of light here. Right. So will the user ever really notice it? No. Yeah. Larry, thank you for the hydration. Cheers to you. Yeah. Cool. Can you show us where the routers are? I can. Cool. So, I refresh the page.

Boom. Refresh the page. The very first thing that hears that refresh is, all right, what route was I on? I was on the default route, right? I was on the root route, right? I was on the root route. Since I was on the root route, I'm gonna use my home routes, my home router. This is my router file. It's gonna handle all the routes that are possible with this root route, right? So let's go take a look at that file. All right. What type of request was made? Oh, it was a get request on the root route. I know what to do. I know what to do.

It was a get request on the root route. I know to use the home controller. And, and not only do I know to use the home controller, I know what method to use. And that method is get index, right? Is get index. So if we look at the home controller, we can see the get index method does what? The getIndex method does what? Look, if we look at the home route, it said go to the home controller and use the getIndex method. Home controller, getIndex method. Home controller, getIndex method. What does this function do? It renders out the EJS. And when it's done rendering out the EJS, it responds. Remember that RES is short for response, right? short for response, we respond with that EJS, right?

So there's a couple levels here. The server set up to hear the requests, all right? It was a root route, so we go to our home routes, all right? It was a get request on the home route, so this is a get request on the home route. We'll use the home controller and we'll use this method, the get index. Cool. Now, we'll notice in the home controller, it renders out index.ejs. What the heck is index.ejs? What part of this MVC is it? It's our views, exactly. Our controller, because right now we're looking at the home controller, our home controller knows how to hand off the EJS rendering to our views, right? So that request came in and we can see the controllers doing the work. The controller knows what to do. The controller knows to render out the EJS. Cool.

So that's just a really simple one, right? This is like, this is as simple as we can get where we hit enter or we refresh. That is a get request on a root route. That git request comes in, the server knows to use our home routes. We know from the home routes that since it was a git on the root route, we're gonna use the home controller and specifically the git index method from that controller. That controller goes and talks to the views, which is our EJS. It renders out the HTML from that EJS template and responds. Now, the cool thing is we can go over here and we can look at our views and we'll see that there's an index.ejs in the views and there's a todos.ejs in the views. So our actual EJS templates are separated out into their own views folder as well. What does modules.exports do? Remember, the way we're linking all this stuff together, right, the way that we are linking all this stuff together, it seems kind of wild at first, right? That we're jumping from folder to folder to folder. How are we jumping, right? How are we jumping from folder to folder to folder? Well, it's because we are calling something, right?

We are calling something, And when we call it, it spits something out, right? So let's imagine we're going back to back in the day. We were little kids. We were playing on the block by ourselves. Well, sorry, let's not slip about myself. We were playing with lots of friends outside, right? We were playing with lots of friends outside and mom or dad came to the door and said, Hey, Leon, come home, right? Hey, Leon, come home. and I would come running, right? I would come running back home, right? The same thing is happening here with modules.exports. Somebody is making a call and then for this to work, this file has to spit something out to answer that call, right? So the way that we are connecting all these files together is one file is making a call and the other file is spitting something out to answer that call, right? Now, what we're seeing here is that a lot of times we're spitting out an object or eventually we'll also see that we're spitting out functions or we're spitting out very simple things that are built into Express, right? And so this idea of calling and spitting out is not using anything new.

We're using the same structures that we've been using since the beginning of JavaScript. We're using objects and functions. And so to separate stuff out into individual files, we'd still need a structure for the stuff that's in those individual files. And so we're not gonna make something else up. We're gonna use the structures that we're already comfortable with in JavaScript. So we'll use functions and we'll use objects and we can spit things out of files as an object or as a function. And so if we look and we're saying, all right, we're on the server JS, we're running home routes, home routes is being required. That's like mom or dad yelling for you to come home, right? that's yelling for you to come home and you need a response. So we have to go look at this routes folder, the home file to find that response and we can see it spit out the router, right? Express is doing some routing for us and it's spitting out that whole router for us. So the response, the response to this call, right? The response to this call is what is spit out here, which in this case, it's just all the stuff we see right here, right? So you're asking for something and something is being spit out to answer that request. Same thing's happening here.

We're saying home controller, all right? Well, here's home controller. It's requiring, it's making a request for something, right? It's making a request for something. and I don't even have to go and look to see what it responds with, right? I don't even have to look to see what it responds with because look at this. What is this right here? That dot notation. What's the only thing that we know can use dot notation? Like what's the only thing we've used so far that uses that dot notation? Objects, objects are the only thing that use that dot notation. So I am requiring, I am asking for something. I am asking something from this controllers folder. I'm asking for something from that home file. I'm asking for something to come here and I can just take a peek and see, oh, I know it has to be an object.

An object is gonna be plopped in here like that, right? an object's gonna be plopped in there just like that. And so if we go and actually look at the home controller, so I go to my controllers folder, I go to the home.js, we can just say, all right, it spits out this object. Let me grab this whole object here, copy, paste. That's all we did, right? We went to that file, we went into that folder, we went to that file, and we grabbed that object. We grabbed that object. And now that object is there for us to use. And we can use it. So if HomeController is now this object, it has a getIndex method. So when I do HomeController.getIndex, I'm using this object, I'm using this getIndex method, and what I'm really doing is just running this function. Right, I'm just running this function. Nothing has changed though. Nothing has changed. And so a lot of folks get, they get confused at this point, and that's okay.

I know it's a lot to come at you at one time It's the if especially if you haven't done the homework if you haven't done the reading if you haven't done the videos, right? If you haven't done any of that This could be really overwhelming, right? Everything I'm showing you is just organization That's all it is. I'm just showing you organization, right? You've already done this. You've already set up a get request, right? You've already set up a get request that goes and renders out some EJS, right? Right, you've already done that. All we're doing is we're adding some layers to what we've already done so that when we wanna make changes, we can, right? When we want to make changes, we can. So if I wanted a different, I wanted a different, I wanted a different, let's say, let's say I don't want this page to render for the homepage, right? I don't want this page to render on the homepage, right? What could I do? I don't want create a to-do list. I want some other file to change.

I could simply create a new view, a new EJS file if I wanted to. A new EJS file if I wanted to. And then all I have to do is know, all right, what's handling my get requests on the default route, right? Like pretend we are a brand new, I'm gonna get big for a second. Pretend we're a brand new engineer to this project, right? We're a brand new engineer to this project. And the very first thing I am tasked with is modifying the homepage, right? I want to make some changes to the homepage, right? So I have to figure out how to make changes to that homepage. What I'm going to do is just look at my code. All right, let's start. Homepage is the default route. So I'm gonna use home routes. Where the heck is home routes? Okay, I go to my routes folder and there is a home file.

So I go to my routes folder, home file. All right, so now I'm in my home file and I realized that when I'm loading that home page, right, that main page on the root route, that is a get request. So, all right, here's my get request. It's on the root route. Now, what happens when I load that page? Well, I'm using the home controller and I'm calling the get index, probably a method on that home controller. So, let me go and find the home controller. All right, so I gotta go to my controllers folder, gonna look for the home file in that controllers folder. Controllers folder, home file, and here we go. All right. I am going to wind up rendering out the index.ejs, which is part of my views. So if I want to change the home page, I know to change the index.ejs. So I know that's going to be in my views. So I go to my views and here's my index.ejs. Now the index.ejs, right?

The index.egs is very, very simple. I can put all my changes in here. So I can say, instead of create, I want to say make a to-do list. Right, make a to-do list, right? And when I go back and I refresh my page, now it says make a to-do list. I was able to step through all of my code, right? I was able to step through all of my code, right? because I understand that a request is coming in. Let me hand it off to my router. The router is going to hand it off to a controller. And if I find that controller, right? If I find the controller, I can see what it's doing. What EGS files is it using? What view template is it using? I can see all of that inside of the controller.

And then I can make the change that I want to make. And the beautiful thing, the beautiful thing is, instead of, when I make this change, am I worried about anything else breaking? Am I worried about anything else breaking? No. The funny thing is, I could go back to my home controller, I could change out this file entirely to be something completely different, and nothing else would ever break, or I don't have to worry about it. So now as a team, we can make all of the changes we want to the views and know that something else isn't breaking somewhere else. Right? And so that's kind of what we're getting here. There's lots of little layers here, right? Right? Lots of little layers here. What we're doing is separating stuff out. And I actually think the homepage route is a little harder to understand, right? Because there's only one thing happening. There's only one thing happening.

But stay with me, stay with me. Let's take a look at the to-do list. Now, I'm gonna click this anchor tag, right? I'm gonna click this anchor tag. If we use the inspector, right? If we use the inspector, we can see that this anchor tag is taking us where? Where is this anchor tag taking us? to the to do's route. So, slash to do's. Let's click on it, boom. Slash to do's. We can even see that my URL now has slash to do's in it. What heard that request? What's the thing that heard that request? The to do's request.

The router, exactly. The router heard the to-do's request and the router's job is to hand that request off to the appropriate what? The appropriate controller. I think there might be some learning happening. I don't know if y'all feel it, but I feel like there's maybe a little bit of learning happening here. Don't worry if the jumping doesn't make sense. I feel like there's a little bit of learning happening though. Let's hang on here. All right, let's hang on here. All right, so we went to slash todos. That request came through, right? The job of the router is to hand off that todos request to the appropriate controller. So let's take a look at our code. All right, started our server.js. Yes.

Now, was the route, the root route, or was it the to-dos route? It was the to-dos route. So which route file are we gonna use? Are we gonna use the home routes or are we gonna use the to-dos routes? We're gonna use the to-dos routes, right? Look, slash to-do, we use the to-do route. So where do I find the todos routes? I have to go to my routes folder and look at the todos file So let's go and do that. All right. Here's my routes folder. And here's my todos file boom Here are all my routes for the todos route now the beautiful thing is Since I am and people ask like Leon, why do I separate this out into separate files? Well, now that I'm in the to-do's, now I'm in the to-do's router, I don't have to do what over and over again? Since I'm in the to-do's router, I don't have to do this. Pfft. Ugh.

Ugh. Mm. Ugh. Oh, misspelled it, that would have been a problem, right? I don't have to do that. Right how wet exactly I don't have to do that because I've already said I've already said I'm in the to-do's route Right i'm already in the to-do's route. So i'm already there right I'm already there. I don't have to worry about it. I don't have to worry about it Great so This was a get request All right, I'm on slash to dues. This was a get request on which route inside of to dues. Which route am I at inside of to dues? This is a tricky question. Which route am I on inside of to dues? You ready? Yeah, the route, exactly.

So I'm here, right? That's where I'm at. I'm at to dues forward slash. the root route on Todos. And what type of request was this? What type of request was this? This was a get request. Okay, this was a get request. So let's go back and take a look at our code. Do we have the appropriate router for a get request on the root route of Todos? We do, line five, exactly, right? Give me the root, get on the root route, we're already inside of todos, right? We're already inside todos, root route, right? Root route inside of todos, we're already there. And so when we hear that get request on the root route of todos, what controller are we gonna use?

Are we going to use our homes controller? No, we're going to use our to do's controller, which is a whole separate controller that just handles our to do's. And what method are we going to use on that to do's controller? Well, it's get to do. So where the heck can I find my to do's controller? Well, I got to go to my controllers folder and find the to do's controller file. so controllers folder, todos.js, and then here is my getTodos function. Here it is. And what is this doing? What is this getTodos function doing? Well, it's going to go and find all of our documents in our database. It's gonna actually count all of the documents that are still left to be done. And then it's gonna pass all those documents into our to-do's EJS file to render out the HTML. But we're missing some code here. We're missing some code here.

Let's go look at our old code actually. Let's look at our old code. GitHub, look at our old, oh, look at that handsome fellow. So, let's go to the 100 devs repo, go to our repositories. All right, where's our to-do? Was it on a different, was it in, it was not in the, in the, here we go, to-do list expresses, the very first one, all right. All right, so something interesting about the code before, right, before we had this go to the database, right, let's make this bigger. Go to the database, find the todo's collection, All right, go to the database, find the todos collection, find all the documents in the collection and turn it into an array. Right? Go to the database, find the todos collection, find all the documents. Yet, that's not here, it just says todo. What the heck is todo? Why isn't it going to the database? Why isn't it finding all the right collection? Why isn't it finding all the documents?

Oh, to do is our model. Should the code that knows how to talk to our database be here? No, we wanna separate that out into our model, right? So if we're looking at our original photo here, right? The controller knows how to talk to the views and knows how to talk to the model, but the model is the thing that actually knows what to do and talk to the database and all that fun stuff, right? So instead of having that all jumbled here inside the controller, we'll just use the controller of to-do, right? The controller of can-do, and then we'll separate all the stuff that the database needs into that to-do model, right? So we'll separate that. So instead of having it all hard-coded in here, right? We can hand that off to the model, cool. So let's walk through what happened there again, just so we can see it. we got sent to this to-dos page. So if we actually step through our code, server .js has said, all right, you went to slash to-dos, let's use the to-do routes. We looked at our to-do routes, all right? We wanted the get on the root of to-dos.

So we were at to-dos forward slash. So we're gonna use the to-dos controller. And what we're really trying to do, because when we go and look at this to-dos controller and we look at the get to do's, what we're really trying to do with get to do's is show the fricking to do's on the page, right? We're trying to show this first try, right? That's the actual to do, but to actually get that data, our data is stored in our database. So we're going to have to use the model to get that data. Right? Right? Why? It is part of it, yeah. So when we come back from our break, we will use that model to talk to the database, to get stuff from the database, right? All right, to get stuff from the database and then be able to show it and render it to our users. Cool, all right, that's a real knock. So I'm gonna take the break, seven minutes on the clock Cause we had the, uh, the bonus from before, and I will see you all very soon. We chill the music here.

We had a wonderful raffle today in the newsletter. So if you haven't opened the newsletter, what are you doing? Folks newsletter always has the coolest stuff, dopest stuff, first stuff. and we will be having a lot of surprises inside the newsletter going forward, especially to get the end of program, lots of cool things to raffle off and stuff like that. I am going to throw Twitch names into our name picker. I did the mistake the last two times of doing Discord names. So now I have to go back through and connect Discord to Twitch to send you a message on Twitch. So I will do that today. So every all nine folks that win the raffle will get a message from me today with the link to set up a coffee chat. Really looking forward to talking to some of you. So let's go to do name picker here. And then this is kind of like my trial run for for the coffee chats. And if it goes well, we'll do a lot more. It was one of my favorite things of last cohort. All right, so let's go ahead and pick three.

And this will be for a coffee chat. So let's go ahead and pick it. Three, two, one. All right, here we go. Octopus, Ridge, Ryan Hawkins, and Shelby55. Looking forward to talking to all three of you. And I think we've talked before, haven't we? I'm not sure, but if not, it'd be great to finally talk to you. Congrats to all three of y'all. Gonna put you over on my list here. You'll get a message from me later today with the link and we'll set up a coffee chat for either late this week or early next week. Cool. Alrighty, so we were at the to-do, right? We were at the to-do. And so we are using, if we look, to-do, right?

to do with simply another variable, right? It was another variable. And that variable was requiring our models. So we had to go to our models, right? We had to go to our models folder, which we have. Let me just kind of make it a little bit easier by collapsing some of this. Go to our models folder and then find the to do. We only have one model. and that to do is using something called Mongoose. So before with our MongoDB, we were using the Mongo client, right? We're interested in using the Mongo client before. Now we're using something called Mongoose. What the heck is Mongoose? I look forward to learning more about what the heck Mongoose is in your MVC lecture. Thank you.

But for now, it's gonna be the, it's kind of like the missing web development Wu-Tang member, right? ODM, ROM, whatever you wanna call it, right? It's the missing member. And so Mongoose for now is just gonna help us talk to our database, and you will discover the merry wonders as you build out your MVC lecture as well. Now, for now, let's just understand Mongoose is helping us talk to our database and is handling all this stuff that we need to actually be able to talk to our MongoDB database. And we have this wonderful thing that it's exporting, which is the actual model and the ability for us to talk to that model, that part of the database. And Mongoose is handling all the connection, the actual connection is over here with this connectDB function. The connectDB function is part of our lovely config and all that fun stuff. We'll get to that later. Don't worry about that for right now. But there's a lot of stuff going on here that just makes it work for now. Let's just understand that's how we talk to our wonderful, wonderful database. Okay. Now, Now, eventually, as we start to build out our databases, we are using MongoDB to start. And MongoDB, right?

MongoDB is a wonderful database, but it is very loose. It doesn't really matter what you try to put into it, it will accept it. So what would be one of the problems Problems of using Mongo DB going forward like what would be a problem of using Mongo DB? I like the way I like that word consistency. Consistency could be a problem, especially if we're working with other engineers. If we go back and look at our old code. Like if we look at our to do express, right? And we look at our, specifically our post, we had this lovely insert one and the structure for what we inserted was kind of like in line with the code, right? Kind of like in line with the code. Now, any developer could have came along here and changed this. And in fact, somewhere somewhere else in the code base might try putting a to do into the database with a different structure, right? And MongoDB would be totally fine with this. And we could run into some real trouble where if we're working with other engineers, we really haven't agreed upon what's going into the database, how it is structured. And so one of the really cool things that we get when we start working with Mongoose are schemas, right? And so here we have a schema, which, well, I look forward to your lecture on MVC explaining what a schema is, but for now, for now, we can think of it as kind of just like the structure, the structure of what we are using inside of our MongoDB database, right?

So when I am creating to-dos, well, there was some data that was associated with those to-dos, right? There was an actual to-do, which is like the text of the to-do. We're telling it's going going to be a string and we are telling it that it is going to also have a completed property, which is a Boolean. Now, one of the things you might have noticed about this project, somebody said, is schema like a template? Yeah, it's like a template for what goes into, right? It is like a template for what winds up going into our database. A blueprint, exactly, exactly. Cool, now we have this lovely structure, right? This lovely structure of what's now going into our DB, right? And with this lovely structure, we also have the ability to know what's going on, maybe without direct access to our database. Right now, do you all have access to my database? No. What happened different? No. So if I wanted you to work on this application, right?

If I wanted you to be able to work on this application, maybe you're a developer on a team that hasn't given you full access to the actual kind of MongoDB instance. How could you write code that interacts with the database without access to the database? If I wanted you to extend, right? I wanted you to extend this project, this application, how would you know what's actually going on? How would you know what data makes it into the database? how it's structured, what the properties would be, right? What do we, how could we do that? Yeah, we could look at our model, right? We could look at our model, and we could look at the schema that that model provides. And so if I was a new developer on this project, right? And I noticed that we were building a to-do list. I don't actually need access to the database to know exactly what's going into that database. I can go and just look at my model, right? I can go and just look at my model. And as a developer, I know, okay, well, the data is going into our database.

there's this to-do model and it is going to have a, all the documents are gonna have a to-do property and a completed property. The to-do property will be a string and the completed property will be a Boolean. So even without access, right? Even without access to the database, even without access to the MongoDB instance, I know exactly what's going into my database and all the other developers can always just take a quick look and understand What's the hex going on? So as we build out this application and it gets more and more complex We know exactly what kind of data we're dealing with should we actually need it? Cool Let's try walking through actually using all of this. So, all right, let's do second try. Submit. All right, so now we have second try. All right, second try. What type of request did I just make? Chat, what type of request did I just make? A post request. What route was that post request on? It was a post request, what was the route?

It's on the to-dos route. Let's take a look at the inspector too. If we look at the inspector, we can see that the action is to do's create to do look at the action. And there's, there's, there's other ways to like not have to hard code it in the action. This is just, I think a little easier to read and understand. So that's why I did it. But if we look at the action, it's to do's create to do. So the route is to do's. Cool. Let's look at our code. Let's look at our server JS. Is it the route that post request? Or is it the to do's route for that post request? It's to do's. All right.

Let's look at the to do routes. All right, let's look at the to-do routes. All right, where do we find the to-do routes? We have to go to the routes folder and find the to-dos file. All right, so I'll go to my routes folder, to-dos route file there. And it was a post request. So do I have the ability to handle a post request? Yes, I do right here. And let's look at the last bit of the action. We already know that we're in to-dos, right? because we just clicked through. We know we're in to-dos, but the last part of that route was create to-do because if there are multiple forms, right? If there are multiple forms of multiple different types of posts, we might have different actions, but we knew that we were on the to-dos route. We know that we're on the create to-do and it was a post. All right, our router is set up to listen for that post on the create to-do route, and it knows to use this create to, Sorry, this to-do's controller, right?

It knows to use this to-do's controller. All right, where the heck is the to-do's controller coming from? Look at the controllers folder, find the to-do's file inside of there. All right, here's our controllers folder. Here's the to-do's file. And this to-do's controller has so many different methods on it. It has the get to-do's, the create to-do, the mark complete the mark incomplete the delete to do but let's look let's look at our router the router said all right it was a post on create to do we're going to use the to do's controller and specifically the create to do method the create to do method so let's look at the to do's controller and let's look at the create to do method to do is controller. Create to do method. There we go. Cool. Now we can follow along with what we're supposed to do inside this controller. So we are going to go ahead, right? We're going to go ahead and use the to-do model which has a schema to then go ahead and create our to-do and so since we are using Mongoose we know where to go to add this to our database and since we have a schema we actually we have the ability that if this was incorrect, like let's say we tried to add something else here, like, right, would this match our schema? If we tried to just randomly add some other stuff in here? Right, this wouldn't match our schema.

So we would have the ability to reject, We'd have the ability to reject this creation of a to-do because it didn't match our schema, right? Cool. But it matches our schema, so we should be all right. We go ahead and create our to-do, and then what do we do as our response? What do we do as our response? We redirect back to to-dos, and this is really important because we didn't redirect back to the root, right? We didn't redirect back to the root. We redirected back to to-dos, like we stayed where we are, right? Because if we had just done forward slash, that would have taken us back to the main page, right? That's not what we did. We refreshed the page we were on. And so when we refresh the page that we are on, right? When we refresh the page that we are on, that is now what request? It's a get request. Beautiful.

It's a get request. All right. Now that get request is on the todo's route. So let's start at the very beginning of our server. Is it a root request, a root route or a todo's route? Ah, it's a todo's route. It's a git on the root route of to-dos. So we got to go find our to-dos routes, which we already have open. Here's our to-dos routes. It was a git request on the root route of to-dos. So we're going to use the to-dos controller, and we're going to use the git to-dos method. So here's the to-dos controller, and we're going to use the git to-dos method. And if we look at the git to-dos method, we have some wonderful stuff here. Right, so what are we gonna do? We're gonna use our model.

The model's the only thing that knows how to talk to our database, right? It's the only thing that knows how to talk to our database and we're gonna use that model to find all of our to-dos that are in our MongoDB database, right? We'll pass that into our EJS, our to-dos EJS, right? We'll pass everything that came back into that EJS We also will count how many things are still left to do Also pass that into our EJS, right? So the controller file that we're in right now is Passing off the actual to do's from our database the total number of items left into our database from our database Into our to do's EJS we go to our views file. I'm sorry views folder Vue's folder has a todo's EJS, and we're passing all of that stuff, all of that stuff into our EJS template. Our EJS spits out our HTML, and then our todo's controller with the get todo's method responds with that HTML. So when we, When we simply submitted the form, we jumped through all of those individual pieces. And it can seem like a lot at first, right? But once you have this structure, once you have this structure, the world is yours, because now you know how to set up your controllers, right? And if you wanted to add something else to this application, right? If you wanted to set, if you wanted to do to-dos, but also like a Pomodoro tracker, well, then you can just have a bunch of Pomodoro tracker controllers, right? And if you decided you didn't want to use EJS anymore, you really like handlebars, well, you just chop out EJS for handlebars. And if for some reason you wanted to update the stuff that's going into database, Well, you could just mess with the model, right? And so we're starting to see this MVC come together.

Lots of, like, humps to overcome, lots of hops to do, lots of little things to jump around in. But once you can start to see that pattern, all right, we're going from here to here to here, well, then you get so much modularity, so much flexibility to your code. And there are still pieces we have to clarify, right? there are still little things that we have to add, right? For this all to come together. We really haven't yet gone through and really kind of looked at like, even like our server file. We haven't really looked through like how we're connecting to the database, right? We haven't really looked through like how, like a lot of this, like the little things are coming together for how this really, really works underneath the hood. But this is our first pass, right? This is our first pass. This is meant for us to kind of start to see, All right, MVC, maybe I can kind of get it. We have requests that come in, the router hands those requests off to individual controllers, and those controllers are set up to do whatever we need to do. And sometimes the controller will just talk directly to the views. Sometimes the controller will talk to the model, right? And that's kind of where we're starting to be.

That's where I want you to exist. I don't care if you can't go out there right now and code a controller. I don't care if you can't go out there right now and code out the EGS that I have here. That's not where I want you to be. I want you to be able to see the hops, get some of the jumps that we are taking. Cool. All right, now, your homework. There's a lot of pieces that are missing here. What the heck is Mongoose? What the heck is a schema, right? And any of the other little bits that we're missing here, I'm putting on you right now, right? I want you to build a lecture on what MVC is, what it is, how it's helpful, and then any of the pieces here that don't make sense, I want you to research on your own, by yourself. Yes, that means by yourself, put in the time and the energy to work through it on your own. Okay. Now we're going to come back on Thursday and do more of this.

We're going to see the bits and pieces that we haven't got a chance to cover tonight. Sunday, we're going to do it again all the way from scratch, showing all the little itty bits, how things come together, right? But I need you to put in that cognitive effort to learn some of these key concepts before I introduce them to you. Right? And the reason for that is because in a few weeks, you were all leaving the wonderful confines of the 100 devs agency and you will be on a team as an entry-level engineer where you will be plopped into a new code base that code base will use lots of techniques tricks code languages things that you have not seen before, things that will not make sense to you, and I won't be here. Mine Wolf won't be there. Rest of the stream team won't be there. It's going to be you. And you're going to have to figure it out. And so I like my students to get used to that process, right? To get used to that process now, knowing that on Thursday, we're gonna review it again. Knowing that on Sunday, right? Knowing that on Sunday, we're gonna do it again in more detail, right? And so get used to that practice. Let your brain sweat a little bit.

Dig in, what the heck's a schema? What the heck is a model? What the heck are, I don't get this require, what the heck's going on there, right? spend some time going through it on your own, diving into resources that you can find and build me a lecture on MVC. I promise you if you do this, I promise, just do it. Promise you if you do this, it helps things click and it's a really good practice for being on the job. Really, really good practice for being on the job, and so I'm going to start doing some of these things at the end of class where you shouldn't really feel that comfortable because I haven't covered everything, right? And you're going to have to fill in the gaps, and this is going to be on purpose because that's what you're going to be doing on the job, right? And I would not be preparing you if you got through the hiring process because I'm going to make you a lean mean interviewing machine You're gonna be able to do data structures and algorithms with the best of them You're gonna be able to have beautiful projects in your portfolio I would be doing you a disservice if I showed you how to interview really really well Got the job and then in the first 30 days, you're just you're drowning so we start with the beginning the beginnings of feeling uncomfortable and and working through some of that uncomfortableness so that we can be doing that on the job, okay? So, we're gonna end a little early tonight. We'll probably still, let's just still do a raid just to give somebody some love and some follows. But then you should stop and take some of this time, right, take some of this time to, to take some of this time to work through your lecture on NBC. OK? Yeah. Yeah.

Yeah. Yeah. Yeah. Does this work? 21 21 21 21 21. Yeah. Yeah. Yeah. Hey, good morning. Good afternoon. Good morning, good afternoon, good evening. No matter where you're coming from, hope you all are doing well. Let's go. Hello, it's Rufio with the rain. Rufio, Rufio, Rufio, Rufio.

We're at 87, let's go. Stream team keep it going, up, up, up, up. I love to see it. What's going on? Hey, what's going on everybody? Welcome back, welcome back. Good morning, good afternoon. Hey, I just think it's a really good question. Just put in chat morning, afternoon, or evening for what it is for you. Morning, afternoon, or evening and chat for me. I'm curious. I've never actually asked this before. Evening afternoon. Morning. We've had a few mornings sprinkled in.

Shout out to all the morning folks or like the really, really late evening folks. All right, cool. Wow. I've actually never, this is pretty interesting to see. So quite, quite a few, most folks it's evening. It seems like quite a few afternooners and then a fair amount of morning folks, which is cool to see. Hey, well, I'm glad that you all are here. Welcome back. We got some more MVC to get into last class. We walked through the basics. We saw kind of the big stuff, But we didn't really hint at a few other things, mainly deleting, updating, so that we can see some of the new stuff that's there, follow some of the new pathways that are there, see things like data sets come into play. So we have a few more things to get to with MVC to set the level playing field so that we can jump into authentication. Authentication is gonna sprinkle on top of what we have here. So we got questions, I got answers, super excited to get through the stuff we didn't get through on Tuesday. Make sure folks are feeling good.

Make sure things are starting to sink in. If you have questions, I did share a Slido in the follow materials channel. So some folks have been putting questions in there. I'm going to take some time to answer those questions tonight and Sunday for office hours. So if things are still aren't clicking, please come back to office hours on Sunday. I will put more time in to make sure everything makes sense. All right. Uh, urchin said, congrats to all the new devs who got jobs. Yeah, we don't have slides this week. Next week we have like really like a lot of slides. Cause there's a lot of detail. I have to walk through lots of spicy memes for y'all. Um, so I'll put all the jobs, uh, on our Tuesday slides. So don't miss Tuesday. We have a lot of folks to celebrate.

So many folks have gotten jobs in the last week. It's kind of wild. Uh, so yeah, I try my best to capture all of them, put them into to this slide just as a quick celebration, but take a look at that celebrations channel, folks. Take a look at Twitter. Like it's been popping off recently. We're not even there yet. We're not even there yet. We're not even in the hunt yet, but where folks are cruising along. So I love to see it. I've already started my hundred hours project. So I incorporate MVC code from last class or yeah. I think really after, like if this MVC stuff feels comfortable, you'd want to start using it for your 100 hours project. Because one of the questions that always comes up, right? One of the questions that always comes up for entry level engineers is, well, tell me about how you write code, or tell me about the things you think through when writing code. And folks that are like entry-level engineers that just do like a normal boot camp, not the 100 devs academy, right?

They don't really have an answer to that question, but we have two really solid answers to that question. On the front end, we adhere to separation of concerns, the golden rule, and on the back end, we separate out our architecture using MVC. And so you want to start incorporating the MVC structure into your applications so that when architecture questions come up during your interviews, you can talk through them. It's just a really beautiful thing to have like your hundred hours project be a really well architected application. And it's not too hard once this MVC stuff sinks in. And so you'll use this going forward. And next week we add next week we add in the little bit of authentication that we need to have like user logins and stuff like that. having multiple collections in our MongoDB database. And that's what we'll really use going forward because it has everything that you need. Cool. Are we doing more crowd review during office hours? Well, we're gonna start building out bigger and bigger applications, right? And so we need to get through that point where we have authentication and then once we add authentication, we'll do like another mega stream like where we do like the full nine hours from beginning to end with a full CRUD application that follows MVC that has authentication. So we're building up, right? We've started off building CRUD apps.

Now we're building CRUD apps with MVC. Next week we'll build CRUD apps with MVC and authentication and then we'll build something from scratch together. And then our really big project that we'll do after that will be to build an Instagram clone. So there's a lot of stuff that goes into that Instagram clone that you could then, once we build that, you can build anything you want, right? Because Instagram has like image uploading, like profiles, individual pages for individual users, there's login, all that wonderful stuff, right? So, uh, that's what we're building up to. And actually one of the questions in the Slido was, uh, MVC seems to be a common pattern. Are there templates for apps with prebuilt methods to handle crud, uh, including validations and standard Mongoose schemas? Absolutely. Like there are a bunch of them out there. I actually showed the hackathon starter on stream, um, last class, but the beautiful thing is that's what we're building up to here together so that by time we get to the Instagram clone, it's not because I want you to build an Instagram clone. It's that the Instagram clone has everything you would really need to build whatever the heck is that you want to build. And we've built up together through it. So it's not completely just out of left field where all these pieces and bobs do, right? We've worked up to it.

There's tons of lectures you can go back to and see like, oh, I don't understand this piece. Leon walked through it and kind of understand it. And then that's your template going forward. There are a bunch of other ones, but the one that we built together in class could really suit you really, really well until you get to your job. Once you're on the job, they will do things in their own way, right? They will use their own systems, their own tools, their own frameworks, and you're gonna have to learn that, but for the projects we do together, that's a good template. So I don't think you need to go off the deep end to learn something else, but what we built here will be enough to get you to the job. And once you get to the job, you take over from there. Yeah. Just a quick check. Is the closed captioning working? Because I see it running on my end, but somebody mentioned that they didn't have it the other day. So make sure closed captioning is working before we continue. Yep, working awesome. Thank you so much.

As we let folks get in, we always like to do questions, but before we do that, if you haven't checked in, please check in, exclamation point, check in for the link for today. Go to that tweet, like it, retweet it, please, helps more folks find us, but also lets me know that you are here. Blah and I are meeting on Friday to finalize our process for the hunt, meaning that we're We're gonna figure out like folks that need verification, folks that need references, things like that. So we're gonna finalize that process. The mods are meeting on Sunday so that we can put that process into place. And so next week we'll start kind of talking about those things. So next week we'll probably do like an intro to the hunt type class. And of course authentication, yeah. It's hard to get a job with these bootcamp tweets. We'd show the bootcamp tweets at the end But we've had folks get hundreds of folks get jobs that have done the tweets the retweets people people don't care It just it's it's come up like once out of hundreds of places Yeah, so you'll chill it as we get closer to the hunt. But for now, let's we know you're here Yeah, people don't care honestly, that's the thing like so many entry-level engineers They get they get caught up in like all these things that half that like they think that recruiters care about is just they just don't So that's one of the things we talk about during the hunt is like what really matters what really moves the needle And remember it's a numbers game. Even if one person dismisses you for something silly. There's so many more fish in the sea. Yeah Well All right, thank you for checking in No slides today because we have a lot of code to go through next week. We bring back the slides Like I said, I got a lot of slides for you next week.

Cause we've got a lot of stuff to get into with the authentication bit. Um, I was gonna start off with some questions and I shared the slide. So I have a few questions coming in. Uh, let's start with these questions real quick and then we'll jump into class like normal. All right. Do we turn in our MVC presentations today? No, they are due on Tuesday, uh, Tuesday, right? So on Tuesday, I'll ask for your presentation that walks through what is MVC? What are models? What are views? What are controllers? I want you to put some time in on your own to build that presentation. And the reason being, because a lot of you are about to leave the wonderful halls of the 100 devs agency and walk into companies with new technologies, new stacks, new things that you haven't heard of before. And you have to gear up very, very quickly on those tools, technologies, tips, tricks. And so it's something I need you to start practicing now, getting some a little more comfortable with it.

Don't worry, we're going to cover a lot of this stuff today. We're gonna cover more of the stuff on on Sunday. We have the stream team members I've been doing some stuff to mine wolf did some MVC stuff yesterday, so I'll share that link after class and Hello, Rufio shared a link with me to that. I'm gonna share as well So there's lots of chances for you to get caught up on that material, too All right Another question we had here what's the point of having a router in addition to a controller, instead of just a controller, when all the router does is direct the request to the controller. So it's just a layer of abstraction, right? Right, just a layer of abstraction. And so the router is really listening for that request, it's really listening for that URL, and then handing it off to the appropriate controller. Now, you could put that all in one file, right? You could have listening for all the URLs, right? Listening for all the URLs, right? And it could possibly work, right? But let's say we wanted to change, right? Let's say I want to change all the routes tied to to-dos. Let's think about that for a second. I want to change all the routes tied to to-dos.

I want to change it from to do's to rainbow, right? I want to change it from to do's to rainbow. And so since I have my router file all set up nice and neat and I want to change it from to do's to rainbow in my server.js, I would just change this from to do's to rainbow and I'm done, right? Now, from todos to todas, exactly. So now all of my routes, right? All of my routes are no longer slash todos, it's now slash rainbow. And so that was one change that enabled me to fundamentally change how routing works throughout my entire application. So to me, that's way more worth it to have these routers kind of separate out because I might wanna change the pathing or I might want to change the URLs that my application is using. And this enables me to do that very, very quickly. What's a real world scenario that you want to change routes like that? Well, when you're working on a team, let's think let's say you're working in a really big company. Let's think of like Wayfair that sells dozens and dozens of different kind of furniture and stuff like that. And maybe their routes get broken down into tables, chairs. I don't know, let's say tables and chairs, right? But now they said, you know what?

We have tables and chairs, but we also want like side tables. So side tables is like a new route. Whereas before everything was tables, now there's also side tables, right? And so if there wasn't an easy way to make those changes, you would be going through lots of lines of code to fix all these routes, right? Now, the other thing too is that, Yes, we made the switch from Rainbow to Todos, but the other wonderful thing is I don't have to worry about somebody like really breaking my routes, right? If all my routes were in this singular file, like if all this stuff from my Todos was in here and all this stuff from my home was in my server.js and somebody starts making changes, is we have to think about the maintainability of our codebase over a long period of time, right? If my route stopped working, I know where to go and look to see if things are working or not working, right? I can see, all right, did somebody mess with my todos and my root route? If there's nothing wrong here, then I know, all right, if my todos still aren't working, Then I can just go straight to the to do's routes file and look here and figure out what's going on But if I have everything in just one singular file The chances of someone messing up my routes is very very easy Or if somebody decides to change one thing to another like it's just having that just extra layer of separation Just makes the code base a little bit more maintainable Over the long haul and so that's why I do it And I like it so that I can quickly change my routes on a whim. I know that folks, if they're in the, if they're in like say the to-do routes file, they know that they're messing with the to-do routes, right? Like if you're in the to-do routes file, you know that you're messing with the to-do routes. If you're just in the server.js and everything's there and you're making changes, you might not know that you're messing up the routes for the entire rest of the application. So a little bit more, a little bit more abstraction, which helps us not lose sleep at night when changes are made. That's kind of the purpose there. Cool.

Is it better to name each file to do JS or is it better to be descriptive and call them route to dos, view to dos, controller to dos? is that's actually a really good suggestion, right? That's really a good suggestion. You could have your file names be a little bit more descriptive so that you know when you're looking at the file where the file also exists, right? So we're looking at right now the todos router, right? If you're looking at the todos router, you could call this todos router. I personally just always look at the folder names anyway. So I don't do that because I think it adds a little bit more complexity to a file, a naming convention that everyone would have to follow, right? And so just a lot of the teams I've worked on, we haven't used that naming convention. Typically we look at folders and then files and that's okay. That's up to you though. You might join a team that has a different naming convention and that's okay, right? And you might come up with a naming convention that helps you build out your 100 hours project. Whatever it is, document it and stick to it. What am I sipping on?

I'm doing just instant iced coffee. What's the drip today? This is my GNU shirt, yeah, GNU Linux. Yeah, as long as you're consistent, exactly. You can make up any of the naming conventions that you want, it's just about being consistent. And what works for you, yeah. Cool. How do I check if something exists in the database before executing and creating a new object? We're not 100% there yet. When we get to our full stack apps that we're building together with Instagram, I'll show you how we don't have repeat stuff. We're going to see a small sliver of kind of the beginnings of that tonight because is we're gonna be using IDs and data sets and all that fun stuff. So we're gonna kind of hint at it a little bit tonight and then we'll see it in full action once we get to our authentication. I don't like to jump all the way right to it because it's just not something that we need to optimize for right now. So that's one of the things that we'll build up to but I don't like to show it right now just because I think it gets folks too confused and just not something to worry about for right now. We'll get there.

I'll tease a little bit tonight and then we'll get there over the next couple of days. I'm just gonna kind of wrap up a few more of these questions and we're gonna start looking at the code. The MVC video shows that the views report back to the client directly instead of the view sending info to the controller and then the client, does this matter? So it kind of depends on what you're doing. It depends on how your MVC is set up, right? It can depend on the tools and technologies that you're using, the frameworks that you're using, and the libraries that you're using, kind of like how this process happens. It's also a little bit more muddled than a nice clean graphic could present, right? So if we look at, let's say, our to-dos controller, we can see in our get to-dos, yes, we are using our to-do model, which we'll talk through again today. and we are asking it to render, right? So we are asking EGS to render, and then once it renders that file, we are responding. So the handing off to the view is kind of intertwined right now in the controller. And so the actual like passing back and forth, it depends on what you're doing. Right now, the controller is asking EJS to render and then responding with whatever was rendered. So how true or not that is depends on the libraries that you're using and how you've written out your code to kind of abstract out these different concerns. All right, so I think we got some of the pretty kind of standard questions so far.

If you have more questions that come up, of course, you can always use chat. And then the other thing you can do is just keep putting in the Slido. The questions that get upvoted. I'll answer at the end of class and then we'll also review some on Sunday as well All right, just so I can kind of get a pulse check our folks feeling with MVC so far How is I know there's a lot of like hopping jumping skipping? But how are folks kind of feeling with the the MVC got some arms got some goods got some great decents good 50-50 scared, feeling great. All right, it seems like folks are in a good spot. A little confused when I get to broad concept because that's where we should probably be. Not bad. Okay. Cool. Let's take a look a little bit deeper tonight at some of the things that we started introducing on Tuesday. We'll keep asking questions, keep putting questions in the Slido. I will keep working through it so that folks can get that a clearer picture and then like I said on Sunday We'll have more time to go from the beginning for folks, especially that missed Tuesday's class Couldn't code it myself yet, but broadly understand the concepts that's exactly where we should be little secret right now You shouldn't be able to code any of this from scratch. Like if you did, like if you could, you're like a savant, right? Like if you could code all this from scratch, like no one does that.

No one would legitimately build all of this from scratch if they're building a full like CRUD application, right? I might be able to do it. I'm sure I would miss a few things, but that would like not be a good use of my time. Why would I code all this from scratch when I've already put together a beautiful template that has all this stuff, right? Like all this stuff already coded out for me, right? I could copy and paste that and start with everything in the right place, knowing that everything is connected, it, knowing that everything is, is just ready to run. It's got to do an NPM install, uh, put in my Mongo URL, my ENV file, and then run it, right? So why would I, why would I ever do this from scratch? It just doesn't make sense. Right. Uh, and so I think, I think that's something that a lot of people kind of go into this type of lecture with where they're like, Leon, I get the broad concepts, but I couldn't do it from scratch. That's okay. No one does it from scratch. Right. No one would take the time to do all of this as long as you understand all the Legos and how to put them together You are in the right place Now as our application gets bigger we're gonna have even more Right, we're gonna have even more Like templated code, right and have even more things that would just make zero sense like zero cents to have memorized.

All right, let's take a look at it real quick. Just to hammer home this point real quick. There we go. So it makes it a little bit bigger. This is the auth that I linked for you to take a peek. Let's look at our passport.js file here. You're not memorizing this, you're just not. Why? You're just not, right? The best engineers don't write this from scratch. They know where to get the code that they need. They use libraries and tools to assist them, right? If you were saying travesty, copy and paste it from documentation exactly? Because we're all kind of building on top of the shoulders of giants, right? Somebody's put a lot of time into making sure that Passport works, right?

So I can just yoink it and put it into my code, right? Right, and so I think you gotta let that, chill, take a deep breath, let it out. You don't have to have this memorized. You're just kind of piecing things together, right? There will be times where you have to write a lot of code But a lot of this like glue and like building the project is not where you put in that time Yeah cool Are you gonna press them you already have the templates all the starter code that I share are your templates and like I said We're going to keep adding more and more pieces onto these templates. And, uh, the templates are already on our, our a hundred devs GitHub. So you can always just go grab what you need and they'll stay up forever. So if you're, if you're, let's say you, you leave the hallowed halls of a hundred devs, you go off to join a team that uses PHP and then in two years, you're back to node, right? Well, come back and grab the templates. Hopefully they're updated a little bit, but that's it. School's hammering plagiarism is bad into my brain really makes this copy and paste concept challenging. Well, here's the wonderful thing, so here's the wonderful thing, right? It's not plagiarism because there are licenses on the code that we use, right? So most of my code is either GPLV3 or MIT and all the code that I use is the same, either or MIT or GPL v3. And that means you can use it for whatever purpose you want to use it for, right?

And so one of the things I love about this code I have here is my database JS, like how we connect to the database, right? And if you're looking at this, you're like, hmm, that looks familiar because this is Brad's connecting to the database, right? This is the one we saw in the video, but this code is MIT license. And so I was like, that's really elegant. It's really easy to understand. People can see it and knows what it does. I wish I could use it. And then boom, license as MIT, right? And so a lot of the code that we're using is giving you permission to use it, which is beautiful. And it's one of the most wonderful things about coding. Yeah, people like MIT, it's just the name of the license. The MIT license is a license that kind of just lets you do whatever the heck you want with the code. There are plenty of other licenses outside of that. MIT is in the school. Yep, exactly.

MIT is the school. But the beautiful thing is you can always typically check the license on code and do it. So all of my code that we generate 100 devs will be MIT licensed or GPLV3. So you can use it and do whatever the heck you want with it. I don't care. I'm working on licensing all of my other content. So all the videos, all the homeworks, all that stuff to be a free use license as well. So pretty much everything we generate 100 devs, you could take it, build a whole nother bootcamp with it, I don't care, right? Like, as long as it's helping people, that's what we want it to do, right? So I just gotta, I've been talking to somebody just to figure out like what the best use, like best license for like non-code content is, so that we could figure out how to do that, yeah. Hey, blah. Cool. Alrighty, so tonight we are going to look through a little bit more of this code, see the things that we're going to need to better understand what's happening. We're going to review the MVC structure and then the two big things like I said are kind of seeing the deleting because we have something interesting. We have in our application the ability to do something like this.

Right, so now I have three to dos. I have a first try, a second try, and a first try. And I can delete that specific first try. Like if I go back again and I do first try again, I can go ahead and delete like that specific first try. So we can see that the first try that was above got delete the first try that below got deleted, right? So we haven't seen that before right? We haven't seen this ability to Delete specific elements exactly when they're the exact same text, right? So like I said, we're building up to being able to have a little bit more like realistic code And so we're gonna see that tonight. Like how does that work? How are we able to delete stuff that's exactly the same and know which one we're deleting? And we're going to see the updating and a little bit more of the EGS too that's going on here. So I want to kind of walk through the pieces of the application and then dive deeper into the code. So that's where we're gonna start. If you need the code, everything of course is always linked in our Discord in the follow along materials channel. If you're watching this on YouTube or somewhere else, please come to Discord.

That's what makes this program work. Come get the help that you need. Come help others learn. We are community taught. So all the code you need is on Discord. Come grab it, come hang out, come answer questions, help get help that you might need. Alrighty. So here is our server.js file. And on Tuesday, I didn't really walk through it, but there's some things I just kind of want to bring back to mine just so that we understand what's happening. If you've cloned down my code, you're gonna have to do two major things. One, you're gonna have to do the npm install, right? npm install, sorry, yeah. npm install will give you the lovely node packages or the npm packages that you need to make this work. And you need to, in your env file, right? in your EMV file, put your Mongo string.

So when you use Mongo Atlas and you create a new cluster, it'll give you a connection string. All you do is click connect, and it'll give you that connection string. You throw it in here with the appropriate username password and make sure your IP address, right? Make sure your IP address is accessible. If you wanna open it to everyone, you wanna whitelist all the IP addresses. So if you've just cloned down my code, why wouldn't you be able to add new to-dos to my application? You have all the code, why aren't we having a bunch of griefers put new stuff here? Exactly, only my IP address is whitelisted at the moment, meaning unless you have the same IP as me, you can actually wind up making changes to this application. Cool. Alrighty, so you've cloned down the code, you've put in your connection string from MongoDB, right? Now you should be able, and you've done your npm install, now the application should work. I do npm, let's go ahead and clear this real quick, npm start to start my server. and we're gonna notice something slightly different about the way the server is running now. Slightly different than we've seen in the past. And I gotta, lean back, lean back, just off your shoulder and lean back.

I remember, remember, think about this too, hold on, hold on, hold on. If you're like in your late 20s, early 30s or older, we had it real easy because in the club, this is all we had to do. This was it. This is what we were doing in the club. That was it. You see it one more time for the new folks. Boom. That was it. That's all we had to do. Have you seen these Tik Tokers? Have you seen these Tik Tokers? Nah. I'm glad I'm married. I already have my kid, I don't even know what I'm doing. Something's a little different here though.

Something's a little different here, right? Something's a little different here. What are we using here that we haven't used really in the past? Some of you might have used it. NodeMon. So NodeMon is running, and what NodeMon will do is it'll restart my server when I make changes. So instead of having to like start, stop, or make my change, start, restart my server each time, NodeMon is listening for those changes in my files. And when I make changes in those files, it automatically restarts my server for me. If you look at my package.json, I have my scripts section. and this is where that npm start comes from, right? I can do npm start, right? I can do npm start and it's going to do the command to do node-mon-server.js, right? So it could be, we could have made npm start do node-server.js and that would have started our server like normal, but I've set mine up to do node-mon-server.js. Now I don't introduce node-mon right away because I've been in interviews where folks have painfully not known how to start and stop their server. So I always make sure folks know how to start and stop their server with node and then the file and then we introduce nodemon.

But please if you get used to nodemon don't forget that you do on occasion especially in interviews if you're using like their box like their code or whatever they might not have and you might have to remember to start and stop your server. So just remember that. Eventually, we'll also have like development versions of our code and production versions of our code, meaning that we might have some stuff running during our development process, testing, linters, hinters, all that stuff that might not be running in production. And so we might have like npm start dev or npm start prod. So we'll start to see more and more kind of like these little scripts that help kind of our server start and run. Someone got really excited about scripts. All right, so we saw that, and that's how our server is running. And I want to start off with our server.js file just to kind of briefly go through everything. We've covered a lot of this in the past, but let's see it all. We are using Express. This is still an Express application. It's still our wonderful CRUD apps that we know and love. And we are using Express to help us build out our API. We're using Express for all the wonderful things that we've learned that helps us. So we don't have to write raw HTTP methods.

We don't have to write raw FS modules, all that fun stuff. Express is doing all the heavy lifting for us to help build out our API. Cool. Next we have our ConnectDB. and connectDB in this case is a variable that's going to be holding something. Whenever we see this require, we're going to a different file to get something. Sometimes we'll go to a different file and we'll get a function. Sometimes we'll go to a different file and we'll get an object. Sometimes we'll go to a different file and we'll get a link to another file, right? Like that weirdly can happen, right? In this case, I'm going to my config folder and then to my database file. So let's take a look at that. Here is my config folder and then my database file. And so in this database file, you can see that we export ConnectDB and ConnectDB is just a function. It is a function that enables me to connect to my database using Mongoose, right?

So Mongoose, if you start to build out your presentation, is a little bit different than MongoDB. We get a lot of little extras that are gonna help us talk to our database via our models. We get a slightly different syntax for certain things that we're gonna see tonight. Create instead of insert one, little differences here and there, but it can really help us to build out our application a little bit more, a little bit easier. And so you can see in this file, what is getting exported is this function right here. And this function is what connects us to our database. Now, there's something really interesting about this. If this file spits out a function, if we want this file to do its job, what has to happen? What has to happen? Yeah, we have to call it. A function don't do nothing. It's happy to sit on the block all day long, no action. Right? If we want our function to do something, we have to call it. So we can see that this is a function that connects to our database.

We see that we spit out that function, but when we go back to our server.js, you can see that here is where we actually call it, right? Those parentheses are letting us know that we are calling that connect DB function. That function came from being spit out of this file. So it's not enough to just require that function. We actually had to run it or else we never would have connected to our DB, right? And we talked earlier that this lovely connection, this database file is something you should be familiar with. It was from the videos. This is Brad Traversy's connection. I love this one. It's very clear, very easy to see. And would you know how to code this from scratch? You might be able to do it after a few times, but you don't have to. You could just include this file, right? You can include this file in your projects going forward. It is MIT licensed, right?

And you don't have to think You just know that this is going to connect to your database. No problem. Now, there are a few other things in here that are really helpful. Just as a reminder, you can see that we're trying to connect to our database, but the connection to our database isn't here. We have this process.envdb underscore string. Huh? What's that mean? Yeah, it's an environment variable. We have to go to our ENV file, right, to find this DB string. And if we look at our ENV file, our environment variables are listed here. I have an environment variable for my port and I have an environment variable for the connection to my database. Now, how, how does my application know know how to use these, right? One of the weirdest things about Node to me is that this is not built in, this is not built in. Like Node by default doesn't like recognize this stuff. And so if we go back and we look at our server.js, we had to say, hey, server, listen for these environment variables, know how to use this env file, right?

know how to go find it. Hey, it's in our config folder, and then there's an env file. If we don't have the string, any of the environment files, right? Any of the environment files that we're trying to use just won't run. And so a lot of folks have been asking me recently about other, other ways of running our code, right? Remember, node is the environment in which we're running our code, but there are competitors. There's Dino there is bun and all these kind of up-and-comers that want to take away market share from node And they're adding a lot of quality of life improvements Meaning that in say bun Env files just work. You don't need a third-party package, right? So that's something that's pretty cool That some of these newer where environments give you access to without needing something extra, right? And so I think that's something really cool. Like, this is one of those things where, like if you're in an interview and somebody asks you, is like, what do you think about Node? Maybe like, well, I love Node. It's helped me build wonderful applications, but I love some of these up and comers that have these quality of life improvements, right? Like having ENV files built in. So, so much of interviewing is being able to like, talk that talk and that's one of these talking points that helps you sound, you know, you got in the bag, you know what I'm saying?

But keep that one in your back pocket, add it to your, your Anki deck, uh, and we'll be, we good. Cool. So our, our server dress file has connected to our ENV files. We've connected to our database. Uh, we're, we're pretty much off to the races We're in a good spot. Why the heck am I using an ENV file anyway? Just as a quick question. Yeah, it's my secrets, exactly. It's the stuff that when I push this code to GitHub, I don't want folks to see. I unfortunately have to share all my secrets with you so that you have an application that works because writing readme files is just not something I think to do in the moment. So thank you for all the PRs that have come in through with how to do it, but for me, I pushed this ENV file so you could see it, but I limited the IP addresses on my Mongo end, right? But for y'all, there's gonna be a lot of secrets that you don't wanna push up to the internet, especially as our applications get more and more complex. By the end of program, we're going to have things like our Mongo connection, our Cloudinary, like where we store our images, some of our Heroku stuff where we're hosting our applications. We're going to have so many Google analytics stuff. We're going to have some fancy search stuff, some Contentful stuff.

Like we're gonna have so many different things that are like keys that we just wanna push up to the interwebs, right? Cause somebody would just take them and be able to do whatever the heck they want it with our services. So we put everything into the env file and then we make sure that our env file is in our gitignore. So you would do .env and boom. Somebody said, what about logs? That's actually really important to keep in mind. And if you have ever committed changes that included like your ENV file before you add it to your gitignore, so you can't like, you can't have like pushed your keys to GitHub and then realize it and then like delete the file, add it to your, or like add it to your gitignore and then repush. It's still like in your git history, like your commit history on GitHub. So just be careful about that. I know a few people that have gotten got by doing that. So that is something worthwhile to bring up. Cool. All right. So we know we're using Express. We feel comfortable with that.

We've connected to our database. We feel comfortable with that. We're letting Node know that we want to use our environment variables so we can use them throughout our application now. And the other two things we saw on Tuesday is that we have linked to our routes. So we're going to listen for the requests come through and then hand the request off to the routes and the routes will know which controller to use based on not only the route but also the what very very oddly phrased question but the routes going to know which controller to use based off of the route and one other thing yeah the method exactly The route's gonna be paying attention to not only, sorry, the route is gonna be paying attention not only to the route, but was it a get, a post, a put, a delete? And based off of the matching route and the method, it'll know which controller to use. Beautiful. All right. Next we're saying, hey, we're using our specific view engine which is EJS, it's in the game, right? Without this line, we wouldn't know what views to use, like how we're gonna handle our views. and so you could swap out EJS to something else, but for now we'll be using it. Eventually our views will be handled by React. Cool. We also set up our public folder. So this application has a lot of stuff going on.

If we look at our application, what type of files do we already know? Just by looking at this, what type of files are going to be in our public folder? Remember, the public folder, right? The public folder hosts all of our static files. So we don't have to write individual routes and then like individual controllers for them, which would be a pain in the butt. Yeah, if we're looking at this right now, we know that in our public folder is gonna be our CSS because we can see that there's red color. And if we're like clicking on stuff, the only thing that can hear that clicking is our client side JavaScript. So in our public folder will definitely be some CSS and probably some JavaScripts because we can like click on stuff and there's yeah, so if we look at our public folder Public we can see that there's a CSS folder with our style dot CSS and there's a JavaScript folder with our main J s right so that's within our public folder. Then we have these two lines right here and these two lines is replace something called body parser and body parser is in the name, meaning that we can parse stuff that comes out of the body. So remember, whenever we're making a request to the server, there's a lot of information that comes along with the request and we're able to yoink the stuff out of those requests so that we can use them now in our controllers to then go make requests or hand them off to the views. But we have a lot of times that we need to pull data out of the request. What was in the form when the form was submitted? it, um, what exactly was clicked on when you clicked on the delete? Like what, what item are you trying to delete all that stuff we're pulling out of the body and these two lines help us do it cool. Uh, then we're telling our application to, uh, use these specific routes.

And so this is something that's built into express routing is now handled by express. And so if we're using the default route, we'll use these home routes. And if we're using a to dues route, we'll use this to do routes file. So just kind of separating out our different routers just to make our lives a little bit easier a little bit more flexibility and a little bit more maintainability because somebody is probably not going to mess up this bit of code and if they do I know exactly where to go look and then the last little bit here is this app dot listen and we are using our environment variable for the port. Why am I using the environment variable for the port? Like what is that setting me up to do? Yeah, deployment, exactly. Eventually this application is going to be hosted. We'll use Heroku to host it in the near future. And that Heroku is probably going to set their own port for their own servers. And so it's nice to not have a port hardcoded, because that might not be the port that Heroku wants to use or whatever hosting provider you are using. So we'll be using Heroku in the beginning. We will see some other hosting providers as well. Heroku is just easy to get up and running with from the beginning. Is Heroku used in a professional setting?

Is it more for small projects? It's definitely used in professional settings, especially for a lot of like startups or like kind of simpler product companies. It's just really quick. You wind up paying more money though. So a lot of startups will use Heroku just to get up and running, get their MVPs out. And then once it's like set up, then they might switch to something else that gives them a little bit more flexibility in terms of like everything, including price. That's not true for every company. So a lot of people stay on Heroku just cause it's easier. It's also really popular in certain development communities. So Heroku became really popular in the Ruby on Rails community. And then you'll see like some other hosting providers are more popular in other communities. It just depends on the languages and who's kind of like building around those tools and systems. Cool. All right. Cool, alright folks, let's go ahead and take our break.

If you are new around these parts, we like to be healthy. We like to, if you're able, get up, move around, hydrate, take care of yourself during these five minutes. When we come back from the five minutes, we are going to look into some of the bits and bobs that we didn't get to last time. I wanted to walk through all the stuff that was here in the actual structure of our code. We're gonna review MVC quickly and they're gonna look at that deleting and we're gonna look at the updating just to walk through it together as well We had two minutes added to the timer rat cane. Thank you for the extra two minutes This will be a seven minute break folks who look sure yes If you haven't yet already, please go ahead and check in exclamation point check in We'll give you the link for today. And if you're on YouTube, go ahead and give it a like and a comment Just help the algorithm to boost us on the YouTubes. Alrighty. 10 minutes on the clock. Enjoy the tunes. I'll see you soon. Alrighty, folks. Come on back. Come on back. All right.

So we walked through the server.js file. There's a lot of other little things that are in here just quickly to kind of touch on them before jumping back into it. There was a newsletter raffle. So we'll get to that after the next break. The folks that won the past three newsletter raffles, you've all gotten a message from me here on Twitch. So check your Twitch messages, grab a time, looking forward to chatting with y'all. All right. So we had some other wonderful things in here. My VS Code, this is just like my settings for VS Code. I have things like larger so that you can see them on stream, right? Larger, because I want you to see them on stream. You can add this to your Gitignore. Like I should put that in my Gitignore so you don't have my settings. But if you're like, why is the text so big? That's what it was for.

The config right now is holding our database connection and our environment variables, right? But starting next week, it's also going to hold like some of our stuff for authentication as well. Controllers for our controllers, models for our models. Node modules comes when you do your NPM install, but it won't be there when you clone it down, of course. Public for our static files. Some folks are saying, could you put HTML in here? You could, but we're not using, we're not like serving up any static files. That way we're using EGS to kind of do all of our HTML. But could you do it? Yeah, of course. Routes for our routes, views for our views. Git ignore, so we don't push stuff up to GitHub or elsewhere we might push our code. And then we have our package.json, which has all the packages we're using for this application and the lock that comes through using it. And so you can see in our dependencies, we're using our .env for our environment variables, EJS for our templating, Express to build out our API, MongoDB and Mongoose to talk and connect to our database, and then NodeMod so we can restart our server without having to stop and restart. And then the server.js file, which you already saw, and our proc file.

Where does the proc file come from? What do we need that for? Nice. Yeah. If we push the Heroku, that's what we're going to use that for. True, get us all the experimental features. I want them. Love it. All right. So any questions about folders or folder structure or kind of the little things that are happening here? Before we look into the MVC a little bit more. Make sense to me, okay? Yes, tons. Let's go away. Premium, yes.

EJS is our templating language. It's how we plug different stuff into a template to spit out HTML. If you're new, we've been building up to this for a while. So we started with raw node, then we added a little bit of express. We built up, we built up, we built up. So this is like the sixth or seventh class in a longer series building CRUD apps. So if this is like brand new to you, you probably wanna go back and watch our previous videos on YouTube, exclamation point YouTube to get access to those. Will this be the standard structure? For the rest of the program, we're gonna use a structure similar to this. There are gonna be things that we add to it. Some ways of doing things slightly different, but for the most part, it'll be this structure. Why start with EJS and not React from the start? Because a lot of folks won't use React professionally, and it just adds a whole layer of complexity that most folks don't need to start. When folks are learning how to code, especially for folks that are new, learn how to make stuff work first so that you can build. And then once you're building, think about it and say, oh, it'd be really nice if I could or it'd be really nice if I didn't have to worry about that.

And that's where the React can come in. But when I've started with React, because I've tried it, I've been teaching for 10 years, I've tried starting with React, my students always got lost and they just gave up. So I don't start with React. I want something simpler that gets you just injecting stuff into your HTML, using it like a template. And then once we learn the limitations of that, then you can add something extra on top. But jumping straight to it, it just doesn't, I just haven't seen it be really useful as a learning mechanism. I'd rather you have a strong base, exactly, blah. Yeah. The traversy video uses handlebars, is that used professionally? Yeah. It's kind of like what you, a lot of this is like preference, right? You can argue for why one is better than the other, but a lot of them comes down to your personal preference. I use EJS because it's only two things that you have to learn. You have to learn that you can have stuff in code blocks and you can have stuff that you're inserting variables. Once you learn that, you can template whatever the heck you want.

So I find EJS to be more simple to start folks off as opposed to something that has its really own syntax. It's completely, not completely, if it looks different than HTML, just a little bit more of a shock. Now, pug might be a little bit easier in the long run, but that initial understanding, I want people to see the connections between everything. And so with EJS, it's easier to see those connections. Are any not used professionally? You know, like any of these big ones probably has a community of folks that use it, right? And so, like I said, the other big thing is that this isn't like a learning to code bootcamp. This is a getting a job program and you are all going to leave to go to different companies that all use wildly different stuff. It's not worth it over investing in one narrow piece without having a larger understanding of the broader landscape. So I'm here to give you the broader landscape and then you can get narrow in on the job. Yeah Joke's on you. I also learned how to code That's the goal right coding is the mechanism for getting the job, right? Cool. I'm gonna take a quick peek at some of these. Uh slido questions real quick Uh, the mvc lecture submission, is that a powerpoint or a video?

Oh, whatever the heck you want Um, probably most folks are doing like a, a Google slides or a PowerPoint or a slides.com type thing, your favorite Marvel versus camp come to character. I'm a big, and I know this is controversial. Spider-man captain, American combo web into final justice. Like, like that's, that's the, uh, that's the combo of combos. Uh, if we have interviews to focus on, is it okay to fall behind on homework? Tricky question. Tricky, tricky. I always want you to prioritize your interviews, but we're really not at the interview stage yet. For the support that we're going to give post program, I need to have seen that you've done the work. I can't in good faith get on a call with someone and say, yeah, they're great when you haven't done the homework and you haven't been here in class, right? Like that's not something I'm going to do. And so I need you to have done the things that we've asked you to do so that I can in good faith be like, yeah, this person's awesome. Here are the things that they've built. They were always here. Like that's what I need you to be doing, yeah.

So always prioritize like the interview and getting the job but know that we're not at that phase at program. So I'm still expecting you to like do the work. If I fell behind, can I submit the old work with MVC? Sure, if you want, that's okay. Are we going to do a back-end mega review? We will. Yep, we will after we get through authentication. Looking for more along MVC questions though. If we want an app to be built to be able to access a DB, do we make that DB public or are there ways to approve the app? So eventually the only thing that will have access to your database is wherever you're hosting your application. So like Heroku would have access to your Mongo Atlas, right? And nothing else. So the only way that you could add stuff would be through the actual site, through the actual, like the application itself. So we'll get to that, yeah. Why is client-side JS and CSS not in the views folder?

Because the JS and the CSS has like, it's not part of our, it's not part of the view that is being rendered. Like we're using our views to like generate something. And the thing that our views are generating is the HTML. So we have the way we set it up now that we can continue to have our static files like CSS and JavaScript be in public. That means we don't have routes for them. Other view type engines might have the CSS and JavaScript incorporated. Right now we've kept it separate just to have a little bit more separation of the concerns there, but know that you could be using a certain thing for your views that has everything together. The way we're doing it right now, we just don't, but you could. Good question. Is there another way to do it besides MVC? Oh yeah, boy is there. There are tons of other ways to architect your applications. We'll actually see some of them, like if you've already dipped your toes into react, um, or any of the other like front end frameworks or libraries, or even like Angular, there's like MVC and VVC, there's like a bunch of them that are kind of riffs on it, but there are also other completely different paradigms, uh, MVC is pretty popular. It's pretty easy, I think, to wrap your brain around. Um, especially for the type of applications that we're building.

That's why we start there. Yeah. But there are plenty of other things to do it all the ways to do it. Yeah. Can you, so there's, I'm looking at if there's any other, um, So there's some folks are saying like, are there other folder structures for like what we have? There will be like, like I said, like what do you join a team? They're gonna have a way of doing it, right? They're gonna have a way of organizing their code. They're gonna have different folder structures. And so, like I said, it's not, it's not worth it to really over invest in one area, but know that when you join your company, They might have a library folder or some other ways of slate organizing it. I think this is pretty clear that there are, um, different, like we can see that there's controllers, there's models, there's views. And so if you know, MVC, um, you know what you're doing, you know? Yeah. And blah said a good team will, a good team will give you time to find your way around a repo. Exactly.

A good team, like the first month is just like getting comfortable with the code base. Sometimes even like the first three months, if you're on like a really big, like a really meaty type of team that has a lot of like pulling from different areas of the code base and a really good team gets you set up making like really small incremental changes until you feel comfortable throughout the entire code base. Yeah. It's actually one of the questions I recommend folks ask once they have an offer. Once they have an offer, that's one of the things you might ask is like, what does onboarding look like? what does the developer experience look like in the first three months? How quickly will I be able to push code to production? These are all questions that we wanna bring up to have a better understanding of like, are you just thrown into the deep end or they actually support you through the first couple months? Cool. There's one other question I saw here. So I'm only doing MVC type questions right now. Can you explain module.exports? So instead of having our code in one giant file, we wanna be able to separate our code out into individual files, just so they can be in charge of doing one thing. Well, for an individual file to do something, but be used somewhere else, we have to like spit it out so that it can be used somewhere else, right? So we saw that with our database JS.

This database JS is really just a function and module.exports spits out that function. And then when we're in our server JS, we can require that file or that function that's been spit out. So the module.exports is just spitting something out that we can use somewhere else, that's it. Does this organization of folders slow the speed? Oh, this does on Tuesday, not really, because we're talking about like speed of light through all this stuff. If you did have way, way more complex structure, it could, it could slow things down. But at this level, not really. You have to do a lot for this to be like the, the slowing down of your application. So I had a good question. If devs are changing jobs every two years and onboarding is three months. They are onboarding 1a for the time. Yes Well, I didn't I'm not gonna check your 1 8th math But yes, that's kind of one of the rough things about hiring developers and why this process is so wild, right? don't tell people the reason the becoming a developer at a company process is so wild is because One, it takes most companies. I wonder if folks remember this, if we have some OGs in the house. How much do you think it costs to get an engineer that you're ready to hire through the door?

Like all the recruiting, all the interviewing, like through the door, how much does it cost? It's about 30,000. Yeah, exactly. Around 30,000 to like get them in the door. And it's different at different companies, right? Some companies pay way less, some of the companies probably pay more, but you're talking about like 30K, like all is said and done, including the things maybe they're spending on advertising, job posting, recruiter, time for employees to interview. So like you're 30K in the hole and the person hasn't even started yet. Let's say they're making 100K a year, right? We'll just use that for a better math, right? And it takes them three months to really ramp up, right? So that means before you ever realize if an engineer is going to be effective on your team You're already 60k in the hole plus benefits plus laptop plus all the other stuff that you have to do, right? So like Imagine being 60k in the hole and then you realize they can't code So that's why there's so many weird things that happen during the interview process Where they want you to leak code your brains out or they want you to do these different types of stuff? or they need to talk to so many different people because it can be a serious cost for a lot of companies. So that's just something to keep in mind. Yeah.

Now a lot of companies realize, you know what, if we're just good at the on ramping, right, then it doesn't matter, right? Some companies actually invest in training their, their engineers and the systems that they want them to be trained in. And so a lot of companies might have a less rigorous interview process, and that That could be a sign that they might have a better onboarding process right where they just get engineers up to speed so they don't they lose less people and they can be less weird during their interview process. So there's a lot of different things that can happen there and it's a very hard thing. That's why the actual hiring process can be all over the place for different companies. Which companies are those? So I always have these different ideas, right? And one of the ideas is like I've interacted with hundreds of companies just through my students having interviewed there. I know what companies are good companies to like interview at. I know which companies are good companies to like to work at and it's It's always been something I wanted to like publish. Um, and my ed at resilient coders actually has this idea of like an equitable employment council. Um, I have a list. I keep the list. I've, I've made this public. I have a list, um, where companies like agree to like do things equitably and then they get put on the list and like that would make it.

So they had more candidates that were applying. So blah, let's add that to our talk on Friday. I would love to have like folks that graduate 100 devs having access to that type of system, yeah. And then the other fun thing is like, I want people to be paid, like, I want people to like, I want people to learn for free, but that's not equitable. Cause not everybody has the time or privilege to do this without getting paid. So I want people to get paid to learn and so one of the things that we had talked about before Which is like when you graduate you get an NFT, right? and so that NFT could be your ticket to access the list and So you could access the list until you get a job and then maybe you sell that NFT that you got for free and then somebody could buy the NFT to get access to the list, right? So now not only did you get access to the list like get your job But then you resold it and you got paid for all the work that you did to graduate 100 devs So if you're excited by these ideas, I have too much stuff on my plate Me and blah are talking a lot about this on Friday. But next week we're gonna talk about a hundred maintainers, right? So we have all these little projects that I think could make it really great 400 days We have lots of senior engineers that want to work with you all to build these ideas And so if that's something you're excited like hey, I would love to be on a project team that did that to help everyone Let's make it happen. So next week I want to share, if you want to join some of those project teams and start building these things that can make the community better, show up next week and we'll talk about it. Cool, all right. So we answered some questions. We've talked through the entire code base. We've seen all the bits and bobs.

So let's talk about some of the things that, let's talk through some of the things that we didn't get to talk to on Tuesday, which was this like deleting thing that's happening. And let me delete first try here. Let me delete second try here. Let me add some stuff here. First try, cool. So we got our first try. Let's do our second try. And let's do our third try. And then we're gonna do another first try. Nemo, yep, it's cohort two you wanna be following on YouTube and then join discord and join the catch up crew. And let's add another first try here. Thank you, Skint, appreciate that. All right, so now we have the first try, second try, third try, and first try. And let's take a look at it. Let's take a look, first try.

Let's take a look at this in the inspector just to see what's happening here. When we look at this in the inspector, what do we notice about these, like about this LI? Like look at these LIs. What's a little different about the LIs than we've seen before? Maybe it's a little. What do we notice about these LIs that are different than LIs we've seen in the past? Yeah, they have this data ID. And we can see that the first try has a data ID of like 7F2, 7F3, 7F4, 7F5. So we can probably get a realistic idea of what's happening here. but each of these allies now have their own individual ID. And if we look, this first try and this second first try are similar in text, but they both have different IDs. Like this is 7F2 and this other first try is 7F5. So while the text is the same, the IDs are unique. where the heck are these IDs coming from? Yeah.

MongoDB automatically generates an ID for every single document in your collection. So if we actually go look at our documents in our collections, we should see some stuff that matches. Let me refresh here. All right, I got to change off of this Virginia East Coast. I need to be on the West Coast. This is just adding to like the mind blowing nature of this. Like our request to like leaving LA, going across the country, coming back and like, and that's being streamed through Twitch, which is then being sent to all these different places. This is like, what? That's how we know we're living in the simulation. Anyway, all right, let's take a look. Here we go as our first try, all right? Here's our first try with 7F2, right? Right? 7F2. And then here is our last first try with 7F5.

So we can see that these individual documents both have an individual ID. Now, the wonderful thing is that whenever we create a document, right? Right? Whenever we create a document, that document automagically, that's for you, Blah, automagically creates the ID. So it's not something that we've told Mongo to do. It's not something that we've like asked it to do. It's just whenever you create a document, it also creates an ID. And this creating of the IDs is gonna really pay off because now we have ways of targeting specific documents, right, targeting specific documents, and we can delete those specific documents, we can update those specific documents. And then as we start to add more complexity to our applications, the way that different bits of data kind of works together in Mongo is that we're able to tie everything back to IDs. So our users will have an individual ID and then each post that the user makes will have its own ID and so we can figure out who made a post by looking at something like a poster ID that ties back to the original user. So these IDs and I don't want to kind of big brain us right now with that but eventually these IDs become really important because it's how we're gonna connect different types of data together that may be in different types of collections. We can go ahead and keep track of IDs inside of our documents and tie everything together. Cool. Is there security risks with IDs being in the HTML? There are some things we have to think through.

Like I said, this is not like production ready code where being bad is writing bad code. There will be things we'll do in the future where it's not like directly, because if the IDs are directly in the code and you can make client side requests and you could like do stuff with the ID if you want it. So yes, there are ways that you could use this advantageously, but right now we only think about that. Cool. Tina says bring it. All right, so we can tell that this to do a first try is the same as the to do a first try, but they have different IDs. And so since they have different IDs, right? since they have different IDs, we're able to target those elements individually. But how do those different IDs wind up in our HTML? Like how did 7f2 and 7f5 both show up in our HTML so that we could use them? And yes, it's part of our EJS, it's in the game. So let's go and take a look at our EJS and see where this is happening. Um, where would I find my EJS in the views running through the six with my woes? I was running through the six with my woes. I got to record this I was running through the six with my woes I was running through the six with my woes I was running through the six with my woes I was running through the six with my woes Hey, does this work?

Hey, does this work? I was running through the six with my woes. All right, if this coding shit don't work out, I got another career lined up. I got another career lined up. Let's go. Only fans. Hold on. I got a VIP though. Who said it? There you go. Dominus Prime. Oh, where are you at? Where are you at? There we go. There we go, Dominus Prime.

You got VIP, my friend. All right. it. Alrighty. Crispy nugget. We got to get this EP out. We got to get this EP out. All right. I didn't run ads during break. I'm sorry. If folks are getting ads, I apologize. I'll run the ads during this upcoming break. All right. So we are going to look in the EJS for where these IDs are being added, right? So we saw that these IDs are making their way into the HTML and these IDs are unique for each document in our to-dos collection.

Where the heck are they coming from? We know that if it's rendering in our views, then we should go to our views folder and look for that to-dos EJS. And so inside the todos EJS, we have some wonderful code. So we have our code block that opens, right? With the carrots and the percent signs or modules or whatever the heck you want to call them. Our code block closes here. And the cool thing is that this code is a for each loop. Before we've seen, we just saw like four loops but the cool thing is you can use even like the newer, the newer kind of ESX plus type syntax inside of here. And so I have this lovely for each on the to-dos. And so all of my to-dos for my document are being passed into this EJS, right? In our controller, we could see where all the to-dos are being passed in. And since there are four documents in my collection, we know that this for each loop is gonna run how many times? Four times, exactly. Looks like bees, people do call them bees. Like I think that's what a lot of people call them these days.

They're like, these are bees. Yeah, this forEach loop's gonna run four times and each time it runs, it's gonna create this li. And the cool thing is that we now have this data ID property, right? This data ID property, right? And I can plug whatever I want into this data ID, right? I can plug whatever the heck I want into here. And the other cool thing is that these data properties on HTML5 plus, we can actually change this to whatever we want, right? So there could be, I could call this data rainbow if I want, it doesn't matter. We can change this to whatever we want. Data Zebra doesn't matter, right? The cool thing about these lovely data attributes is that you can call it whatever you want, right? And so I'm gonna keep it as our data ID because what I am doing is grabbing the ID out of the document, right? And so if we look at our documents, we go back to our MongoDB, we can see that each of our documents is gonna have an ID property, a to-do property, a completed property, and this like underscore V property as well, right? And so what we're gonna do is we're gonna yoink this as we build each of our LIs, right? And so if we look, our LI, we're gonna give it this lovely class, and then we made up this data attribute to be data ID, and we're gonna plop the ID in.

Remember, this L, E-L, is the element, right? Each of my to-dos, remember, it's gonna run four times. Each time it runs, L is gonna represent a different document in that collection, right? So the very first time this runs, it's gonna be the document with first try. So L or E-L will represent the document of first try. The next time it runs, it'll be the document of second try. The third time the document a third try and then the fourth time it is the other document with the text of first try So it's just our parameter that's holding each of those individual documents And the cool thing is that each of them will actually just be a what it's always just what's I was gonna hold a what each time it runs Yeah Yeah, it's just gonna hold an object each time that this runs, right? It's gonna hold an object. And so the first time that it runs, the object will be the first try object. The next time it runs, it'll be the second try object. These objects are coming from our collection. And since it is an object, right? Since it's an object, we can grab the properties of that object. So the very first time this runs, we're gonna grab that object and we're gonna grab the ID property off of it. So that way, when we actually see in our HTML, there will be a data ID and the value, the value that came out of the document, right?

So that's how we're gonna plug in the individual IDs for each one. Why is it underscore ID? Because that's the property on the document. That's what Mongo automagically creates for us. And so we're going to use that to our advantage. Cool. All right. So now we're able to build out these LIs that all have their individual IDs. Right? Welcome Ultra. Each has their own individual IDs. And these individual IDs are coming from the actual documents themselves or grabbing that ID property off of each one. Right? And plugging it into the DOM eventually right here. So L is going to be just a bunch of objects.

Exactly. Because remember, this is just a fancy for loop. and all this is doing is looping through all the documents that came from this collection, right? We can step back and see how it got the documents, but let's focus here for a second and just know that we've passed all the documents, we've handed all of them off to our EJS template, and now we're gonna loop through all four of those documents and L, or short for element, just gonna hold each of those documents one at a time. The very first time it runs it's gonna grab a different ID than the second time it runs because that's a different document from our MongoDB collection cool How does data ID know to go to MongoDB and get the ID it's not that smart we've already passed all of the documents into our EJS template, just like we've been doing in all the past of our CRUD apps, we've already passed all of those elements into our EJS. Now we're just looping through all of those objects, all those documents that came from the database. I'll show that again, just so we can see it in a little bit, but we already have all four documents. All four documents have been passed into this EJS template, and now we're just looping through each document one at a time. Don't any custom attributes work? Yeah, any data, whatever. You can change this to whatever you want. It can be whatever you want. Cool. Cool. All right.

I also have some other fancy pants stuff here that I like. What is this called here? What is this code here? Yeah, it's a ternary, exactly. So instead of having that conditional logic that we had before, like if we look at our old code, look at our old code, We had like this conditional, if completed equals true, then we add this span, else we add this span. So I did a ternary, which is kind of like an inline conditional, and I'm saying, hey, does the document have a completed property of true? If so, give it the class of completed, and if it's not true, like if it's false, give it the class of not, right? So I'm just I'm just going ahead and either giving it a completed class or a not class, and where could I go to see what these classes do? Yeah, we go look at our CSS, which is in our public folder. If we look at our CSS, we can see that the completed class gives it the line through in gray and not just has it be underline, right? So what we're doing is we're just giving it either the completed class or the not class using that delicious ternary. Cool. Let's go back and take a look at our todos EJS. So we're going to loop through all four documents that are in our collection. We're going to put in the individual IDs.

We're going to use this ternary to figure out whether or not it has a completed or or not class. We can actually see that completed or not class here in the inspector. So if I click on the first try, it now has that class of completed. We can see it right here. If I click on it again, we can see that it has that class of not, right? So I'm able to toggle that class using my ternary. Cool. Cool. Can we see that in MongoDB? Yeah, sure. So if I, let's say I click on third try. Third try is the only one that has the completed class. So that should be the only one that is true. Let's refresh here. And we see first try is false, second try is false, but third try is true, and then the other one is also false as well.

The off-coloring from EJS is super annoying. It's just you just have to tell VS Code that you're using EJS. I haven't set the file type down here to be EJS. You can like add it and like change your language, your language, and there's a way to do it for EJS. Yeah, there's an extension and stuff like that. Cool. So we are taking all four of those documents, looping through them, adding the LIs that have the individual IDs. And why are we going through this trouble? Well, why are we going through the trouble of adding the IDs again? Yeah, it helps us stop with the duplicates. We know that each of those LIs is unique, exactly. Would I reuse more again? Yeah, we'll use that in the near future. Cool, all right, let's just real quick show how we're getting all the documents into this EJS file. So folks who are curious about that, if we go to our to-dos controller, we can see in our to-dos controller, our get to-dos function, and that function goes and finds all of our documents, and then we're passing those documents to-do items into our EJS.

So this is something that we've seen plenty of times before With our previous CRUD examples, we are going to our database. We are finding all of the documents. All of those documents are now stored in to-do items. And I'm passing to-do items into my EJS template with the name of to-dos. So wherever I see to-dos inside of my EJS, it's just the things that came back from the database. Now, there are some interesting things that are here that are a little bit different. What's missing from right here that we've used all the time in the past? Yeah, we have this, we normally have two array, why don't we need two array right now? Why, why, why don't we need to array? Yeah. Cause we're using mongoose, uh, and mongoose kind of makes our life a little bit easier, does a lot of the heavy lifting for us. And so mongoose already knows that, Hey, you're probably going to want to like an array of these objects. And so it just does that for us, right? Just take some of that heavy lifting off of our shoulders and does it for us. So we have here like this to do find, we don't need the to array, it just kind of just works.

Cool. All right, so we're gonna take our break now. When we come back from the break, we're gonna dive deeper into looking at the deleting and how we're gonna use those individual IDs and the updating, how we're gonna use those individual IDs and then we'll answer any other questions that folks have. All right, folks, let's put seven minutes on the, Sorry five minutes on the timer and we'll be back soon. All right, everybody. Welcome back. Come on back. Come on back We got a couple other big things we want to do and then don't forget we're coming back on Sunday For office hours and going through this kind of like more step-by-step So you missed Tuesday's class or you still a lot of questions. No worries. We'll have office hours on Sunday then next week Oh boy We got a lot a lot You got a lot next week a lot of little stuff that we've been working on behind the scenes And then also we're getting to authentication. So super excited for next week Let's see if we have any other questions in the Slido. This is an important question just because it's here. I want to help people out on Discord, but I'm autistic and find it really fast and overwhelming. Any suggestions for ways I can contribute to the community? So Discord, you could ignore pretty much everything about Discord, except for the things that you care about, right?

So in Discord, we have our help channels and our help channels are actually threaded, um, so there's no like boom, boom, boom, one after another. You can go into the help channels and they are threaded. So there is no kind of like fast pace. So that's more helpful. Um, definitely start there. Um, because that could be pretty helpful. Um, the other thing that we're doing is like I said, we work on these those little things behind the scenes. We're talking about like other ways for folks that wanna help the community that are further along in their engineering career. We'll be talking more about those in the upcoming weeks. And we talked a little briefly about the 100 maintainers where you'll be working with folks to help kind of on actual code. So yeah, totally get it. For anyone that's new here, Discord can seem overwhelming when you first join. Find your little community, find your pieces of it, but you can ignore most of it. Like each notification is not important. find the little pockets that are important to you.

Yeah, you can individually do that too, yep. Cool. Alrighty. Any other big ones here? Why don't we use ES6 syntax for this to-do app? We are using quite a bit of ES6 syntax. We're using a lot of it actually. There are some things I think that are just easier for new folks to understand if we don't use the newer way of doing it, but there's a lot of ES6 mixed in here. And one other thing here that I thought was important. Can you please let office hours stay on Twitch for longer than 60 days. Nah, unfortunately there's one, there's, there's a few things to being live. Like I don't want, I don't ever want a hundred devs to just be like, I don't know, like a, like a, like a course on teachable or something, right. Where it's just like, you go through it at your own pace and like, there's like, you're just doing it by yourself. Like you just do video after video, like thing after thing. Like, I think there's something special about being live and together and going through work together, um, to where I want to encourage folks to join us live.

Right? Like I want you to participate in the community. And so one of the few things I can do that helps that is the office hours. Like there's an incentive to show up, um, because it'll disappear. Right. We're community taught. Right. And so I think that is really important. And the cool thing about office hours is you could be, you can join office hours at any, any point in program and get something out of it. Uh, and a lot of times the office hours aren't like, it's just kind of answering questions, right? So there are some office hours where we focus on specific pieces, but at least an hour or two, I always try to do that first, right? Like the first hour or two is always kind of just answering questions that might be helpful to anyone at any point in the program. So definitely come to office hours. I think that's one of the few things I do that like keeps community live and not just a static, you're just going through the material on your own. Yeah.

Cool. It's also why I push discord so much. Right. And it's also the reason why I don't like publish. Like I know there are like, there are things that people do like in catch up crew that like move through material. Um, but there's a reason why I haven't done that. Right. Because I really do want people using discord. I really do want people participating and any little thing I can do to like get people to interact with each other. That's, that's the goal. Yeah All righty, let's keep digging folks. We got a little bit more. I want to cover tonight All right So we, right before break, started talking about the wonders of inserting unique IDs. And I wanted to talk about where those unique IDs come from. Do you have TAs for 100 devs?

No, we are community taught. No one is above another. There is no like I don't want people blessing each other with knowledge. We come together to work on stuff You have myself that goes live. You have my wolf. Yeah, Rufio. Yeah Fox that go live on Twitch We have so many other folks that are hopefully joining the stream team soon that go live We have so many folks that are part of this community that like take time out of their day to help each other that Yeah, there's no need for that and then folks just helping in the discord channels, right Uh, it's, it's, it's beautiful to see. So, um, thank you to everyone that does help. If you've ever answered a question in the help channel, you're doing more than you realize. Um, because community talks a real thing and, and it's helped so many folks get wonderful jobs, uh, wonderful opportunities coming their way. So yeah, you want to help jump on discord and start helping. That's my thing. People that want to help, we'll find a way to help. Folks that want to sell yourself might pretend to do it, but the folks that really do want to help, they just help, you know? And so if you're that person and you feel like, you know what, I want to help others learn how to code.

Maybe you're, you're an engineer that's further along in your career pathway and you think you've learned a thing or two and you want to help others, jump on Discord. We need it and it'd be appreciated. All right, so we were showing those individual IDs, right? We had those individual IDs. Oh yeah, shout out to Rascal too, yeah. Thank you Rascal, I appreciate all the work you do. Yeah, we were putting in those individual IDs where folks are like, Leon, where are those individual IDs coming from? Where are those documents coming from? In the past, right, right? In the past, we had this db.collections.find, right? We had that whole string. But right now, what has replaced our db.connection and like anything that has to do with interacting with our database? What has that been? What is that being replaced by? The model, exactly.

The model's handling all the stuff that has to do with talking to our database. And so you can see that we've required our to-do model up here. And so we're using that to-do model in conjunction with Mongoose to go and get all of our documents. And so we are using the model that knows what database to connect to, how to talk to the database, all that fun stuff. Mongoose is handling that for us, and then we're doing find. So that's gonna give us all the documents out of our to-dos collection. We're storing all those documents in the to-do items, right? And then eventually we're passing those to-do items into the EJS, just like we've done for the past couple of times with our CRUD applications. If you're new and like that hop, skip and a jump is too much, go back to our earlier CRUD videos where we spent a lot of time in detail on like, alright, how is that to do is getting into the EGS, but that's what's happening here. We also have this lovely count documents, which is a wonderful method that will look for how many documents have this match right of completed false. What the heck is this enabling What is that enabling us to do this line right here? Line seven. What is that enabling us to do? Yeah, it's enabling us to count how many things are still left to be done. Cause remember when we click on our items, right?

Like when we, when we click on like, let's refresh real quick to make sure we're up to date. When I click on first try, I have changed that completed property, right? From false to true. So now we know there are four documents in our collection. Two of them will have the completed of true and two of them will have the completed of false. And so the cool thing is that this line of code can count how many documents in our collection have the completed property of false. And so we can also pass that into our EJS as well. And when we're looking at our EJS, we can see that we're using the left value here. So we're just plugging in how many items we have left to complete. We're just plugging that in as like a variable that we pass through. And if we look one more time at the Todoist controller, we can see that we've passed in wherever we see items left, right, this is the items left. We've passed that in, items left gets passed in with the name of left. So wherever I see left inside of my EJS, right, wherever I see left inside of my EJS, that's the number of items that are left to be completed. Cool. All righty, now there's one other tricky bit that's happening here, right?

And it's this kind of like this idea of completing or not completing. I wanna talk through that. We're gonna look at the models a little bit and then we'll see if there's any questions at the end. So when I click on this first try, what actually hears the click, right? What actually hears the click? Yeah, our client-side code. Our client-side Smurf hears the click, right? Hears the click. And what it's going to do is, is it going to try and grab, because in the past, every time we've done this before, it's just grabbed the text of first try, and then we send that text, and we try to find that text in the database to change that document, right? But are we gonna do that anymore? Are we gonna grab the text of this? No, we can use the ID now, right? that we can use that ID. So let's go ahead and look at our client-side JavaScript and see that in action. All right, let's go to our public, go to our JavaScript, main.js.

And so here we have this lovely client-side JavaScript all set up to handle different types of clicks. So we have a click on the delete, we have our to-do items that are not completed and our to-do items that are completed. Because remember, the spans could have the completed or the not class, depending if they have been clicked on or not, right? So if they have been clicked on, they get that class that helps us like make them gray and strike through. And then the not class just make sure that they are underlined. Cool. Alrighty, so if we are clicking on, let's say we're clicking on this first try for the very first time, three, two, one, click, right? That originally, right, that originally, right, that click will be heard, right, by the wonderful, one of these two wonderful event listeners, these two smurfs, right? If it has the not class, it'll be the first one. And if it has the completed class, it'll be the second one. And so we're able to listen for those two different types of clicks. Has it been completed or not based on the class that it has? That's all we're doing, right? Now, if we look at the very first time we run this, we'll run the lovely mark complete, right? That's the function that we're gonna call.

We just clicked on a to-do item that was not yet completed. Right? So we're going to run that mark complete function. That mark complete function is going to grab that item a little bit differently. Right? It's going to grab that item a little bit differently. Right? And like I said, this is a jump. It's not exactly how we do it in production, but we're getting closer to it. And so the thing I just clicked on, we're gonna say, all right, well, I just clicked on that span, right? If we look at the actual text, the thing that had the text first try that I was clicking on was the span. So if I want this ID, what do I have to do? How do I go up a level? How do I go from the span up a level to the LI? ParentNode will be one way to go from the span up to the LI.

And so that's what you're going to see here. We're going to see, all right, I just clicked on that text, this, the thing I clicked on. We're going to go up a level to the LI. And then we're going to look at the data attributes. So the cool thing is that we can make up any data attribute that we want, right? We could have called it data ID, data rainbow, data zebra, data duck, it doesn't matter. We can access all of those independent or different data attributes by using the data set and then the attribute that we care about, right? So we called ours data hyphen ID. We could have done data hyphen rabbit, data hyphen duck, doesn't matter. And then we just would have changed this to be what it was, rainbow duck, right? But we called it ID because we were using the ID, right? Cool. Cool. So now we went ahead and we were able to grab that ID. And the cool thing is we know that these IDs are unique to each individual document in our collection.

So when we go ahead and make our request, right? When we make our request to our server, we're able to pass in that unique ID, right? So we're making a put request, we're passing along that unique ID. And when we look at our controller, right? Oh, let's look at our routes first. All right, well, we made a put request on the mark complete route, put request on the mark complete route. Remember, we get to say what type of requests we're making and what the route was. That would came from our client side JavaScript. And the router said, all right, I heard your put request on the mark complete route. Go ahead to the to do's controller and use the mark complete method. So we go to our to do's controller. we find the mark complete method. And what are we gonna do? Well, we're going to find one document and update it. So what document are we gonna find?

We're gonna find the document whose ID matches the ID we just sent along, right? So that we've seen this pattern 20 times before already. When that put request was sent to our server, not only do we send the put request, but we sent that ID along with it as well. And now we're able to use that ID. We're going to find one document that has that ID and we're going to update it from completed, whatever it was, to true, right? So we were able to set that to true. There's some other stuff that's going to happen. We'll respond back to our client-side JavaScript. The page will refresh, yada, yada. We've done this a bazillion times, right? But it's still the same process just because we're adding an extra layer of abstraction doesn't mean the core stuff is Changing right? It's still the same crud out that we've been building up to it's just that now we're getting a little bit more Robust and a little bit more abstraction. So when we're working with others We're not stumbling over other people's mistakes and we're able to kind of go exactly where we need to go Well, let's look at that one more time. Let's try it a little bit differently now. We're gonna click on this.

Let's take a look at this one. We can see that this first try span has the completed class, right? Has the completed class. So when I click on it, we actually used a different click event, right? Let's go back to our client side, JavaScript public folder, main.js. All right. We clicked on something that had the completed class. So that's gonna be a different function that is called. We're gonna call the MarkIncomplete function, right? We're gonna call the MarkIncomplete function. And this MarkIncomplete function is gonna be a slightly different function down here. Here's MarkComplete, here's MarkIncomplete. This MarkIncomplete does almost exactly the same stuff, except that when it makes the put request, it's a slightly different route, right? It's a slightly different route. Before it was to do's mark complete.

Now it is to do's mark incomplete. So we have to go to our router. Our router's gonna be listening for that to do's mark incomplete. Let's take a look. Router, to do's mark incomplete. All right, we heard the put request that came along with mark incomplete. go to your to do's controller and find the mark incomplete function to do's controller mark incomplete function and it's almost exactly the same except instead of it being completed true it's completed false All righty. No res redirect. Well, we're gonna respond back to that request that came from the client-side JavaScript, right? Like that, we're gonna respond back and then it's the client-side JavaScript that's doing the reloading for us in this case. Lots of bouncing around, but makes total sense. A good to hear it and if it doesn't make sense Come back sunday sunday, we'll have more time we'll go through the whole thing again come to office hours this sunday 1 p.m. Eastern time 10 10 a.m. Pst E. Cool.

Makes sense, couldn't make it myself. And guess what? A lot of other developers couldn't. A lot of developers that are getting paid six figures couldn't do this from scratch, right? It's just, it's just, it's just not a good use of your time. It's just not a good use of your time, right? My dog keeps opening and closing. of the door. I have a dog that can open doors. That's why sometimes you can hear the little one in the background. It's because the dog decided to open the door and come see what I was up to. Yeah. So what I was saying is like, like it's your job is to know how to bring all these things together to research different ways of doing things, to pull all the pieces together. Like you are an engineer, engineers don't do stuff from scratch. Engineers can go look up formulas.

Engineers can go look up the right tool for the job. You wouldn't expect an engineer to necessarily be swinging the hammer, right? When there's been a, something has been developed to help them do the job. You are all here are all engineers writing the individual lines and knowing every individual piece from memory is not a good use of your time, right? We work smarter than that. We have the templates that we have. We can pull the pieces in together. You have to understand how the system comes together. But the individual lines that doesn't come until you've been doing this for four years, right? All right, questions while we're here, questions while we're here, if I want to be a carpenter, You're first gonna need to learn how to build a saw from raw metal. Exactly. No, we just don't do that, right? Real engineers uninstall the Windows calculator write a new one from scratch whenever they need to perform a calculation exactly Jay Hawk, I think your question got blanked out. I think he said, could you go over a parent node again? Parent node is just when we're looking at the span, right?

The span is inside of the LI. So if I'm actually clicking on the text, I'm actually clicking on this text that's in the span of first try. but the idea I want is up here on the LI. So to go up a level, I can do parent node. We could have also done like query selector and a bunch of other stuff, but my goal is to show you a lot of different stuff and then build up to the more performant ways of doing stuff to build up to the ways we'll actually do it in production. So yeah, you can think of the module exports as like just functions ready to be called or objects ready to be used until they're required. The data ID gets set on the first get request, right? Exactly, yep. When that get request comes through, or actually right now, on every single get request, we're redoing the DOM, right? On every single refresh, this all gets repainted. And so maybe that's something we might think about when we get to React is like, do we need to be repainting the whole DOM every single time. Yikes. Hey, the last two classes really helped solidify this concept for me. I whiteboarded a presentation of this to my niece today and surprised level understanding talking through it. Yes, let's go.

That's the beauty of of of working through this, specifically the lecture. I know it sounds like a silly assignment, but I trust trust me if you just do it You're gonna walk away with so much more like it's one thing to learn It's a whole other thing to teach and the way our brains work is we get all these new Connections when we try and explain something to someone else, right? and so just the act of building the lecture and figuring out all the gaps the things that don't make sense and investing time and understanding them and then trying to Articulate in a way that makes sense to others that just like is like cheat mode It's like it just does something in your brain It's gonna help this click a little bit more and then the things that you're still really struggling Oh if you come to office hours on Sunday, so please do the assignment. It'll really help My will say I second what Leon is saying I do this all the time it really is it really does Help the the things sink in so try give it a try Cool. All right, let's take a look at the Slido real quick. I'm going camping next week, can I submit my MVC lecture early? No, but you can, it'll be open on Tuesday. Sorry. I probably won't announce the winner for a week, so you'll have some time. Variables used in the index, where are the functions? Variables used on the index, where are the functions? For example, on the items left, where is the function that decrements minus one? Oh, I get what you mean. So this is a really interesting question. So in our todos controller, we have this count documents.

So there's nothing that's like subtracting or adding. What this is doing is literally counting the documents inside of our collection. So it's going to Mongo and literally counting how many of these things there are. So that's where that's coming from. If you're building like a super serious application, you might store that number into memory so that you're not like counting because that might be like incrementally faster. But one of the things you have to realize right now is like none of these optimizations like matter until you're on the job. And when you're on the job, you'll just research the way to make it more optimal, right? It's not something you have to know in this moment, especially when you're first learning. There are so many ways that we can make this code more optimal, more efficient, but this is a learning exercise, right? We have to get there, and to add all those little bits and bobs, it's just too overwhelming. Let's understand the core of what's happening, understand what MVC might bring to the table, and we'll have time to add all this extra stuff. So you have the presentation that you have to do. The other thing I'm gonna ask is to tweak this in some way, make some changes to this, figure out something you wanna modify about this application, right? Because the way you learn, the way you're gonna learn, especially this part of programming going forward is by building. Please don't just listen to me and then go home and do banky and that's it, right?

Please actually break this, build with it, play with it, get stuck, get lost, bring it back to life. Jump in a Discord voice channel, say, hey, I'm gonna do X, Y, and Z, come join me as I do it, right? Like build, build, build, build. If at this point in time, you are not building, you are messing up, right? You're gonna learn so much more from building than you are from just listening to me, right? Listen to me to maybe understand how this all comes together and then build. Comment at least, oh, that's a really good idea. Yeah. So at least comment it. Right. On the job. Unfortunately, you're not going to get paid to listen to me anymore, right? Like you're going to get paid to build stuff. So start practicing the building too. And then maybe incorporate the thing that you changed into your presentation Cool all right any other questions Alright.

Cool. Let's end with a raid and then we're going to come back on Sunday. We're going to go from beginning to end on Sunday and I'm going to answer all your questions. It'll be traditional office hours. So you got questions about this code bring them you got questions about the hunt anything in general Come back on Sunday, and we'll go through it all together

End of Transcript