Introduction

Rufio with the ray let's go. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Hey, good morning. Good afternoon. Good evening. No matter where you're coming from. Hope you all are doing well.

Welcome back. Rufio. Hello. Rufio with the raid. Oh, string team coming in through. I love to see it. As always, folks, if you have some time before, before class, what are you doing? Should be hanging out with Rufio. Then you come through with the raid. You're stacking points on top of points channel points on channel points Good to see you all Full stack your first live class a welcome Jason car hey, thank you for the fog. It's us. Hope you're doing well Curse as I was, but I was watching the bachelor. Oh, sometimes you got to put the bachelor down to, to check out the stream team streams, you know what I'm saying? That's how you got to put the bachelor away to come live to class. I know how it could be.

I get that way too. Welcome everybody. Hope everyone is doing well. Hope you are having a good Thursday, uh, tonight as promised, we are running them back the crud, the create, the reading, the leaving. But tonight we're putting the you in crud as well. So we're going to do what we did last class where we see the example live. We talk through it. We see it multiple times from different angles. We draw it out. We see it live. We look at the code, right? And then once we've done all that, we're going to look at all the little accessory things that are making this run, connecting our database, making sure that we can use environment variables and other fun stuff like that. So a lot of stuff to get to tonight. We're going to do less review than we normally do. We're just going to jump right into the crud.

But before we do that, and before we jump right into the crud, let's go ahead and see if folks have any questions. Always like to start off with a few questions just so that folks that are running from work or doing the things they had to do can come in and get in here. So let's go ahead. Do we code along? I don't really think this is like a code along type class. This is more of a watch and ask questions type of class. Question of the day, the question of the day is what is your favorite crud operation? So are you more of a creator, a reader, updater or a deleter? What are you at in chat for me? Put in what is your favorite crud operation so far? I think a lot of people are doing creating a lot of folks saying deleting a few updates here and there. Maybe, maybe, maybe it's because we haven't gotten to update yet. So people don't have the love for update. Like they have the love for creating, reading and delay. So maybe, maybe that's what it is.

I think I, my favorite is the reading. And I'll tell you why. The reason why the reading is my favorite is because the moment that I understood that when I hit enter, it was making a request to a server. And the server heard that request, went and talked to a database, got some data, plugged it into an EJS template. and then it spit out some HTML and it responded with that all the way back to the phone that was in my hand. And it took under a few seconds and it just worked. Like what? That's the internet? That blew my mind. So I'm a reader. Civic, I already shared the source code. It's in the materials for today. And it's the same materials that we used last class as well. Oh, Mellie Ruru, Mellie Ruru. Hey, thank you for the gifted subs.

I appreciate that. Fly Ashley with the crate. Hey, welcome. All right. You ever get into the office? The office was my... Are folks having trouble with the slides? Casasaur says that they're getting a 404. Are folks having trouble with the slides? Let's make sure that it's the right link in there. The live slides, yep, 404. All right, let's see. This was the link for it, so this should be the live slides. Let me put this in chat for y'all. And then I'll update the, we know what a 404 is, yeah, we do.

So let me try opening this in the Cognito window. Huh, I'm getting a 404 too. Oh, you have to put slash live on it. Oh, maybe we forgot the slash live, that's what it is. Yeah, yeah, we forgot the slash live, I'm sorry. There we go. Oh, let me update the night bot too so we have the updated one there. Yeah, I just forgot the slash live. Cool. All right, there we go. We should be all set. You should be able to use it now. You can do the expiration point slides, get the slides if you need them. And it should just be the slash live that was the problem there. Cool.

Alrighty. I have a call with a local recruiter next week. They got in touch with me after we met at a local meetup event. I don't feel ready. Any advice, know what you're walking into say, Hey, I'm really excited for our call next week. Is there anything that I need to prepare? Is there anything that you, that I should know? Is it more just of an informational getting to know each other type of call? Right. Don't go ever go into your calls with recruiters or any type of interview, like an accident. Always know, right? Always know what you're getting into. Cool. Pipeline, that's actually what we use. Yeah, that's what we use.

Oh, somebody said, we were talking about the office, sorry. Uh, so I've watched the office at least seven times, like all the way through. And for the longest time, it was the television show that I fell asleep to. And so I grew up with like something always in the background playing, like, like something on the television or something playing in the background. And so it's very hard for me to fall asleep without like noise playing. And so sometimes I use like, you know, like a white noise thing or like, I, but For me, I just normally let shows run and people talking helps me fall asleep better. And so I liked the office because it's all people talking. Right. And then I was on Reddit and I found out, I found out that, um, that there was a subreddit, right. It was a subreddit for folks that fall asleep to Futurama. Like it's a whole subreddit just dedicated to people that people that fall asleep To listening to Futurama and then in that channels like wait a minute. That's what I do But with the office and then there's a whole subreddit for folks that fall asleep to the office, which I thought was pretty funny, too So apparently it's a thing people do and so I've I've seen I've seen the office at least Seven runs through and probably way more because I fall asleep to it. Yeah All right, I think we got the I think we we got to it. I think we got some questions here Trashy glad you're back live with us a Alrighty, thank you the questions. We got a lot of stuff to get into tonight.

So let's jump into it Please, if you haven't already, check in, right? Check in, you do exclamation point, check in here. That'll give you the link to our tweet. Go ahead and like and retweet that for me, please. I had some folks that are starting to get, that are starting to get like, like getting towards the end of their interview phase and they're asking for references. And so they'll reach out to me and I'll say, all right, Well, let me, let me see all the projects that you built. Let me see the things that you've done. Let me see if you were here for class. Right? So this is important. This is important to me is one of the things I look at before I, before I put my, before I put my, my, my, my, my word on the line there to say this person knows what the heck they're talking about. I need to see that you were here. I need to see that you were doing the stuff that you said you were doing. And so checking in is really important. It's one of the first things we look at when we go out and make sure that we can do that post-program support that we're trying to build for y'all.

So please if you haven't already checked in go ahead and like and retweet it. It also just helps more folks find us All right Leon how can I make you laugh? I don't know. It's pretty it's pretty random pretty random All right Is missing last class a problem for today and maybe not so much we're gonna do a lot of review We might go a little fast through the creating the reading and the deleting but you'll be able to hang on, I think. Yeah. Cool. If you haven't submitted your work, right? If you haven't submitted your work, please go ahead and submit your API homework, right? Please go ahead and submit your API homework, right? If you haven't already, go ahead and fill that out for me, please. It's been really cool seeing all this stuff that you built. Last class, you were able to build APIs, but then this week you're able to build full CRUD apps. Let's go. You gotta really think about, I put it in the email today. I was like, think back to when you were learning HTML and that was the world.

Then think about when you were learning CSS and that was the focus, right? And now you're all out here trying to build full stack web applications. You already built your own APIs. Like what? That's wild. And so I said it before, I'll say it again. Each and every single one of you that are here right now You should be proud of yourself. You should be proud of the work that you're doing, to show up time and time again, to keep throwing yourself against that brick wall, which is learning how to code. The stuff you're being able to do right now is just mind blowing. How many folks set out on this journey to be able to do the things that you know how to do? And yes, the backend is wild. Yes, we're connecting a lot of different pieces, but the more you throw yourself into it, the more it's gonna be able to click and the more it's gonna happen. And so I'm glad that you're here. I'm proud that you're here. Let's keep it pushing.

Pseudo co-op with 19 months, what? Yo, Pseudo co-op, thank you for the sub, I appreciate that. All right, let's keep pushing here. So, we had a little run-in with the Code Wars crew. So let's talk about it real quick. Um, the, the marketing manager, and I think it was the CEO, um, from code wars reached out and they kindly requested that we set our repos to private. So if you are pushing code wars to get hub, they kindly asked that you turn those repos to private. And, um, there is a setting on get hub where if you make your repos private, you still get those delicious, delicious green squares. and apparently it's one of their, you know, one of their lovely, lovely rules baked into their, into their code of conduct. And so they asked nicely to me via email to, if I could relay the note that you should set your repos to private. Now the code is yours. It's licensed to yours. What you decide to do with that code is up to you, but I think we can, we can be good neighbors, right? We can be good neighbors, and if you feel like it, go ahead and set that to private to be a good neighbor. Now, I don't think the folks that some folks have run into in their Discord is representative of Code Wars as a whole, so let's try not to base our judgment on the actions of a few, just like we wouldn't want folks to judge 100 devs on the actions of a few, right?

So they've asked nicely up to you whether or not you want to you want to to do such But they have asked that you set your repos to private But why so they don't want folks To be able to like Google the answers, right? Lena Lux. Hey with the raid what's going on? What's going on? Thank you for the rate. Thank you for bringing everybody. Bye. Hey, how you doing? Were y'all working on today? What were y'all up to today? We with the the last way we got to see that the projects come along the games come along like the outside Area being able to like run around like that. It's wild to me. I see that whole thing come to life I hope like you like when you're done the game you do like a documentary of like all your past footage Just like combined together and then like you'd like release. I don't know. I think it'd be pretty cool Getting through the cutscenes today, that's dope.

That's pretty cool. If you're not following them I know they're good friends of a hundred days. You're not following. You definitely need to follow them I mean, let me paste their channel here and chat I've said it before but I'll say it again if If you, if I'm on, if I'm like working, I'm probably lurking in their chat. We were, we were just talking about how I like to have things playing in the background and their channel is definitely one of them, but it's also just wild to see, like, not only is it like in the background, so you like, you feel like you're not by yourself, but to see like the progress, it's just, I don't know. It's inspiring. It makes you want to write better code. So if you want to write better code, you should definitely be hanging out in their chat, uh, just to see someone that's throwing their, their passion into a project that, that kind of gets you going to do the same thing with yours. There we go. Boom. Yeah. So. We, um, we, we just were talking about how Code Wars asked us to mark our repos as private. But the thing that they're afraid of is folks like are trying to solve the code wars challenges. They Google the result.

They see it. They plug it in. Now. I think that ship is way past sailed. There are full repos of every code wars that's ever been posted with the solution. But it's one of the things they ask so we can be nice. We can be kind. And it doesn't cost us too much to do so. But I do think the code is yours. It is licensed your way, right? It is licensed to you so you do whatever the heck you want. Don't let some guy on the internet tell you how to live your life. Do we still get green activity if we make our repos private? You have to turn the setting, right? You got to turn the setting on, on that repo to get credit when you push to it.

Yeah. Yep. So just make sure you have that setting on so that as you push, you still get credit for the private repo. Cool. Account contribution settings. There you go. Thank you, Chibi. Cool. Yeah, it's account and then contribution settings. Yep. Cool. Can anyone tell me why today's source code has a huge font? because, and then we're going to keep going into it. I have like this little settings.json that sets the font and the terminal to a specific size. So if you clone down my code, it's going to set your editor to that size.

I didn't do this on purpose. I just forgot. Cause I have to make mine bigger for stream, right? And so I guess when I push this, I should have added this to my what? What should I, what should I have added this to? I should have added it to my gitignore. So yeah, when we go over the gitignore, that'll be the thing that we add to the gitignore so that folks that clone it down don't have to worry about that. Cool. All right. Homework. I asked you to watch these videos. I asked you to read the article by Zelle. Once again, a huge shout out to Zelle. I really do think they make some of the best tutorials online. They really do break down Some really meaty topics step by step with like pictures of everything.

So a lot of stuff that we're using tonight They have walked through in detail So if you need that detail, especially after you've sat through class and going back to this reading will be a little bit easier And so I I think that it's really worthwhile to go through it. I've assigned it multiple times I really do think it's that important even though it's meaty I think it's really important to go through and shout this out for making great content and then making it free Cool summer break folks Summer break. Let's go turn up So we will be taking a two-week break if you missed last class Which when we announced it we're taking a two-week break. So tonight is our last class for two weeks including office hours. So no office hours, no class, but we will have some project nights in between. So if you wanna come and work together, we'll have some time for you to do that. If you wanna work on a credit app together, we'll have some time for that. We'll have the stream team going strong. So we'll make sure that we can highlight members of the stream team during this break so that you're not by your lonesome, that you have folks to code along with, whether it's Lena Lux or somebody on the stream team, know that there are people that you can just hang out with while you're getting your code on if you choose to do that. So for the break, you can dealer's choice here, right? Or players choice, I guess. Right. And so the idea here is that you can take a break. If you need to take a full break, that's OK. Use this time to rest, to recharge, to get ready for the next phase of program, which is building real full stack applications and getting ready for our interviews via the hunt.

The next phase of program is difficult, it is intense. It is probably the hardest part of program, not in terms of learning to code, but the sheer things we have to do to make sure we secure that job. So if you need to take the break, you need that time to relax and recharge, boom, go ahead and do it. Nate said, we were on a break. I should have used that as the gift. I did that for the last one. Um, if you need the time to catch up, we have so many members of the catch-up crew that are, that are scrambling to, to get caught up and join us live. I'm hoping that this two week break gives you that chance. If you want to join us live for the end of program, you can use that time to catch up, right? If you haven't done your professional stuff, maybe some time to get that professional stuff done, the completing the checklist, getting some hours into your a hundred hours project. I think that's what some of our project nights will be around. We'll be around getting some of that hundred hours project done And then the last thing too is it might be time to start thinking about your hit list So these are all things that you could be doing over these next two weeks It's up to you how much or how little you went to do just come back ready to put in that work to hit the home stretch to get our last few classes in to hit the hunt ready and be ready for Megasummer, Megasummer is making a back folks. If you don't know what Megasummer is, oh boy. When we come back is, ah, you're in for, you're in for a treat. The hunt begins exactly blah.

The hunt begins. Megasummer begins. That's all I'm going to say. If you know, you know, but when we come back, it's whoop, whoop. Oh boy. That's all I'm going to say for now. Let it linger. or you can go dig if you want to dig, but you were coming back to some bangers folks. So take the time that you need if you need it. And when we come back, I've saved the best for last. I have saved the best for last. I said for these past few classes, these past few classes really have been my favorite, like this building of your API to transitioning to building crowd apps. This is my favorite part of program, but the best part of program is the end because it's when you start to reflect on all the skills that you have, right? You start to reflect on all the things you're able to do and build, and then other folks start to see it as you start the hunt. And so I'm really excited for you to get into that phase of program.

All right. Let's get into the backend, folks. We're not wasting any time. We're getting right into it. Last class, we talked about the creating, the reading, and the deleting. Tonight, we're reviewing that. We're going back to it. If it didn't make sense, that's great. We're jumping back into it. Continue to ask your questions. Remember, Discord, we have a Node help channel. Please use these help channels. And please, over the break, we're gonna have a lot of folks that are kind of plugging away, trying to catch up. If you have the time, go into those help channels. Be kind, be helpful, answer their questions, okay?

I really would appreciate that from all of you. There's a lot of folks here. If folks showed up in those Discord channels to help others, folks that are on the catch up crew, folks that are feeling a little behind to get the support they need. And so I'm going to ask that of you over the next two weeks, if you have the time. All righty. Let's get into it. We also need folks to show up and ask questions. Exactly. If you have questions, make sure you ask those questions. Cool. All right. We're using node, right? We're using node, right? So he said, Leon, I watch this with parents, please. Oh, the back end.

I was like, what? Yeah, uh-oh. He got got then I guess. All right, so we're using Node. And when we first started using Node, right? When we first started using Node, we were using the raw modules. We were getting in there with the HTTP, the FS. We were getting there. Every, every, every single, every single request, we had to custom build a route. We had to tell it what type of content to expect. We had to tell it how to send it, when to send it. We had to do all this stuff. Ugh, ugh, we had to do all this heavy lifting. And the problem was that it wasn't clean. We had to always think through exactly what the users are going to do it It just was a lot to do and so we said how can we clean this up?

How can we clean up our back-end code that was using know that was using the core modules? What's something that can make our lives? easier Of course it was express Express came in to save the day to make building our API's Anything that deals with that listening for the request and generating the response, the Express helps us do, right? So, before we jump into Express and how it's changed our lives, we wanted to start off by talking about how does the internet work? And I've given myself a, don't do that to me. Don't do that. So we, I don't know, I don't know, only OGs remember that, but, um, one of the weirdest things is like, so you're streaming, right? Like you're streaming, people will pop in and they'll like, see something you're doing. And they'll be like, well, what about this thing? Like, why aren't you teaching them this? Like forget that we've been how many 40 plus live classes, dozens of office hours, somebody will jump in and be like, well, why, what about express? Why aren't you teaching them express? Right. And so last cohort, we were showing like the raw modules and somebody came in and said, what about express? And so, uh, that's, that it's, it's kind of a little bit of a meme if you know, you know, um, but it's kind of funny because the reason why we don't start with express is so that you see the pain, but also so you like, you know, the, the benefits that you're getting, right.

If you jump right into express, it's a little harder to see like what's happening underneath the hood. You don't understand like why we're using a framework. And so that gentle progression, I think does help things solidify a little bit more in your brain, yeah. But yeah, we'll always have some code we need to stop in to ask us about what we're doing that day, which I think is funny. All right, so let's talk about how the internet works. On one side of the lovely wire that we've always talked about is we have our client side devices. And our client-side devices are just computers. And often we have running on these computers a program called a browser. Right? And that browser enables us to do things that make requests to other computers out there on the internet. And these other computers that are out there on the internet we call servers Now why did we call these other computer servers from the very beginning why are they servers? They serve exactly And I'm not, I'm not talking like early 2000 break dancing. You got served. I'm talking about files, right? I'm talking about things that we're going to send back to the browser, right?

And so we had these client side devices and we go ahead and we type in things into the browser. Like we type in a URL and when we hit enter, that makes the request to a server. What are some other things that we can do on the client side that would make a request to a server? We talked about like typing in a URL and hitting enter. What's something else that we could do, right? What's something else that we could do? Yeah, we could refresh the page. If we refresh the page, that's also going to make a request to a server, right? What's something else we could do that can make a request to a server? Yeah. Filling out a form, submitting a form can make a request to a server. Um, clicking an anchor tag. Thank you, Hazel. That's a good one. Clicking an anchor tag can make a request to a server because it's trying to take us to a new page.

Right? So we said, enter a URL. We said, refresh the page. We said, click a link. We said, submit a form. And then the last one that we saw just briefly with the deleting was this idea of making a fetch to a server, just like we used to do client side. Well, our apps can also make requests to the server via fetches, right? And the cool thing about fetches is we get to say what kind of requests it's going to be. A fetch could be a delete, could also be an update or a put. We get to decide with our fetches. Cool. So we have all these different ways of making requests that come from the client side and make their way to a server. Now, these different kinds of requests all have names, right? We know that they are gets, they are posts, they are puts, they are deletes, right? Where do these names come from?

Why is it called a GET request, a POST request, a PUT request, a DELETE request? Yeah, these are the methods that HTTP understands. Remember, the thing that is handling the requests and the response back is HTTP. It's the protocol that we use for the internet to work, right? And a part of this protocol are these different methods, the get, the post, the put, the deletes, right? They're all part of HTTP. And we know that since we're using Express, Express is the thing that's helping us utilize all these methods to listen for them, to respond to them. We could code it with the raw HTTP module, but Express is gonna make it easier for us to do what? Express is gonna make it easier for us to build out our what? There's a specific name for it. Our APIs, exactly. So running on our server is some code and that code typically has a portion that's listening for these requests. And we call that portion of the code our API. and that API will be set up to hear the gets, the posts, the puts, the deletes, right? And when it hears those requests, we are in control as to what happens.

Just like with a click event. When our users heard a click event, we got to write the code as to what happened. Sometimes we were flipping a coin. Sometimes we were doing rock, paper, scissors. Sometimes we were doing some math, right? When we heard that click event, we got to write what happened when we heard that event. It's the same thing with our APIs. Our APIs are set up to hear specific requests on specific routes. And when it hears that request, we get to code what happens, right? We get to code what happens. Now, these methods that are tied to HTTP, the protocol for how we send and receive stuff across the internet, they're not cool enough, right? We want some words that we can use to talk about these different operations and what is really happening in our applications. So instead of get, post, put, delete, we've come up with a better acronym that that describes what each of these methods are actually doing. Please play the music. Yeah, we added crud.

Create, reading, updating, and deleting. It's not get. It's read. Not post. It's create. It's not update. So it's not put, it's update. And it's not delete, it's delay-tay. Anybody love how the music just definitely like, like petered out for me right at the right time? I'll take that. So when we are talking about these methods, we've given them names that are just a little bit cooler that help us to describe what's happening in our applications. We're creating, right? We're reading, we're updating, and we're deleting. And that just makes it a little bit easier to think through what's happening in our application. And so we make these requests.

There's some code that is running on our server that hears these requests, and then we can do whatever the heck we want. Sometimes we go to a database and get data. Sometimes we spit out some HTML and respond with it. Sometimes we just say everything went okay. It's up to us to decide what happens when we hear these requests. And so that's what we had ventured out on. We ventured out on building an application that could listen for all these requests, generate responses and respond. Cool. So we know that our creating is when we're trying to make something. Our reading is when we're trying to get something from the server, or updating is when we're trying to change something, and deleting is when we're trying to remove something. And we see all four of these operations coming to play inside of our application that we started last class. So here is our current wrappers application. And when I refresh, I can see the list of my wrappers that I've added. I've added their stage name and their birth name. We also have a number of likes and we also have the ability to delete.

And so we have all these different wrappers that we're adding. I'm able to create, read, update and delete. So my question here, what is the creating in this app? What are we doing to create the first bit of crud creating? What are we doing here in this app that enables us to create? Hey, master, firewall, welcome. Yeah, that form, submitting that form is what enables us to create. Thanks, Drift. Yeah, when we submit this form, we are making a create request to our server. Beautiful. What can do a read request? So what's a read request in this application? Yep, we can type in the URL, like we could type in localhost 2021, 2121. We can also refresh the page. So refreshing or typing in the URL is our, I see his arena, that enables us to make that read request, beautiful.

What are we doing here that's an update request or a put? The likes, exactly. When we click this thumbs up, what we are doing is we're trying to eventually update something in the database, right? If we click on Rico nasty, that goes from one to two. When I click that thumbs up, a request made it all the way from my app here to my server, from my server, we sent a request to the MongoDB database. The MongoDB database went from one to two. And then we took all that data. Oh, we put that from one to two. And then we sent back to the browser that everything went okay. The browser refresh, which is a get request. And now we see the updated two. And it all happened like that. Doesn't that blow your mind? Like, come on, let's just think about this for a second. Right?

Hold on. Let's click on Polo G here. Three, two, one. Look how quick that was. Look how quick, like what? Let's, come on, let's think about that. All right. I clicked on the thumbs up. What heard that click? What's the only thing that could hear that click? Maybe I should show chat. What's the only thing that could hear that click? Yeah, our client-side JavaScript. Our client-side JavaScript heard that click. And once it heard the click, it triggered a fetch to my server.

The server had some code running on it that heard that fetch request from my client. and part of the code that got triggered to run when it heard that request was to go to our database, find the Polo G document, update it from two to one, and then respond back to the fetch saying it went okay, and then the page refreshed, making a get request from the from the client to the server the server heard that request it has some instructions part of the instructions was to go to the database find all the documents this time plug them into EJS the EJS spits out the HTML and then it responds all the way back to our client. What? Look how fast, hold on 321. What? Look at that doesn't blow. There's nothing else I can do to blow your mind other than that, right? Nothing I can do to blow your mind other than that. So that's what we're talking about tonight. Tonight, we're going to step through the creating, the reading, the updating. And then the last one that we talked about is the deleting, right? We know that if we click this trash can, it's almost the same thing that happens when we click the thumbs up. But instead of it being an update request, it's a delete request. Same thing still happens. We go, the API, here's the request.

We go to the database. We've remove a document instead of updating a document, remove a document. We respond saying everything went okay. The page refreshes. We make a get request. The get request goes against all the documents. There's a document missing now. We pipe all the documents into the EGS. The EGS spits out HTML. The HTML we respond with. Like the fact that this all happens and that I can code it and I can make it happen. Like what? Blows my mind. So let's get into it. Let's step through each of these individual pieces.

Let's put the U in CRUD as well. Then we're gonna look at kind of all the other little accessory things that we need for this to function and we'll call it a break. And the fact that we know it exactly, let's go turn up. All right. So we introduced two new bits of technology to make this app work on Tuesday. The first bit was a MongoDB. MongoDB is the database we used in the beginning, because it just helps us build full stack web applications. And the beauty of MongoDB is if you know how to interact with objects, you know how to interact with MongoDB. MongoDB is made up of collections of documents, right? Collections of documents. But those documents are really just what? Yeah, they're just objects. They're really just objects. Beautiful. Just objects.

Cool. And so when we put stuff into the collection, we're really just putting objects into the collection. And when we get stuff out of the collection, we're really just getting objects out of the collection. So if we know how to work with objects, we know how to work with MongoDB. and that makes it a great first database when you're using JavaScript. Cool. So we have MongoDB made up of collections full of documents. Those documents are really just objects. Dragging that, hey, what's going on here? Those are really just objects. So we introduced that. And we also introduced this concept called EJS. It's in the game. So EJS is simply a what? It's just a, it's a what?

Just like our Mad Libs were, just like our HTML5 up was. EJS is just a what? Just a template, right? It's just a template, right? It's just a template. And like any template, we can plug stuff in. And the cool thing about this template is we can plug in all of our data. And at the end, the EJS just spits out regular HTML. So a lot of folks, when they first see EJS, they get a little twisted at first because they're like, Leon, this looks like you're mixing JavaScript and HTML. No, EJS is its own thing. EJS has its own syntax, right? Its own rules and rhymes for how you write that code. It just looks like HTML and it just looks like JavaScript for our convenience. Thank you EJS for making it convenient for me to write EJS, right? So the cool thing here is that if you know your JavaScript and you learn a little bit about this syntax they use, like the carets and the modulus or percent sign, if you learn that little bit of syntax, you can build whatever you want inside of this EJS.

And the cool thing is, it's really just JavaScript, right? It's really just JavaScript. And so the cool thing is that we can use the JavaScript that we already know to do things in a dynamic way. We can plug in our data, instead of things being hard-coded, we can generate as many, let's say, LIs as we want it. If we look at this app, did I know that there were going to be five wrappers at the end? Did I know that there were going to be five wrappers at the end? No, there was no way I knew how many wrappers there were going to be. So there is no way I could have just hard-coded HTML. I could have tried. I could have totally hard-coded HTML that we respond with, but that's not what we want to do going forward. We want to be able to get data from our MongoDB database and plug it into a template. And that template, we want to be able to spit out HTML. And so that's exactly what's happening with our EJS. We're able to pull in data. And once we have that data, we can build out individual elements of our HTML and then once the EJS is done running, it's run through all of our data, it's generated all these elements, it just spits out a regular HTML file.

So no, I am not mixing JavaScript and HTML because the end result is to spit out HTML. How is this different than appending childs with click events? Well, do those children persist after you refresh? If we had a click event and we were just appending children, like let's say we're doing a to-do list, which we'll do after break. We're building a to-do list and we're just appending children with click events. Does that stay once we refresh? No, because the data was only client side. What this is a full stack web application where our data is persistent, meaning that we can always go and get it. It's stored in our database, right? And so we're able to pull data from our database, plug it into this template. And as we refresh, like, look, I'll go back, boom. I'll refresh, I'll refresh, I'll refresh, I'll refresh. The data staying there because it's not local. It's going to the database each time to get this data. Every single time I refresh, boom, I refresh.

It went to the database. It got all the documents out of my database, plugged it into my EJS and that EJS spit out HTML and that's the HTML that you see loading. That's happening every single time I refresh. Put up GL form. What are the limits of local storage? That it's local. Oh, what if I want everyone to be able to use this application? If we're just storing stuff local on your local host, everyone's gonna have a different set of wrappers, right? Everyone will have a different set of wrappers, right? Cool. Alrighty, so we add it to the mix, this MongoDB, and we add it to the mix, this EJS. Let's talk through the getting, the posting, the putting and deleting with this graphic. Then we will go piece by piece, drawing it out, and then looking at the underlying code, right? So we're going to see it step-by-step, not only this piece, but the underlying code as well. So if we're looking at this document, or sorry, this application, and I click refresh, what type of request have I just made?

I just click refresh. What type of requests have I just made? I made a get request, right? A read, a get, or a read. And so if we're following along this pattern, what happened when we clicked refresh, we clicked refresh, that get request made its way to the server. There was some code running on our server that was set up to hear that get request. Just like we could have click events that would listen for clicks, this code running on our server called the API was set up to hear that get request. Now, how many get requests could we really have in our API? How many get requests could we have as part of our API? As many as I want, exactly, infinite. We'll get as many get requests as we want. Now, how do I differentiate between the different get requests? What if I went to localhost 2121 slash Pokemon? on, right? How do I tell the difference between these get requests?

Yeah, the routes. I see, Surly, it's the routes. So when I click refresh on this page, look at the URL. What is this route when I click refresh? What's the route here? It's a forward slash. Yeah, that's the default route. It's root. It's the root route, right? And so we don't see it, but it's there, it's the default. So when I refreshed, that get request left my client side, made it to my server, the server heard the get request, right, heard the get request, it made sure that it was this route, and then it had some code to do what it needed to do. It had some instructions to follow. So it heard the get request, And once it heard the get request, the first thing that it did is it went to our Mongo database and it found all the wrappers in my wrappers collection. What up Andre? Right, we heard all the, we got all the wrappers in the wrappers collection.

Each one of these documents represented a different wrapper object in my collection. So we got all those wrappers from the database, right? We took all of that data and we plugged it into our EJS template. What did our EJS template spit out? Yep, it spit out HTML, and that HTML is what we responded with. So all those steps happened. We heard the request. We went to the database to find all the wrappers. We got all the wrappers, we plugged them into the EJS. So we wound up creating an LI for each one of the wrappers. When it was done generating all that content, it spit out a singular HTML file and then respond it, right? Respond it with that HTML file. Cool? All right. Now, we're gonna take our break because we're at the top of the hour.

When we come back, We're gonna walk through the the posts the put the delete Then we're gonna go step by step. We're gonna write it out again We're gonna look at the underlying code for each one of these see how everything connects We're gonna take a look at the the Mongo database live be able to see all the content that's in the database We're gonna connect all these dots that by the end of tonight's class You should understand how to build an app that can create read update and delete We've got to add Jasper's two minutes, that's right. So we're going to do a seven minute break. If you're able, please get up, move around, hydrate. When we get back, we're going to keep jumping into this. We're going to make it make sense. We're going to get into the code. Give me your all tonight. Put it all on the line for me tonight because you got a two week break after this. Give me every ounce of focus and attention you have and I'll give you two weeks to recover. I'm gonna walk through each bit, then we're gonna see it each inside the code. That way you have the raw materials you need to build these applications should you wanna build something over break. I think I'm making an app similar to IG for my 100 hours project. Do you think it's a reasonable project? Absolutely, yeah.

I mean, we're going to build something very similar together. Like we're going to build a clone together. So yeah, you'll have everything you need because we'll do it. Music Error Sue added two more minutes. We're going to add that to the next timer. So our next break will be seven minutes as well. All right. So we will not typically be hard coding HTML slash CSS in real job scenarios. Yeah, a lot of time you're not really hard-coding HTML or CSS anymore. You're using a templating language. You're using components by something like React. So yeah, you still have to know what HTML and CSS is, right? But you won't really probably be writing that from scratch. Yeah. Alrighty, so we talked about the Git.

All right, let's talk about the post. What's the post or the create here for this application again? Kerb said, why does index.ejs have an EJS extension rather than HTML? Because it's not HTML, right? It's its own thing called EJS and EJS spits out HTML, but it itself is not HTML. It just so happens that it it renders out html. Remember when we look in the express We're going to see that it renders ejs and it renders out an html file Is ejs front end yes, it's still technically part of our front end code But we're full stack developers. So right now we're doing we're handling both the front end and the back end at the same time And eventually we're gonna add more organization to our code via some architectures like MVC. And that's why right now, all of our EGS files are in a folder called views, but we're not there yet. We'll add that layer of complexity and organization as we get a little bit further in. But there is this idea that right now we're building full stack. We're in front of, we're in charge of the front end and the backend. But when you join your next company, you might only focus on one. Cool. All right, so folks said it right.

It's the form. It's how we do our posting. So if we were to fill out this form, somebody get, we did have baby Keem on here. So let's do baby Keem again. So baby Keem, we're gonna add, grab their birth name. Boom. And so I'm gonna go ahead and I'm gonna enter it in here. I'm gonna hit submit. Boom. As soon as I click submit, I have submitted what type of request to the server? I submitted what kind of requests to the server? Post, yeah, I made a post request. And so our application is set up to hear that post request by submitting the form. We made a post request to the server. Our server is set up to hear that POST request.

Now, how many POST requests could our API be set up to hear? Remember, the API is the code that's listening for that request. How many POST requests could it be set up to hear? As many as we want it. So how do we differentiate between all the different forms? What if I had 10 different forms on this page? How would I know what POST I was listening for? Different routes, exactly. And the route or the form comes from where? Do we remember this from last class? The route for the form comes from where? The action, exactly, the action. So, on this form, if we go back and look, come on, let's go to our, I'm gonna do it right here. Inspect, if we look at this form, We can see this form has an action of add wrapper. So I'm gonna listen to a post that's coming from the add wrapper form, right?

Add wrapper is the action. I'm gonna be listening for a post from that form. I could have a dozen different forms all with different actions that my API could hear and listen for. So we submitted a form, that request made it to the server. It was a post request. Our API code heard that post request. It had the correct route. And once it heard that request, it did some things. The first thing it did is it went to the database. It found our wrappers collection, right? Found our wrappers collection and it inserted one new collection. It inserted one new collection. And where did the data for this new document come from? We inserted a new document into this wrappers collection. Where did the data for this new document come from?

Yeah, from the form, all the stuff that was in this form, all the stuff that was in this form gets sent with the request. We saw that massive request body that came through and a part of that request body was all the information that was filled in in this form. And so we were able to take all of that data to create a new document in our collection, right? And then once we had put that new document in our collection, what did we do? We responded, right? We responded. We said, hey. We responded and said, hey. Everything went okay. Exactly what you asked to happen, happened, and then we refreshed, exactly, I see you chat. Then we refreshed. And when we refreshed, we made a what request? We made a new what kind of request? We made a new get request. That get request went to the database.

This time, however, there was a new document inside of that collection. So when we got all this data and we put it into the EJS file, the EJS file had to create one more LI, which spit out new HTML. That HTML had that additional LI, and that's what we respond with. And that's why we're able to see babykeem show up. It was two steps. It was a post that put that document into the wrapper's collection in our database, and then it was a get that went back to the database to get all that data, plug it into EJS, spit out HTML, and respond with that HTML. It's so fast. Well, it is. It's wild. It's mind-blowing. So Zilby said, does EJS re-render on every refresh? Yes, the way we have it set up right now. It's it's we're refreshing on everything. We're re-rendering on everything Eventually, we won't we'll do it slightly different ways. But yeah for now it is Cool React will be a way that we might handle some things differently there are ways to do things asynchronously that we haven't covered yet.

But for now, I want the raw request marinating in your brain. All right. So we've created, we've read it. We're going to skip update because we haven't talked about that. Then we're going to talk about delete. So delete. What are we doing for deleting here? What's the deleting thing here? Prod by Moose said, is React better than EGS? You're never really gonna hear me say something is better than something else. It's very rare that I'm gonna say one thing is better than something else because they're different tools for different jobs, right? Right, they're different tools for different jobs. And so I like putting as many tools on my tool belt as possible, but I'm never gonna look at a hammer and say, you know what, hammer, you're better than my screwdriver. Right? It's just not something that would be like, I would like, I'm not gonna be like, oh, I might prefer my hammer, right?

I might prefer my hammer. I'm not gonna tell my hammer that it's better than my screwdriver, right? So I think that the better is kind of interesting there. We will use tools that solve more and more of our problems. Right now, there's not a lot of stuff that's really kind of updating. there's really nothing we're gonna call state eventually other than these likes. Well, it's not something we really need to bring react into the mix yet. But once we get to applications, say like Facebook that have all these different things that are happening, your number of followers are going up, your likes are going up, people are logging in and out. Like once you have to keep track of all these little changes, there are things that can make your life a lot easier and react is one of those things. So we'll get to it eventually, but for now, no. All right, the deleting. Yes, we said the deleting was clicking the trash can right when we click the trash can there's some stuff that happens What here is that click? Yeah, our smurf hanging out on the block by himself I I really, new people that join us are just screwed sometimes. Some of the references we throw out there if you're new or a little wild, I understand. Yeah, so our Smurf is just sitting out there.

It's our client-side JavaScript. It's our event listener. Our event listener's just chilling on that trash can, waiting to be clicked. And that client-side JavaScript, here's that click and it makes a what? What what what what is the only thing that we've seen client-side that can make a request to a server? The only thing that we've done that we've used time and time again is a what? Chat stop trying to make fetch happen. It is a fetch though It is a fetch right? We click that trashcan and in the client-side JavaScript is a fetch request that makes its way to our server right and That request leaves the client side and makes it to our server. The API is set up to hear that request. There's a delete. We gave it a specific route so we know we're listening to the right delete. And what that's going to do is that request is gonna be sent to our database. We're gonna look inside of our wrappers collection and we are going to delete one of the posts or one of the documents from the collection, all right? We heard the delete requests, we wrote the code that went to the database, found the document, deleted it, and then what do we do?

What do we do after we delete the document from the collection? We respond, saying everything went okay, and then we refresh. And when we refresh, that makes a new get request. That get request goes to the database. It finds the wrappers collection. However, this time when it goes to the wrappers collection, it's missing the document that we deleted. And we pass this stuff into the EJS, which spits out HTML, and the HTML is short and a lie that we respond with. Solars, hey, welcome. Glad you're joining us. Cool, cool, cool, cool, cool, cool, cool, cool. Someone said, how does it know what to delete? That was interesting. Good question. How does it know what to delete? When we click the trashcan, when we click the trashcan, we're making a fetch.

But remember the fetches that you did, remember the fetches that you did with your APIs, right? You can always send information with a fetch. And so what we're able to do is we're able to send some information along with the fetch. And what we did is we sent Baby Keem along with the fetch. And so when our API was trying to do its deleting, it actually went to the database and found the document that was baby keem and deleted it because we with our fetch we sent the information that we wanted to be deleted and so it had to go find that document that had that name to delete it so we're going to see that like i said we're going to take a look at um all the code today i want to really make sure that we understand what's happening remember this class and last class is It's all about the like the why not the nitty gritty. Remember, we're committing to using, understanding, and then building. So we're using, right? We're using all these pieces and maybe through a little bit of that using, we'll start to understand a little bit and then we'll be eventually able to build with it. When we come back, we'll be building these apps from scratch. One of the very first apps we're gonna build is a to-do list from scratch. We'll handle all the client side code, all the server side code, all of the routes, our API, everything from scratch. So tonight's not that night. We're trying to understand what's happening underneath the hood. And if we can walk away understanding what's happening underneath the hood, we're in a good spot. So the client side is doing the fetch and the backend is doing the delete.

Yes, Pi, exactly. Cool. Alrighty, so we talked about the creating, the reading, the deleting, but what's the thing doing the updating in this application? The likes, yeah. Each one of our wrappers has a certain number of likes associated with its document. And so what we're doing here is when somebody clicks on the thumbs up, right? When we click on the thumbs up, that client side JavaScript hears the click and it makes a fetch, right? And this time the fetch is also sending along not only the information about the person, but the number of likes. So all that data is sent as part of the fetch right all that data gets sent as part of the fetch and So we make that request the the put request or the update request to our server There's a part of our API that's set up for that request and it's gonna go to our database It's gonna find the document that had that match of baby Keem their birth name and the zero likes And it's going to take that number of likes and add one to it so that it goes from zero to one Then what's it going to do It's going to respond It's going to respond. And it's going to respond saying everything went okay. And then it's going to refresh. And this time when it refreshes, it's gonna make a get request to the server. It's gonna go to the database, find the collections, find the documents inside the collections. We're gonna notice that one collection is no longer zero. So it is now one, all that data gets put into the EJS, baby keems, li, the update now is there's not zero, it's one, that's HTML that has the one, and we respond.

And we respond. How are respond and refresh different? Respond is something that the server does, Refreshing is something that the client does. So the client can refresh, like when you refresh the page, the client can do that. The server is just listening to requests and sending responses. Somebody said, but Leon, that's not secure. It's not, we're here to learn. We're not here to write performance secure code yet. Yeah. The reason why this wouldn't be secure or is because we're yoinking stuff from the DOM, right? Right now we're yoinking stuff from the DOM, but we can always just come in and edit the DOM, right? Cool. All right, so we could do that like yoinking, right? Where we change the stuff that's happening, right? And that could impact.

I don't know if that's how I have it set up right now, but there is ways to do that. But we're not here to worry about that yet. That's some record card adjusting right here. Yeah, it is. How does the API know who is liking the wrapper? It doesn't know right now. So right now it doesn't matter. It doesn't know who's liking it at all. Eventually we'll have logged in users and we'll be able to tell who is liking what. But for right now, anybody that had access to this application and whose IP address was listed on my MongoDB instance could do these updating. Yep. What if we want to delete from an API that isn't ours? Well, hopefully we can't do that. Hopefully we can't do that. So a unique IP address can only like each name once.

No, no, we don't have any of that stuff built up yet right now. Um, right now the, the way that MongoDB works is that you can either set it so that only your IP address is able to update stuff, or you can set it to multiple IP addresses, or you can whitelist it so that any IP address can make changes, uh, and this makes a lot of sense because we are going to put our code on, uh, let's say like a Heroku server, right? We're gonna put all of our code on a Heroku server. Do we want any other server besides that Heroku server to be able to talk to our MongoDB database? Do we want any other server besides the Heroku server to be able to talk to our database? No. So we would just whitelist the Heroku server's IP address, and then that way we don't have to ever worry about somebody else accessing our database. Mm-hmm Cool How does Heroku defend against viruses no idea that's why we use Heroku though We could roll our own metal right back in the day instead of paying for somebody's server, right? Let's talk about this is a really great question Why would we put our code on Heroku? Let's talk about it So back in the day one of my first companies What I did is I had a server drilled into the cement Drilled into the cement right it was literally drilled like there was like a computer connected to the internet That was drilled into the cement so that somebody couldn't like steal it right and That server served up the the website or the application sorry and And what were the downsides of me rolling my own metal where I had like my server cemented into the ground? What were some of the downsides of that? What if it floods? Great question. If it flooded, my server would go down. If the hard drive failed in the middle of the night, what did I have to go do?

I would have to get up, get my ass all the way back to the office, pull out the drive, put the hard drive back in, right? What if the power went out, right? What if the power went out? Well, I better go figure out my redundant power system to bring the server back online. So back in the day, it's what we used to do. I rather pay someone to host my code so I don't have to worry about any of that, right? I don't have to worry about the power going out. I don't have to worry about a hard drive failing. I don't have to worry about, do I have a good enough ether, like a good enough internet connection, right? All that stuff I hand off to somebody else, right? And that's why I put my stuff on Heroku. Heroku handles all of that stuff, plus makes it easier for my application to scale. As I need more and more resources, is it's easier and easier to get more and more computers that can host my code, right? So that's why we'll use services like AWS, we'll use services like Heroku, we'll use Azure to host our code so that we don't have to handle all that crap. Also, what's something that's really cool about putting our code on these servers?

Well, these servers are great, they have really good connections, but they might also be closer to our users. we could have a server, let's say in Dallas or Chicago or someplace that's like equidistant to all of our users, or we could keep track of our analytics and see that like 80% of our users are in New York. Well then better, we probably should put our server in New York, right? And so a lot of these bigger companies have servers all around the world where you can put your stuff on there. So we'll talk about that much in the future where we talk about CDNs, we talk about distributing our code across multiple servers. We're not there yet, but for folks that are saying, like, Leon, why are we using Heroku? Why are we putting our code there? Well, we don't have to worry about it. It just runs and it does it all for us. Cool. All right, so we talked through the creating, the reading, the updating, and the deleting, but what I wanna do now is I wanna look at the code for each of these. I wanna look at the code for each of these. Is Heroku trustworthy? Yeah, Heroku is used by a lot of really, really big, big organizations. It's been around for a very long time.

But remember, it's just somebody else's computer. There's nothing special about the cloud. It's just somebody else's computer. Whoever you're using, AWS, Heroku, whatever it is, it's just somebody else's computer. I think somebody asked in Ask Leon, and I haven't had a chance to respond to it. They're like, do we still own our code? Yeah, you still own your code. You're just using their metal. Yep. What if they get flooded? Well, they thought through that. A lot of these big server companies put a lot of time and effort into making sure that their servers are secure because that's real money for them. If they got flooded, then they're out. So they'll put them in above the floodplain, right? They'll put their stuff above the floodplain.

They'll have redundancy. They'll have backup power systems. They'll have a lot of stuff that makes it so that when they build out a huge data center that they thought through all this stuff. I've had the privilege to be in a lot of data centers. Uh, one of my favorite is, uh, if you're from Boston, uh, one of the biggest, like one of the biggest server farms on the East coast is underneath the Macy's in downtown Boston and whenever I would walk by the Macy's, there are always these like Debo looking like security guards, like fully strapped up, like they, they, They got, they, they had like, not only like, like full, like full, like AR platforms, like hanging in front of them, like just, just strapped up. And so I was always like, damn, like people really be out here shoplifting from Macy's and, uh, they, they, they, I don't know, I don't know why they need these Depot security guards, but then I found out that they're actually protecting the data center that's underneath Macy's there, they, they, They weren't there to protect Macy's. They were to protect the servers that are below the Macy's, which I thought was just like, it was pretty funny. And if you actually look it up on Google Earth, you'll see like all these redundant power systems on the roof and stuff. It's pretty wild. Yeah. Yeah. Oh, I guess it gets pretty spicy. The links don't go through to protect the data and the servers. Yeah. Protect Macy's at all costs.

All right. All right, so what I wanna do now is I wanna look through each one of these, see the code underneath of it, look at all the accessories that make it run, and then we should be in a really good spot for you to maybe build an app or two on your own over break. All right, so here we wanna talk about the reading. I think this is the easiest one to start with. It combines a lot of stuff that we need to know. So we want to do the reading. So, I want to go ahead and refresh the page, right? So, I refresh the page. What happens when I refresh the page? Well, from the client, right, a request makes it to a server. And we have some code running on our server, which we call our API, that hears that request, And so we'll see something like app.get and we'll have the route. In this case, since we're on the main route, localhost 2121, the default route is that forward slash the root route. Then once we hear that request, there are steps that we're going to have pre-written for what should happen. And the first thing that's gonna happen is we're going to go to our database, we're going to find our collection called wrappers, and once we go to that collection, we're going to find all the documents, right? So that request leaves our server and it goes to our MongoDB Atlas database.

And on that database, there is a wrappers collection. And inside that wrappers collection, right? Inside that wrappers collection is a bunch of documents, right? A bunch of documents. And what we're gonna do is we're gonna get all of these documents, but each one of these documents is a what chat? Each one of these documents is a what? Is an object. And what's the only thing that we know that can hold all these objects? Not the only, well, maybe what we know. An array. So what we do is we say, you know what? Turn all this into an array. And so we get all of these documents back and we put them into an array. So we have this array of objects, right? We have this array of objects.

And once we have this array of objects, where are we gonna pass this array of objects to? Where are we gonna pass this array of objects to? Yeah, we're gonna pass it into our EJS. and our EJS is gonna take all of these objects. The EJS is gonna loop through them, take the data out, plug it into an LI, bill out all these LIs, and when it's done rendering, what does EJS spit out? When the EJS is done rendering, what does it spit out? Yeah, it spits out HTML. So it spits out some HTML, and the last thing we do with this HTML is what? What do we do with it? Yeah, we respond with it. We respond with this HTML back to the client so that we can see the lovely page that we see here. Cool. Let's go ahead and take a look at the code that powers that get request as part of our API. All right, so here it is. Here's the code, right?

Here's the code. Don't stress about it. Let's take a look. We can see, if we just go ahead and delete this for a second, we can see the normal structure, right? We can see the structure. All right, app.git. This is Express doing the heavy lifting for us, right? Express is doing the heavy lifting for us. It heard the get request, and when it hears the get request, it fires this function. The two things that it passes into this function is everything that it knows about the request and everything that it knows about the, well, eventually everything it'll know about the response. So we hear that get and we fire this function, just like click events where we heard the event and we did the following function. This is the exact same thing here. So what do we do when we hear that get request? Well, we decided to go to our database. I'm gonna show how we connected to our database in a little bit later tonight.

We go to our database, we find the collections wrappers. Let's take a look at our database and let's look at the collection of wrappers. All right, let's take a look. If we look at our database, here's our database. Here's our collection of wrappers. and we can see all of the objects or documents that are inside of this wrappers collection. So what we decided to do, what we decided to do, what we decided to do is find all those documents. And once we had all those documents, all of those objects, right? Right? all of those objects, we turned them into an array. Right? So now we're chilling with an array of objects. And if we know anything about how like we get responses back from stuff, we know that this is probably a promise. And then this then is going to run once this is done doing its job. Remember, this is something that's happening asynchronously.

It has to go to a whole other database out there on the internet. Find our MongoDB Atlas like database, find the wrappers collection, find all the documents, turn them into an array and respond with all that data. Well, all that data, that array of objects is gonna be passed into the word data. So wherever I see, right, wherever I see data is really my array of objects. It's all it is. So wherever I see data, I see data down here. It's really this array of objects that I got back from the database, right? It's just all the objects that I got back, right? Now, what am I eventually going to do with this data? I got all this data back from the MongoDB database. I got all of these documents, all these individual wrappers. is I got back from the MongoDB database, what am I gonna do with all of these objects that are sitting in my array? Well, the beautiful thing about Express is we had a send file method, we had a JSON method, we have also a render method. And so we can tell it to render our EJS using this data. So we're gonna pass this data into my EJS template.

What is gonna be the name of my data? What's the name I'm gonna use to represent all this data inside of my EJS template? I'm gonna look inside this EJS template and it's gonna be represented by a name. Yeah, here we go, info. Info is the name of all the data I'm gonna pass in, all of my wrappers, all of those objects. So wherever I see info, it's really that array of objects. It's really all the wrappers, right? And so let's go ahead and take a look inside of our EJS and see if we can see where we're using that info. All right, here we go. We have this thing that looks like a for loop, but it's the EJS syntax, right? The loop, and so we know it's gonna loop through and each time it loops through, it's gonna create an LI. And the cool thing is that Info is holding all of our documents. So let's go and take a look at our database. There are one, two, three, four, five documents that came back from this database, right? Five documents that came back.

So how many times is this loop going to run? It's gonna run five times. If there were five documents in our database, it's gonna run five times. And each time, what we're gonna do is we're gonna pull off the information for each one of those objects. So what it really was, it was an array. It was an array that had objects in it. And each one of those objects has a stage name. It has a birth name and it has a number of likes, right? There is just a bunch of objects that have the same stuff. Age name, birth name, likes. Age name, birth name, likes, right? It's just an array full of those objects, right? So the very first time this runs, info will be zero. Info will be zero. And so we're going to use the square bracket notation to go ahead and grab this first object out of the array.

We can grab the stage name off of it, the birth name and the likes. And so if we look at our application, we can see that that was 21 Savage, their birth name and one like. Then this ran again, but now I is one. And so instead of it grabbing this one, it goes and grabs the next object and we pull off the stage name, the birth name and the likes, which if we look at it was chance the rapper, please say the rapper, their birth name and one. Then it's gonna run again and I is gonna be two. And instead of it grabbing this one or this one, it's going to grab the next one. And we're going to grab the stage name, the birth name, and the likes. And we're going to plug those in. And that's how we wind up getting Polo G, their birth name and four. And it's going to do this two more times, grabbing the content out of those objects to build out this LI. And once this is all said and done, And once we have fully rendered our EJS, what do we wind up with? It spits out some HTML and we respond with that HTML. Right, we respond with that HTML and that is how we are able to see all of these wrappers that were inside of our database. That's how we're able to see them here on the client side. This was not hard-coded.

This is, we went and got data from the database. We plugged it into a template, that template spit out HTML, and we respond with the HTML that we're seeing now. Every single time, right? Every single time that we refresh, It's doing that same process again. Every single time I hit enter, it's doing that same process again. Your code on GitHub, your code on GitHub, why do you, why do the legs start at negative one? I think you're maybe referring to something I did here that I took out just because I think it's, it's just a little extra. I'm telling you Express makes our lives so much easier. Using MongoDB is so amazing because it just makes our lives easier. Right now, are my wrappers sorted in any way? No. What's something that we might want to sort them by? What's something that we might want to sort them by? Likes? Yeah, I think likes make the most sense here.

We don't have, we don't have somebody said age. We don't have their age here, right? We have their likes though. So, uh, instead of having, instead of having to figure out some big brain query, you're ready for this dot sort. And then we tell it what we want to sort by just an object that we pass in. So I'll say likes, and do I want to sort in ascending, which will be one or descending, which would be negative one. So I want to sort in descending from biggest to smallest or greatest to least. Uh, and so I just plugged that in. I got to restart my server. Please save the server and let's go back and refresh. And now our stuff is sorted. Yes, right? Because what happened now is when it went to the database, it still went to the database, it still found all the wrappers, it still found all the documents, but it decided to sort those documents for us from the likes from greatest to least before it handed us them in the array. Right? And so like, it's just plain language, right?

It's just plain language. And so that's why I love this. It's like, you start to think through all the things that you might wanna do, and you find time and time again, and it's pretty readable the things that you wanna do. What does negative one mean here? It's just how do you wanna sort it? One would be, here, let me show you. So negative one, we can see it goes from four to one, one, one but if I change this to just regular one, it's gonna go the other way. So let me stop and restart my server. And now it's gonna go the other way when I refresh. So now it's going from one to four, right? So it's descending versus ascending. So I wanted it to descend. So I put negative one there. All right. Leon, how will we Google something like this?

Let's try it. MongoDB sort. So this is kind of like MongoDB telling you how to do it right off the jump. I don't know, there's a bunch here. Let's just take a look at it. Tells us sort, this is doing aggregate though. So let's see if there's something just regular. I'll see where it says sort. I don't know how I'll see where it says sort. So I'd go back. Oh, there we go. Super simple. Sort, field name, and then order. And it's telling us here that you can do one or minus one. So that was what, I don't know, less than a minute to find it, right?

And so notice what I did, like the docs didn't really help me, right? So I was like, I don't know, this is, you're using a lot of big words here, it's too complicated. So I just went back right you don't have to You don't have to always do the that like and I just went down the list. I was like, all right This one seems okay. Let's see and then oh right there. Boom sort All right read a little bit more above and below it and saw one minus one That's it So, I think a lot of folks they they spend too much time Like they spend too much time like when you see something like this I'm not gonna spend my time. Look what no use a lot of big words use a lot of not for me And I go back. I think that's one of the Leon what's the difference between senior and entry level? Yeah, that's it right there. I Know when to move on I know what I'm being disrespected and I move on I don't I don't stick it out All right, so we did the get. Let's take a look at the post, but we're gonna do that after we come back from our break. We have a seven minute break, thanks to MusicCR2. CR2. So we're going to put seven minutes on the clock here. When we come back, we're going to see the post, the delete, and finally the put.

And then we're going to take a look at all this other stuff, like how I'm connecting to the database, what the heck all this stuff means. And then we'll end for the evening and go into a beautiful two-week break. All right, let's go ahead and put seven minutes on the clock here. We talked about the creating, sorry, the reading. Let's talk about the creating. So if we look, we're able to enter in a rapper's name, stage name, and birth name, and submit, right? Right? Right, and submit. And when we submit it, let's get myself a little blank slot here. When we submit it, we were able to make a request from our client side. That request made it to our server. That server had some code running on it that we call our API, and that API was set up to hear the post. Now, the route for that post came from the action on the form which we'll see again in a second and when it heard that that correct action and it was on the post it did some stuff. The very first thing that it did is it went to our database it found the wrappers collection and in that wrappers collection we added a new document with the new info that came along with the request from the form, all right? Once we added that new document, we inserted that document into the wrappers collection, the only thing that we did was we responded okay and asked for the page to refresh.

and it was the refreshing that made the get request that eventually found its way to the wrappers collection and saw the new document that we just created, put that document into the EJS and that's how we were able to see the updating, or sorry, the addition of the new wrapper. But all that creating did was put that new document in our database. We had to still do another get request to be able to see it. All right. So if we look, here is our post. We know that the post request is coming from this form. If we look, this form, when it submits, it has an action of add wrapper. So our API is set up to hear a post from that add wrapper route. Cool, when it hears that add wrapper route, that post, it runs this code. And all we're doing is we're going to the database, we're finding the wrappers collection, and we're inserting a new document into that collection. I love Express because if I want to insert a new document, it's just insert one, and I've inserted a new document. What I'm going to do is I'm creating the document that I want to put into that collection. If we look, if we look at our documents that are inside the collection, we'll see that they have a stage name, a birth name, and a number of likes. Stage name, birth name, and likes came from us. We told it what to put in the database, and we see that here.

we say stage name, birth name, and likes. We are hard coding what those properties are going to be in the document, in our collection, in our database. Now, the value that each of those had, right? We saw that the value will be different depending on what was entered into the form. In the Polo G instance, we entered in Polo G as the stage name, and we entered in their birth name into the birth name slot and we clicked submit. That request made its way to our server, and we were able to pull off Polo G and able to pull off the birth name by looking at the request that came when we submitted the form. Because when we submit that form, We send a big old request and at the very bottom of that request is a request a body that comes From the form and we're gonna be able to see in that request body Properties that have the name that we describe here. Whatever we call this here is what shows up on the body So let's see that one more time I know we saw it last class but I want to show you that it really is the request that is coming through that has it so I I'm going to console log the whole request, right? So we can see it. Let's console log the whole request. Let's start and start our server again. And let's go ahead and enter in a new wrapper. Somebody give me another wrapper. Actually, I already have one pulled up, RZA. Let's go ahead and do RZA.

RZA, the JIZZLE. All right, there we go Cool Boom we're gonna submit Great, I submit it Right. I submit it right I submit it And if we go back and look Look at all this crap that we console logged as the request. When we submitted that form, when we submitted that form, right? When we submitted that form, all this crap gets sent with that request. All this stuff gets sent with the request. And we're gonna notice that there's also this request body. The stage name property and the birth name property came from the form. If we look the form has a name of stage name, right? This name Is being used here this birth name is being used here Whatever the user entered The stage name from the body was RZA and the birth name from the body was Robert Right, so we're able to say, you know what? Hey with this request give me the body and give me the stage name that's part of the body, give me the birth name that's part of the body, right? And so that's why when we look at our server, we are saying request.body.stage name, grabbing RZA out of the request that was sent, right? Grabbing Robert out of the request that was sent. It's all coming from the form because it's all coming along with the request. Boom.

All right, let's get rid of this console log because I don't want to have to keep console logging in this every single time. All right, so now we got the stage name from the form. We got the birth name from the form and we decided to also hard code a number of likes. And what winds up happening, what winds up happening is we insert this object as the document into our wrappers collection. So if we go and look at our wrappers collection right now, we expect to see a new document that has the stage name of RZA, the birth name of Robert and the likes of zero that we hard-coded. We hard-coded the number of likes, right? That's what we expect to go see. So let's go look at our database here. Let's refresh our collection. And we should see in this collection at the bottom, yes. There's a stage name with the value of RZA, birth name with the value of Robert, and likes with the value of zero. We literally insert this document, right? We inserted this document into the wrapper's collection. Cool. That's how the one guy was everyone's friend on Myspace.

Exactly. Whenever you created a new Myspace account, there was a friends. There was a friends array, right? There was a friends array and that array always started off with Tom, right? It always started off with Tom. And so whenever you created a new MySpace account, Tom was already hard-coded. That's exactly how it worked. You think I'm joking? This is exactly what was happening on their backend, right? Was that every time we created a new user, it was hard coded to have a friends array that had Tom already in it. That's it. Cool. So once we're done adding that new document, right? Now, once we are done adding that new document to the wrappers collection, our then fires, we print to the console that we've added a wrapper just so that we can see it in our terminal here. And then what's the last thing we do?

We tell Express to respond with a what? We tell Express to respond with a what? We could respond with a send file. We could respond with a JSON. We could respond with a rendering of EJS, but we told it to respond with a refresh. Beautiful. And when we refresh, when we refresh, that triggers a new get, that get goes to our wrappers collection and now there is a new document in our wrappers collection that has RZA in it. Cool. Let's talk about the deleting. All right, the deleting. When we go ahead, let's get rid of RZA for now, right? When we click on this trash can, what hears that click? The Smurf, and where does that Smurf reside? Where does the Smurf reside, where does the Smurf reside? Yeah, it's our client-side JavaScript.

So if we're gonna start by looking at what happens, We need to start there. So let's go to our public file, main.js. Here is our client-side JavaScript. We can see that we have, we grab all of the trash cans. We add an event listener to all the trash cans. And whenever we click a trash can, we're gonna fire the delete wrapper function. So let's go down and look at this delete wrapper function and what it's going to do. When we click on the delete wrapper function, it's going to grab some text. It's going to grab the name that is next to it, like the stage name, and the birth name that is next to that trash can. Let's add back RZA just so we can delete them. All right, so let's go ahead and put Let's grab their birth name. Boom, we submitted our POST request, we made a GET request, and now we're seeing them here. When I click this trashcan, that click event fires, we fire the DELETEWRAPPER function, and the first thing we do is we say, hey, this, aka the thing we just clicked on, go up to its parent, find the first child node, and find the text inside of it? What the heck? Eventually we'll use query selector and stuff for that.

But I wanna see this right here. So let's take a look. All right. We just clicked on the trash can. Let's go ahead and take a look here in the actual DOM. Inspect, here's the actual trash can. We said to go up to the what? We said to go up to the parent, right? So if we just, if we click here, if we click on the trash can, we go up to the parent, which is the LI, and then we're gonna look at the child node. Let's take a look. It says go up to the parent, which is the LI, and then go to the child node. And so if we look, here is the child node that has RZA in it. Then we're gonna look at the other child node and it has Robert Fitzgerald Diggs in it. So we grabbed RZA and Robert out of the DOM. Out of the DOM, we literally grabbed it out of the DOM Because how do we know which trash can we're clicking on?

How do we know what trash can we're clicking on? We could be clicking on Polo G's, we could be clicking on Chance the Rappers. How do we know which trash can we're clicking on? So we have to go starting from the trash can we clicked on. So we start here. We went up to the LI, which was the parent node. And then we grabbed RZA and we grabbed Robert. Why do we need RZA and Robert? What are we going to do with RZA and Robert? Why are we grabbing these out of the DOM? Yeah, because we're eventually going to search the database that has a document of RZA and Robert matching. And when we find that document, we're going to delete it. Right? So right now, if there are multiple RZA's, It's just going to delete the first one, right? In the future, we won't use, we won't use the stuff that's here.

What do we know about each document? What do we know about each document that's created? They all have these unique IDs. See all these unique IDs that are being created. Eventually we'll just use those unique IDs, but we're not there yet. We're grabbing stuff from the DOM. We're being wild and fast with it here. And so we went, we clicked on the trash can, we went up to the LI and we grabbed the first child node and we grabbed RZA out of it. Then we went, same thing again, from the trash can to the LI to the second, the third node and we grabbed the text that's inside of it, right? Now, could we have done query selector? Could we have used IDs? Could we have used classes? Yes, yes to all of those things. But I want to show you the wild way first. And when we come back from break, I'll show you the cleaner way.

All right, this is in a lot of code bases. I've seen this a lot. And so I need you to know what it is. Now, some people are saying, what the heck are child nodes? When we are looking at this stuff here, when I do this and I'm looking at this, is this HTML? Is that HTML? Nope, that's the DOM. And the DOM is made up of what? The DOM is made up of nodes. And all those nodes are connected in weird ways. And so it's not 0, 1, 2, like you would expect. It's actually one, three, five, seven. It skips because there are things here that aren't just the text. There are some things that make up the nodes that are gonna be the zero where the text is the one. And so there's things like spaces that could throw this off.

There are things like carriage returns that could throw this off. There's a lot of stuff in here like the entering. Look, look, this is on a different line. This is on a different line. That's a carriage return. That's an enter that might be its own node in the DOM. Right? That like going to the next line might be its own thing in the DOM, right? So the child nodes are a little weird because it's not zero one. It's because we're not really dealing with HTML. We're dealing with nodes in the DOM. Okay, so let that wash over you. It's okay. We'll eventually use query selector. We'll eventually use IDs and other things.

But for right now all you need to know Don't remember tonight's not about understanding the code. It's about seeing it. It's about believing Right It's about believing. So what are we doing here? Fuck all that Fuck all that when we click when we click When we click the trash can what are we doing? What do we need to do? When we click the trash can, we need to grab Rizza and Robert and send that with our request to the database, right, to the server, I mean. And so when we click the trash can, we need to grab Rizza, we need to grab Robert, right, and we need to send that as part of our request. And if we look at our code, That's exactly what we're doing. We are making a fetch that is a delete request and we are passing along as part of this request another body and in that body we have RZA's name and Robert, their birth name, right? we're plugging that in, we grabbed it from the DOM and we're plugging it in so that when we make our request, when we make our request to the server, we can see their stage name, we can see their birth name and we can use it, right? We can use it so that we can eventually go to the database and delete that document. Let's actually go ahead and make sure we console log this request. So we're inside the delete. Let's console log this request.

Cool. Let's restart our server. All right. Let's refresh the page to make sure we're all good. And I'm gonna click this trashcan next to RZA. Let's go and look at our server. Look at all this crap that came along with that fetch request, right? Look at all this crap that came along with the fetch request, but look what we have this time with that request came a new Request body Is this where data attributes come in handy yes, that's eventually where data actually just can come in handy, right? Look at it, look at this request body. There is a stage name S property that has the value of RZA and a birth name S property, right? That has the name of Robert Fitzgerald Diggs. That came, that came with the fetch from our delete. look we made a fetch that was a delete request and we sent along with it a body that had RZA from the DOM and Robert from the DOM plugged into it so we grabbed all that and we sent it along with the request right we sent it along with the request and since we had all that information as part of the request, we could use it. We could use it to our advantage. So we said, all right, let's go to our database.

Let's go to our wrappers collection. Let's delete one document from that collection and we're gonna delete the document that has the stage name of what right now is request.body.stage name S. what is holding, what is request.body.stageNameS holding? It's holding RZA. So it's as though we plugged in RZA right here, right? It's as though we plugged it in. And so we're going to look for a document inside of our collection that had the stage name of RZA. And when you find the document that has the stage name of RZA, what are we gonna do to it? We're gonna delete that document. We're gonna delete that document. And when we're done deleting that document, we're gonna respond back to the fetch. We're gonna respond back to the fetch saying, hey, we deleted that wrapper and we handle it. You need me to delete that wrapper? I handled it, right? I got you.

And so that fetch, here's the response and what the heck do we do? What the heck do we do after we get the response that we deleted the wrapper from the database? we refresh, which is going to trigger a new get request. This get request is going to go to the database, find the wrappers, find all the documents for each wrapper, but this time it is missing one. RZA is now gone. And so when we spit out our HTML from the EGS, we no longer have them. So if we step back and we think about what happened, right? If we think about what happened, on the client side, we had a wrapper called RZA, and there was a trashcan next to them. We clicked the trashcan, and when we clicked the trashcan, we grabbed RZA's name, and we made a fetch to our server, right? And part of that request, right? Part of that request that went to our server was to bring this name along with it, right? To bring that name along with it. And then when we looked inside of our app.delete, what we're able to do is go to our database. We're able to go to our wrappers collection, right? And when we're in that collection, we can, we can search.

We can look through that collection. We can look through that collection. We can, we can scroll through. We're looking for it. We're looking for it. We're looking for it. Aha. I found it. I found it. Here it is. Delete it. Delete one, delete it. And once we delete it, what we're gonna tell to have happen, right? Once we delete it, what we're gonna tell to have happen is we're just gonna respond. That fetch is gonna hear the response and reload the page.

And when it reloads the page, that document no longer exists in our collection. If I refresh, RZA is gone, no longer a document in our collection. Right, no longer a document in our collection. So when that git comes through, it's missing something. Cool. All right. Why are we using async await on the client side, but not server side? Because it's too much extra code that throws people off when they're first learning about the backend. Eventually our backend code will also be async await. It's not yet, because it just adds too much complexity to it. There, it's not a delete wrapper folder. This delete wrapper is how, how can we differentiate between the different deletes? Right here, we have a fetch that is a delete fetch. Like it's a delete request. How do we differentiate between this delete request and any other delete?

Well, it's the route of delete wrapper. I could call this something different here, but if I called this something different, then on my server side, I would actually have to call this something different as well. It's just the route. We are using fetch because we don't know which trash can we were pressing. Well, the only way that we can make a request from the client side based on a click is to make a fetch. That's the only thing we've ever seen so far, right? The only thing that we've ever been able to use from our client side JavaScript to make a request was fetch. That's why we're using it. Are there other ways? Of course, of course there are. All right. Last one, last one is the updating. Now the cool thing about updating is that updating and deleting are going to follow the same process, right? Update and delete are gonna follow the same process. What if there are two wrappers with the same name?

Right now, it would just delete the first one in our database that had that name. We'll eventually have things that make it so that we can have unique wrappers, but that's too much to put on the table when we're just learning. Big pictures make sense, but it's a lot of moving pieces. is exactly, that's why I need you to get the big picture tonight. I don't care if you understand like exactly what is happening right here. That doesn't matter to me. What I do care about is that you know that when we clicked on a trash can, we grabbed this info to send with our request to the server and we use that info to find the document to delete from our database. I don't care how I got the info. I just need you to understand that we sent a request with that info and we heard that request and went to the database to delete something based off of that. Why is there an S after stage name? As just a, so if you're, when you're coming back and you're looking through this code, you'll see that it's a little bit different and hopefully that little bit difference makes you go, oh, these two pieces of data are connected. Erica said, what happens if you go to Localhost 2121 slash delete wrapper. What type of request would that be? If I went to localhost 2121 slash delete wrapper, what type of request would that be? A get request.

All right, so let's go ahead and take a look at our server. Is there a get request for that route? There's a get request for the default route. This is a POST, this is a PUT, this is a DELETE. Are there any routes here that would be listening for that GET request? Nah. 404. 404. Cool. All right, last one. Last one and then we're going to look at some of the other glue that makes this work Now once again Do I like here? Let's just take a look at it real quick. Remember you're gonna you're gonna do Leon how dare you show me this code, right? You're gonna do Right, that's gonna be your you're gonna be your your reactions. Just go right This is a this is how we do our update request or our puts now Do I have this memorized?

The disrespect. Do I have this memorized? Hell no. I've done it a lot, so maybe I could type it out, but what I really have is just like templates on templates, snippets on snippets that I can pull when I need to do something, right? So let's think about updating. What's the only thing that we're updating in this application? The likes, the likes. And so when I click on the thumb next to Polo G, it's almost the exact same thing that had to happen with the delete, except we're telling it to make a different kind of request. right? When we click on this thumbs up, we need to grab the name, the stage name, the birth name, and the number of likes and take all this data and send it with our request to the server. Now our server is going to be set up to hear that request, right? We set up to hear that request. So it's gonna be an app.put. And when it hears that request, what are we gonna do with this data? We have this stage name, birth name, and number of legs that were sent.

What are we gonna do with this information? We send it all to the server. What are we gonna do? Ah, yes. We're gonna search the database for a match. We're gonna find a document in our database that has the name of Polo G, the birth name of Taurus, and the likes of four. When I find that match, what am I going to do? When I find that match in that document, in my database, what am I going to do? I'm gonna, whatever likes is in the database, I'm gonna add one to it. And then when I'm done doing that, I'm going to respond back saying everything went okay and that the page should what? Refresh. And once it refreshes, it'll do a normal get. However, this time when it goes to the database and it finds the likes on Polo G, it'll no longer be 4, it'll be 5. Let's do it and then take a look at it. All right, ready?

Here we go. I click the thumbs up, we could see that it went up to five. How did this work? Well, when I clicked the thumbs up, there was some client-side JavaScript that heard that click. And then just like before, we grabbed Polo G from the DOM, we grabbed their birth name from the DOM, and we grabbed the number of likes from the DOM. I then took all this info and used it to make a request to my server. Do I have a freaking clue how to do this from scratch on my own on the block by myself from memory. No, no, no. So I didn't want to hear me curse and all that. I meant to do this. No, nope, hell, fuck, no, right? No way I do this from memory. I just have this sitting on my desktop. When I need to use it, copy, paste it, boom, I'm ready to go. So what I did is I grabbed the name, their stage name, their birth name, the number of likes, and I took all this data and I sent it as a request.

Here's the route. Here's the type of request I put. I sent all that data with the request and that request made it all the way here to my put. We can tell that this is the right put because the route matches our fetch. Add one like, matches the route here. Add one like. We know our request matches our API here. Wonderful, right? Vincent, I love how you beeped no, but let the F-bomb fly because no is the worst word there. If you really think about it, if you think about it, no is dirtier than fuck. You know, come on, let's be real. Let's never let someone tell us, no, you can't be a software engineer. No, you can't learn how to code. No, you can't do it for free. Look at us fucking now building full stack web applications, understanding, getting posting, putting the leading.

Get out of here. Get out of here, all right. Like I said, if this makes any sense, like this is wild. If this makes any sense, this is wild, right? So let's see if it makes a little bit more sense. All right, so we sent all that data. We sent their stage name, their birth name, the number of likes, and we're gonna use all that information right here. The beautiful thing here is this update one is magic. It's going to find a match that has a stage name with Polo G, a birth name with Taurus, and likes with the number four. Once it finds a match in our database, right? Let's go to our database. Let's find Polo G here. All right, boom. Here we go, I found a match. Found a match of stage name Polo G, birth name Taurus, likes number four.

I found that match. When it finds the match, what is it going to do? We found the match, what are we gonna do? Set the likes to whatever the likes were, plus one. Set the legs property to whatever you passed, which was number four, plus one. So what's gonna happen is this legs property right here, let's watch it, let's refresh it. Let's refresh it. That legs property went from four to what? to five, that's it. We found the match, we went to our database, we found the rapper's collection, we passed in all this info to find the right document in that collection, find the stage name of Polo G, the birth name of Taurus, the likes of four. When you find that document, when you find that document, set the likes property to whatever this was, which was four plus one. There's some other stuff here, let's skip that for a second. And then we respond, we respond, right? We say that we added a like, right? We added a like, and if we look at our main.js, once we get that response, what the heck do we do?

We refresh and when we go and get a like, right? We go and get the new data, right? And when we go and get the new data, that new data has a legs property of five this time. And so that get goes to the database, finds all the documents, pipes them into the EJS, The EJS spits out HTML. The HTML this time now has five. Now, there's a bunch of other stuff here that we're not really using right now. What if there were multiple documents in our database that had the same stage name, same birth name, and same number of likes? Well, we could go ahead and say, All right, well, in descending order, grab the first match and just update that one. Also, what if we send a request to find something in our database that didn't exist? Well, there's this property of upsert where if it doesn't exist, if this is true, it'll just go ahead and create it. It's a really wild thing. You don't have to use it. I'm just showing you what it is, right? So you can actually get rid of this stuff, but what if we wanted to find, And if there are multiple instances, we could find the first one in descending order. If it didn't exist, we could like create that document on the fly.

It's wild stuff. There's so much more stuff here. There's so many more layers to it. There are so many other things besides set, there's set, ink, all these different things that we can learn over time, but it's not useful to worry ourselves about this stuff right now. It's just understanding the big patterns of what's happening here. Now you've seen the creating, you've seen the reading, you've seen the updating, you've seen the deleting, and it's all here folks, it's all in this code. You can build whatever the you want, right? With this stuff, because it's all here. You could take my code, you could take my code and just make it something else. It doesn't have to be wrappers, it could be anything. It's all here, you have the power, all right. Oh, we gotta, we gotta, we gotta keep that up. No. Whatever the no you want, you know? All right.

Now, we got a little bit of time left, and there's still some simple things that we need to cover that makes all this work. So if we look in the slides, I've actually broken down all the stuff you need in the slides as well. Like all the big key steps, like how do you create your project? How do you connect to your database? How do you use environment variables? All that fun stuff. So we're just gonna take a look at this stuff real quick, but it's also all here in the slides. So if we look, If we look, we've done some things here. We've required express. We've set express to the variable of app where we see app is express. Yeah, all this stuff is in Zelle's reading. You don't need me to do this. Zelle walks through all this in super detail. Here, we're setting up how we're gonna talk to our Mongo database, right? We set up our port.

and then this is something really interesting. Here are, I'm setting up my environment variables, right? Everyone always says, Leon, how do I not push my database string to GitHub? How do I not push the secrets to GitHub? Well, the way you do that is with the environment variables. So what you're gonna see here, right? What you're gonna see here is I set up some variables. I set up a database variable, a connection string variable, and a database name. Right here, this process.env.db string, this string is the string that Mongo Atlas has given me to connect to my database. If you were on Mongo Atlas, once you set everything up, you can go to your actual application and there's this connect. It'll be this connect your application and it'll give you the string that you need. It'll give you the string you need to put for your database connection. And you'll see that there is the username and the password you're gonna have to plug in. Like I said, Zelle covers this in detail, right? I know mine wolf wolf wolf mine wolf is gonna go over this in detail I'm sure so you don't want to miss their next stream.

I know they're gonna go over this right and so Make sure you've done this all reading and make sure you check out mine wolf's next stream I'll make sure that I post when they go live because I'm pretty sure the wolf packs gonna go over this, right? You plug in your password now, you're like Leon. I had so many people call like they sent me a message on They sent me a a message on Modemail saying Leon well you grab that string and you put it in your dot env file I have this new file called dot envy you put it in your dot env file But Leon you put your username and your password doesn't that mean anyone? right doesn't mean that anyone can now access your database and Yeah, technically, but what did I do on my end? that helped me a little bit. What did I do that helped me on my end? Because I pushed this up to GitHub. I pushed this up to GitHub. Yeah. Yeah, I only have my IP address registered for this application. So only if you had my IP address could you use my application. So even though I shared my env file, because I wanted you to see what an env file looks like. It's simply .env. We just do touch dot ENV you create the file and I put my database string in there and the cool thing is I Can now do? Process dot ENV and DB string.

It's just a variable coming from this file So this is the thing I got from MongoDB Right. This is the the the string I got from MongoDB I gave it a variable DB string and I'm able to plug that into my server And what I could do is in my gitignore, I could just do this, .env. Now, my env file will not be pushed to GitHub, right? Anything that I put in this env file, it could be any of my secrets, it could be any of my database, my heroic, anything that I don't want to go up to GitHub, I can put in this env file, and then anywhere in my server.js, I can just do process.env and whatever variable I give it, right? Now, I pushed it on mine so you could see everything. You will not do that in the future. In the future, you will put your .env inside your gitignore so none of this stuff gets pushed up to GitHub. Now, the cool thing is if you wanted to use Heroku with this, in your Heroku application, you can plop in the same variables. The same variables that are here in your .env file, you can put those on Heroku as well. The cool thing is I even gave you a way to do it from the command line. You can do it from their GUI or the command line. Here's the command, heroku config set dbstring equals. And so now Heroku has that DB string and I have it locally, but I didn't push it up to GitHub. Yeah. That's how we can do it.

That's how we can have secrets. That's how we can have private stuff that runs locally, but doesn't get pushed up to GitHub. And then we could also take those same secrets and put them on Heroku. So when our code is running on Heroku, who they have access to the same variables. So you'd have to do two steps. You would do it locally, hide it in your ENV file, and then also update it on Heroku's end. Cool. So that's the quick overview of ENV files, and we'll see this a lot when we come back from break. Here's everything I need to connect to my database. Do I have any idea what anything's happening here? Could I code this from scratch? No, I'm just copying and pasting it, right? I'm pretty sure I've done this enough that I could, but it doesn't matter. You're just copying and pasting it. Or better yet, you're cloning down this code and starting with my code, right?

You're just gonna start with this. This is a full API. This is full database connection. The only thing you have to do when you clone down this code, what's the only thing you have to change? What's the only thing you have to change? You just have to go into your ENV file and change this string. That's it. You change that string, you're done. And Zelle walks you through it. Mine will slash stream walk you how to do it. So all you do is change that string. I'm gonna remove my ENV file before I accidentally forget to push it, but I'm gonna put my VS code in here. There you go. So that doesn't get pushed up to GitHub because people are freaking out why was their fonts changing. Cool.

So, we have our environment variables, we're connecting to our database, we're letting Express know that we're using EJS as our templating language. We're setting up that delicious public folder so that any of our static files that get put in this public folder, they just work. We don't have to write a custom route for it. One of my favorite lines of code of all time. And then this stuff right here replaces something called body parser. These two lines of code enable us to like peek into that request object and get all the stuff we need out of that request object. Yeah. Do you need to install the .env package? Yes, you do. I think there's a mistake in the slides with that. Yeah, we're gonna need to add that here. So you should also add here NPM install.env.save. Like you're gonna need that package if you wanna use the environment variables like I did. Yeah, body parser has been deprecated. These two lines are now built into Express and all they're letting us do is like pull stuff out of the requests, right?

That's how we were able to get the request body and all that fun stuff. All right, then we have our API that we've walked through plenty enough. And the last thing is just listening. We're telling our app to listen on process.env port or our port. Now, the cool thing is we now know where the heck would it get process.env.port? Where would that come from now? Where would that come from? Where would that come from? Yeah, it would come either from our env file locally or Heroku. We would on Heroku set a port or Heroku themselves set a port, right? So this environment variable is using the environment variables that come from Heroku. Env is short for environment or environment variables. It's like the variables we need running in that environment. So we have a bunch of we have one variable that we need for this environment Which is the connection to our database But eventually this is going to this is going to be full of stuff all of our secret keys our AWS keys our Azure keys All the stuff that we're going to use will go in here so that we have a local copy, but that doesn't go to github And remember if you want this to work you have to put dot ENV inside of your gitignore you have to put .env inside of your gitignore. I'm not doing it so you can see what my env file looks like, but if you want the protection of not pushing your stuff to GitHub or anywhere else, you need to put it in this folder, in the gitignore.

Cool. Now, when you go to this repo on, on GitHub, you're going to clone it down. What are you going to do after you clone it down? NPM install, you're going to NPM install. You're going to change your MongoDB string to your own and you're off to the races. is you can build the apps of your dreams, folks, the apps of your dreams. It's all here. You did it. You made it. Let's go. Now I know you're probably gonna have to run this one back. You're gonna have to run back last class. That's okay. But I need you to be at the point where this is at least making some sense. You're understanding the big picture.

If you're starting to understand the big picture of how this stuff is working, you are in the right spot. Now, we will be taking a two week break. Up to you how you wanna spend this break. Some folks will use the break to catch up. Some folks will use the break to relax. Some folks might use the break to build amazing apps with the stuff we covered today. It's up to you how you use this time. Like I said, we'll have some project nights, we'll make sure that we highlight the stream team members that are still going live, but I hope you take this time for yourself to do the things that you need to do, whether that's relaxing, catching up, building, take these two weeks and I will see you after the break. Come ready, come ready after this break to put in the work, to get these jobs, to give it the last big old 100 devs push. You deserve it. You owe you take the break and I'll see you in two weeks. Let's wrap up with a raid. So we get our sweet, sweet channel points. Uh, it is hiccup interactives, uh, two week, two year stream anniversary. Uh, we've always rated them in the past.

Let's just go by and say, what's up. Uh, they build, uh, games here live on Twitch. So let's go ahead and say what's up to them just to celebrate. All right, folks. Setting up the raid. Hope you all have a wonderful rest of your night, a wonderful weekend. Enjoy your two weeks. Make the most of it in any way that you want. And then I will see you back here in two weeks. I can't wait to see you. I hope you have a wonderful break. Peace, everyone. Let's raid. you

End of Transcript