00:00:00
Let's get into it. Let's do a little, let me walk you through what we're going to do today. So we're going to start off with JS fundamentals, right? We're going to start off with JS fundamentals. We're going to go over promises, async, await. We're going to go over node fundamentals. We're going to go over CRUD with Express. We're going to go over local auth. We're going to review our binary upload boom, right? And so if you sit through these six hours, right? If you sit through these six hours and you don't do any active recall, it was a waste. It was a waste, we know, we know that there are specific study habits that will literally change the game and what you're able to retain and what you're able to use going forward. Software engineering is a cumulative career. The way that I go through lectures, because I'm always learning something new, literally always something listening. One of my favorite things to do is learn something new.

00:01:00
And when I am learning something new, active recall is a key part of my process. The way that I go through lectures, right? Or if there's somebody trying to teach me something is I don't take notes. Notes don't work. I take questions instead. So as I'm going through And somebody says, um, let's say somebody says, uh, HTML is the content of your website, I would say what language makes up the content of a website. So that was the question I would write down. So instead of taking notes, I'm taking questions at the end, right. At the end of my lecture or video or whatever the heck I'm watching, I go through all those questions and that's my active recall, that's my ability to recall all the things that I just learned. Now, there was a study, and Ali Abdaal has a wonderful video on this, this is their graphic here, where

00:02:00
they looked at a group of people that re-read a chapter four times. So this is the group of folks re-reading a chapter four times, and this is the group that read the chapter once and then recalled to themselves the thing that they just learned. What this broke my brain and I know if you've been around here you've seen this a bazillion times but this this literally broke me right because I was the type of person that would reread shit multiple times that would thug it out like I was going to put in the work and hopefully get there but these people are doing a quarter a quarter of the work and doing better than people that reread it four times. Think about that a quarter of the work and getting better results. So make sure you're incorporating active recall, uh, for a lot of folks, uh, they'll active recall at the end of

00:03:00
each chapter. I like the active recall after every couple of paragraphs, my brain teleports when I read, right? My brain teleports when I read. And so I like to actively recall after each chapter, sorry, after each couple paragraphs, what did I just read? What did I just do, right? And so super important practice. If you're not doing it, even if you've been with us the whole time, you're not doing it, start doing it now. Literally put in a fourth of the work and get better results. Now, the other part I think to keep in mind is that we forget stuff, right? We forget stuff. We will, we will, sorry, one second. We will learn something. and then by the end of

00:04:00
a month, there's an 80% chance that we have forgotten what we just learned. Let's think about that. Software engineering is a cumulative career, and there's an 80% chance that we forget the stuff that we just learned that month. All right? And so we can't let that happen. you can't put in all this work and then be in an interview and they ask you to use some CSS and you can't do it, right? Or they ask you to do a certain coding challenge that you know you've already solved. That's the worst. That's the worst. The worst is being in an interview. They ask you a coding challenge that you already solved and you can't remember how to do it, right? And so we can flatten our forgetting curve, right? we can flatten our forgetting curve, right? And make

00:05:00
sure that we do not forget stuff for the long haul. And so what we can do is we can review material over and over again. And each time we review the material, the length of time that it takes us to forget increases. So the first time you learn something, by the end of three days, there's like a 40% chance that you've forgotten it, right? And then the second time you review it, it takes like seven days for there to be a 40% chance. And you keep reviewing and it keeps flattening and flattening and flattening, right? Right? Right? It's flattening and flattening and flattening. So the more you do your resetting of your forgetting curve, the more likely you are to remember. And this is called spaced repetition. The tool that we mostly use around these parts, So the tool that we do use around these parts is called Anki or Anki if you're Hermione, right? And this tool is flashcards

00:06:00
with an algorithm behind them. And when you use this spaced repetition tool, it serves up the material that you need to see so you don't forget what's happening. And so here is something that's really interesting. Here's someone that spends a Saturday, right? something over and over right so that you you reread something a couple of times you you have your flashcards and you spend you spend a couple hours on Saturday going through your flashcards right so let's say you have five hours a week right some folks will take their five hours and say you know what I'll take five hours on Saturday to do all my studying does not work you have to space without your repetition. Here's people that study just on Saturday, and here are people that find time to get a little bit of studying in each day, right?

00:07:00
So you're better off having an hour of studying each day as opposed to five on a weekend, right? And if you can start incorporating this space repetition into your daily practice, just 30 minutes a day, you're gonna see massive results when it comes to retaining information, especially with these like complex topics that we cover in software engineering. Is there a 100 devs Anki deck? There are tons of them floating around. Don't use them. Don't use them. Why don't we use other people's Anki decks? It's a really interesting question. The making of your deck is active recall. It is literally the primary thing that's gonna

00:08:00
help you learn, right? So when you use other people's decks, you're depriving yourself of active recall. You're depriving yourself of a point of spaced repetition. and we all remember things in different ways, right? And often tying the things you're learning to the process of learning them helps form the neural connections in our brain. So a lot of folks like to, a lot of folks like to write out their, I write out my questions. There's some research that shows like writing out stuff helps like with your memory retention. And so I like to write out my questions and then transfer them to my Anki. and that process gives me active recall, gives me spaced repetition, gives me the benefits of having these questions and answers in my own words, right? And it ties it to the generation process that my brain does something weird where I actually remember it. And so you could definitely find

00:09:00
decks out there, there's tons of them, right? But you're better off doing it yourself. Chris to be said, you don't need, I don't know who needs to hear this, but it's not too late to start inking. Now I started super late, just start. Even if it's today, it will work. I a hundred percent agree. Uh, this whole class is a lot of review, right? Uh, but this is maybe the starting point for a lot of folks, right? Especially for a lot of folks that are in the ketchup crew. Um, there's no shame in the game of starting to put these things into practice. Now, right. Best time to plant a tree was 20 years ago. Second best time is right now. Right. And so make sure that you're taking the time to do these things because they are scientifically proven to work. They just work. Having had thousands of thousands of students that I've taught how to code, there's two classes. There are folks that do the tools that help them to learn,

00:10:00
and there's folks that don't. And what's going to happen? What's going to happen is three months, Like, let's say you're brand new. It's the first time you've heard of a hundred devs, right? First thing we've heard of a hundred devs three months from now, you'd be like, that was too hard, I wasn't able to do it and you drop, right? You disappear. I guarantee you the reason why you dropped and disappeared is because you didn't do active recall. You didn't do spaced repetition. You didn't watch Dr. Barbara Oakley's course on learning how to learn and put that stuff in the practice. Barring life events. That's the reason 95% of the time And you can even be here right now being like Lee I'm barely hanging on to buy a thread Right. I'm barely hanging up by a third and the first thing when I'm it So I teach during the day and the first when somebody comes to me says Leon things aren't clicking things aren't making sense The first thing I tell them to do is show me your Anki deck and a lot of them go

00:11:00
Oops, right, he got, and so you like there, there, there's things that work and there's things that don't. And so what I don't want folks to have in the back, like learning the code is very, very hard. I honestly believe everyone can do it. if they put good study habits into practice. And I would say, barring, like I said, life events, right? So some, some, some, some learning challenges that, that, that we, some folks don't have the privilege of having, um, for, for most folks, it comes down to good study habits, right? And so if you put these things in the place, I guarantee you're going to have a better time. Right.

00:12:00
So the other thing that you have to do is cause this is a lot of work, right? It's a lot of work and you got to have a solid why, right? If you're going to make it to the end, if you're going to make it through the hunt, right, where if we're here to, if you've been following along, you're here for a back end review and you know, you're gearing up for the hunt to get the job, the hunt is a very difficult process. It tries you mentally. It tries you spiritually it can shake you to the core because it's rejection after rejection when I tell you it's One out of 60. I really do mean it one out of 60. We had war roach that said on their 55th networked application They got the job and So to put ourselves through that you need to have a really clear why? All right Law says you have to have a prize to keep your eyes on. I 100% agree,

00:13:00
right? There's a lot of wonderful things about this career. It's high paid. It's consistently ranked one of the happiest careers. There's lots of flexibility to be had remote, wonderful office spaces, sometimes with slides and arcades. Like it's wild. I'm not a person that likes the hype fang that you'll never hear me say, like, go get a fang job. I think that's ridiculous. don't do that because some YouTuber told you to do it. But there's so many wonderful jobs out there for software engineers that are high paid, that are happy, that have really great work environments that could be the blend of work and work from home that you could spend time more with your kids and your family, right? Like there's so many wonderful things about this career. It's fun. Like building shit is fun, right? You could be working on building projects that you love. And so there's something here for everyone. Um, and you really have to focus on your, why, why are you putting

00:14:00
yourself through this? Learning to code is hard. Why are you putting yourself through the wiggles of false hope? That is the hunt. What is your why? Like, you need to think about that right now. Like when we take our first break while you're getting your water, you're hydrating, you're getting up. If you're able to, and walking around, I want you to think about what your why is, right? Like, keep that in the back of your mind. Why are you giving me six hours on a Sunday? Right. Why? And if you can focus that, why I guarantee learning to code, it's easier because when you're lost in the sauce, it's not, you're lost in the sauce. It's I'm going to get there because why? Cause I have to, because I want this thing for my life. Right. I want this for my family. I want this for my future. I want this for, I don't care. I want the Porsche. I don't care what it is. Like whatever that, that motivator is for you. You got to have it. You

00:15:00
got to, I have a lot of folks that just put like a sticky note on their monitor, right? Right. What is your, why, why are you doing this? Right. It could be that you just love to build cool shit. Like whatever that why is it has to be front and center or else this process will tear you apart. And so a lot of folks when it starts to get a little stressful because they're not centering on the why Right, like who cares if it takes me an extra week to learn something? Right, who cares if it if if I don't understand something the first time I cover it I can go to my wolf right who cares if if if my first three rejections come through doing the hunt I'm sticking to my why I'm sticking to my why and you gotta have it. Don't continue with this program without a why. And it can be the, it doesn't have to be that deep.

00:16:00
Doesn't have to be that deep. I love programming because when I looked at my bank account, money was there. That's why I love programming. That's it, that's where I started. I started with that why. I want food. I want food. That's literally why I started coding. Cause I wanted food, right? Like figure out what your why is, and there's a chance to grow into it, to turning into something that you love. Right. I love learning about code. I love writing code. I love building cool shit every single day, but it didn't start that way. Right. It didn't start that way. Don't ever let somebody tell you that you have to, you have to be in love with writing code to be a good software engineer. Nah. The best software engineers I know, clock in at nine, leave at five. They don't touch code on the weekends and they're beasts, right? Right? But figure out what your why is, center that, you're gonna need it for the rest of program.

00:17:00
Now, one of my experts in residence at Resilient Coders that I work with every day, had this wonderful analogy that I think is super important. And they relate it learning to code, like babies learning to walk. Babies learning to walk is half like hard work, like them getting up, falling down, constantly not being able to do it, and half believing that you can actually learn to walk. So babies look around and see all these people walking, And they don't start crying and sitting in the corner going I'll never be able to walk There's never I'm never gonna be able to walk like they don't see other people walking and feel bad about themselves Right, like they keep putting in the work. They keep getting up. They keep falling down. They keep getting up They keep falling down. They keep getting up. They keep falling down. They keep getting up They keep falling down

00:18:00
and they learn to walk Don't ever look at somebody else getting a job before you. Looking at somebody else picking up the code we did last week before you. Don't ever look at somebody else that's having a better grasp of Node. Don't ever look at those people and go, damn, I'm never gonna be able to do that. That makes absolutely no sense. You have to believe, right? You have to believe that you're going to get there too. And if anything, seeing those people walking is should be the biggest highlight of your day. Cause you're like, if they can do it, I can fucking do it too, right? I think so many people see folks walking, see folks getting jobs. They see folks picking up concepts. And for some reason in their brain, in their body, their soul, they go,

00:19:00
I can't do that cap. You all have the ability. You all have the ability. It just takes a lot of hard work. And babies don't sit in the corner crying. Sometimes you need a good cry, but babies don't sit in the corner crying. What was me? I'll never be able to do it. They see everybody else walking and they get up, they fall down, they get up, they fall down, they get up, they fall down. So you need to get up and you need to fall down a couple hundred more times and you'll get there, too This is also the point of program where imposter syndrome becomes probably your chief Your chief concern. I Think this is the point of program where imposter syndrome comes in the full effect and this is honestly what will hold the

00:20:00
most people back from achieving their why right and getting getting this shit done like I said you see other folks starting to get jobs and for some people that triggers something in their brain that makes them feel like they can't do it too and you need to squash that that's that you just need to get rid of that right now it's just absolutely not true Other people's success takes nothing away from you. Nothing from you. And you have no idea how long they waited to get on that front of the car. You have no idea what experiences they have. You have no idea how their life is set up right now to do all this. You can't look around at other people walking and think that you won't get there too. Babies don't do that, you don't do that. Now, the other part of imposter syndrome is we're getting close to the hunt, right? Right, we're getting close to the hunt, which means that you're going to now have to start showing others that you can do the things that

00:21:00
you can do. And that triggers a whole other level of fear within ourselves. But that's why it's a numbers game, right? It's 100% why it's a numbers game. You're going to have 10 interviews that go horribly wrong. Like you vomit on your keyboard, you slip. right? And as you're slipping on your vomit, you, you, you, you like, I don't know. I'm trying to think of like the worst thing that could possibly happen. You hit the, the nuclear launch codes, right? I don't know. Right. You need to do something horrible. Like it's just going to go like the worst thing you could ever think of. Right. And so what you have to realize and you poop yourself on the way down exactly, nerd, um, on the way down, you just have to realize that, that you're going to have, every single one of us has 10 of those in us. Every single one of us has 10 of those in us. Right. Right.

00:22:00
And so it's, it, you can't think less of yourself when I'm telling you, you already have 10 of those in you. Right. And then you got like 40 mid interviews, right? You got 40, you're going to go, eh, I was there. kind of went okay, and then you'll have 10 where the stars align. You're going to feel like all the planets are in direct alignment with you. You're going to feel like, uh, like, I don't know that, that, that somebody was whispering all the answers magically into your ear. It just happens to numbers game. Right. And so you can't let the nerves get to you. You can't let the imposter syndrome creep up because it's just, it's just the fear of the unknown. And it's just the fear of, um, what if somebody is going to ask you, like, it just doesn't matter, right? At the end of the day, all these companies that you're going to join are going to do things in their own way. And

00:23:00
they're going to expect you to take three to six months to ramp up. Most companies expect you to take three months to figure out what the heck is going on. Right. And so you're going to learn just enough to get your foot in the door. And then you're going to work your ass off once you're there. And worst case scenario, worst case scenario, you get paid for three months to learn how to code, let's go turn up, right? And so the imposter syndrome, this is when it hits. It's not warranted. You've been putting in the work, you've been here, you've been showing up, you've been building your projects, you've been doing the things that you need to be doing to get these jobs. You're a great software engineer, full stop. Now it's time to find the right fit for you, It's time to find the right interview process for you. Every company does it differently There's gonna be something that clicks for you and the things that you know, and you'll be an asset to that team Now

00:24:00
Very first thing I showed you was the trough of sorrow. The funny thing is like I show the trough of sorrow and it's so true Like you show the trough of sorrow. It's just it's just it's just true Right, like people don't get how true the trough of sorrow is you show this day one and everybody's like Can't be that bad, right and then a week later they're like That was true and and so I Think the the trough of sorrow is very real Right? I mean, most folks aren't willing to sign themselves up to go through six months of sorrow, right? They're just not willing to do that, right? Because like that, it's just, it's just, it's six plus months of sorrow. Like most people in the world aren't willing to do that. And I think our, our, our, our communities showed that,

00:25:00
right? Like we started it off with first class, which is always a scrub because people trying to figure out what it's going to be, but our first class was 5,400, right? Like after the, after the, the intro, like this is what you're signing up for 5,400. And now, now we're, we're, we're at like one to 2000, right? Like we we've kept a strong number of folks, but this trough of sorrow is real. Right. Is real, right? You get stuck, right? You get stuck in this trough of sorrow, right? And most folks don't want to work through it. Right? Right? Right? Right? The more you do it, right? The more you do it, right? The more you trudge through it, the worse it gets. All right, the worse it gets,

00:26:00
right, like this, this drop of sorrow, you, you still, you're still like in the fun part. You just went down the rollercoaster. You're like, and then you get to the bottom, right? This is the real trough of sorrow that, that three months in things still aren't clicking, right? Things still aren't clicking. You're, you're, you're feeling, you're feeling all the insecurities, you're feeling all the things that are coming up, like that's the real trough. And then you've pushed it. You've pushed it to here. And now we're building full stack web applications and you're seeing folks get jobs and then you tank. Everyone does it. This is the process. You tank. There's something about being close to the end that messes with us. It's the worst part of the process. When you're so close that you can see it, you're seeing other

00:27:00
folks around you, all the imposter syndrome comes through, right? All the imposter syndrome comes through. All of the struggles of realizing, shit, I got real deadlines. Holy crap, like this stuff, I really need to start putting into action. I'm gonna have to start talking to people in these interviews, like all that stuff comes together. and that's why this little dip right here exists. The worst part, it's where most folks take themselves out the game. And then you start to build your hundred hours project. You start to realize that, wait, when I build out that checklist, I'm starting to get recruiters reaching out, right? I'm starting to like maybe understand some things. I have my first interview, right? I have my first interview. And then after your first interview, what happens? Boom, you drop down again, right? And then you have like your next interview, and it kind of goes well. And

00:28:00
then boom, down again, interview, down, interview, down, interview, down, up and down, up and down, up and down, sideways, left, right, boom, boom, boom, boom, boom. And then eventually the stars align, that one interview goes really well, and you make it to the promised land. And then you're out of the trough of sorrow, You still fight and you fight over the next rest of your career to keep learning and keep growing right All right, so don't realize that most of us are right here and Realize this is the most difficult part Where all of our knowledge is coming together to build full stack applications All of our doubts are coming to the surface because now it's time to start applying stuff all the the judgment and worry that comes With the interview and this is the hardest part But we'll get there as a community All right, we'll get there as a community as you need help come to discord

00:29:00
leonnoel.com slash discord right if you're watching this on youtube discord if you're brand new here excavation point discord you can do this you can absolutely make it through the crash of ineptitude and into the wiggles of false hope and into the promised land Cool. Now, before we jump into the rest, before we get into basic JavaScript, before we get into basic JavaScript, three things, this is it. After thousands and thousands of students, I can say tens of thousands of students now with 100 devs,

00:30:00
Managing your frustration, being consistent, and taking care of yourself are the only three things that get you to the end. The only three things that literally help you get the job in the end. I've talked about the studies in the past about the managing frustration. Basically you look at adult learners, the reason why adult learners don't actually learn and how to code is because they are in control of their life. They can decide to put Netflix on instead of studying. And so when things get tough, when they get frustrated, instead of doubling down and trying to get help and working through it, they turn on Netflix, right? And so the more you can manage your frustration, the easier it is to learn. And managing your frustration just starts with realizing that you're frustrated and coming up with systems to not be. That's it.

00:31:00
It's coming up with systems to not be frustrated. So for some folks that is, all right, when I'm frustrated because I'm stuck on code, what do I do to get unstuck on code? Do you post on discord? Do you jump in a voice channel? Do you ping folks on discord? Do you go to the stream team members streams and ask they're like, what do you do to get unstuck so your frustration subsides. And most folks don't have a game plan for when that happens. But if you put a game plan in place for that. Because a little easier. The next thing is being consistent. Consistency works because we saw that spaced repetition works literally scientific fact about how adults learn spaced repetition is the key to not forgetting stuff. It's the key to learning stuff is active recall is the key to getting that material in with a quarter of the effort and consistency means you can't just chunk one day of the week and hope

00:32:00
that you remember something a week later. It doesn't work. It's daily practice. It's squeaking out 30 minutes a day so you can get that space repetition in, right? So that you can reap the benefits of the things we know actually help you to learn as an adult. And then the last and most important thing is you're signing up for months and months of mental anguish Making your fingers on the keyboard do things you haven't done in a long time sitting for long hours staring at screens for long hours Constantly getting rejected when you go into the hunt It's a lot You have to find ways to take care of yourself. You have to introduce breaks. You should be doing Pomodoro I know a lot of folks like to just go for 3-4 hour stretches, I'm telling you if you do that for months, most of my students are not successful doing that. Taking good

00:33:00
breaks, taking care of yourself, hydrating, walking away, letting your brain diffusively think pays off significant dividends. We're not in flow states yet. We're in learning mode. When you're on the job, maybe you'll achieve flow and you can code out 4 hours straight, that's fine. right now you're learning and we know the research behind memory consolidation and it doesn't happen when you do it for that long you need to take breaks well so last but not least don't let your dreams be dreams Alright, center your why, manage your frustration, be consistent, take care of yourself, if you do that you make it to the

00:34:00
promised land you owe you you owe you i can't make you do anything but you deserve a high paid career you deserve a happy career you deserve a flexible career you deserve the things that come your way when you put in this amount of hard work when you put in this amount of supporting those around you that are part of this community. You owe you. What is the internet? Bring it all the way back. What's the internet chat? What's the internet? It's a wire connecting two different kinds of devices. We have our clients. So think of our desktops, our laptops, our mobile phones, and they to make requests to servers. Their servers are just computers out there on these internet wires that can hear those requests and respond.

00:35:00
Eventually we are going to be writing code that exists on these servers that can listen to those requests, generate the responses and then respond, right? And so the beauty here is that we can build out applications that look good on our client-side devices, and that would be our front-end web development. So building out the HTML, the CSS and JavaScript to make our stuff look good and run good on these client-side devices. And as backend developers, we can write the code on our servers that listens for requests and knows what to do when it hears those requests. Do we store stuff into the database? Do we process credit cards? Do we log folks in? All this stuff that happens on the server and then figures out how to respond. Are we sending code? Are we sending JSON or anything back? Wonderful.

00:36:00
So, today, we'll be talking mainly about the backend, the stuff that runs on the server, that's listening for requests, that's generating responses, that's doing the heavy to build out our applications. All right. Programming. As we talk about programming, we have to keep something in mind. A computer will do what you tell it to do. Right? A computer will do what you tell it to do. So a program is simply a set of instructions that you write to tell a computer what to do. And that makes the act of programming just simply the task of writing those instructions in a language that the computer can understand. And that's the important bit, the language that a computer can understand. So if we talk about this in terms of building up to a language that the computer can

00:37:00
understand, I like to start with a simple circuit. Okay, one second, I gotta grab my iPad. I don't know why it's not plugged in. Be right back. Share your why in chat for me while I grab the iPad. Why isn't chat why I grabbed the iPad, please?

00:38:00
You nerds, you're a bunch of nerds Fulfilling stable job, childcare is expensive, hell yeah, so I can move out, that's dope. I'm gonna make the bread Lambo Family vacations a nice work from home freedom flexibility I'm gonna live for a sense of pride and financial freedom Take care

00:39:00
of your family more pizza Money so the family can get their best life Buy more digital goods on meta Napio on disability, help my mom get a dead end job, travel the world, healthcare. I love it. Thank you for sharing. So I don't understand why we're spamming Y's cause you're all a bunch of nerds. I'm a nerd too, so that's okay. Everybody just start typing the letter Y in chat. Alrighty, thank you for sharing that. All right, iPad's ready to rock and roll. Thank you. Alright, so programming is a task of writing instructions in a language that the computer can understand. So let's build up to that language. So here I have a simple circuit, so I have my light bulb and I can connect a battery and since this circuit is complete, right?

00:40:00
Since the circuit is complete, the light bulb should turn on, right? So let's go ahead and introduce a switch into this circuit. So right now, the switch is open. And since it is open, is the light bulb on? Nope, not on. And if I was to close the switch, the light bulb would turn on. And so we can represent this on off value with some very simple notation, right? So we'll say off is zero and on is one, right? And

00:41:00
so if I was to draw this circuit, That had two switches, how could I represent this circuit? Yeah, I can represent it as zero, zero or off, off. And how could I represent this circuit here? Now that both switches are closed, how can I represent that? Yeah, I can represent that as one, one. Right, one, one. And so that means that I've now represented a circuit where both switches were open. I represented a circuit where both switches were closed. Right, we could also do, right, we could also do some other things like zero, one, one, zero. Right, we could represent these very simple on off values in a very simple language, which we call binary. Now from

00:42:00
this, we can actually start to build up to a little bit of logic. Booleans are C and C are sugar that reduces to zero one. I love that. I actually can introduce a little bit of logic with this notation. So since both of these circuits are closed and I'm representing it with one one, what would one one actually represent right now? Like if we were to say, I think it's very simple. This is very high level. this is not meant to be exactly what's happening, but we can just think about something. Yes, it's on, but we're talking about both of these switches and we're representing that they are both on. So we would say this blank, this. Yeah, and, right, and, right? We're saying this one is closed and this one is closed, and. So we can represent both, right? One, one,

00:43:00
and we can say that that means, and like this one and that one. And so we can actually build up some very, very simple logic, right? We eventually call these things called logic gates. And just by representing on and off values and adding slightly more gates that are on and off, we wind up with things like and, nor, like all this other fun stuff that you will see when you kind of nerd out about this stuff. But the idea here is that from just simple on and off values, we can build up to some logic. We already saw and, right? Right? We already saw and. And we can start to realize, well, once we have simple logic, we can then build up a very low level programming language. Once we add things like memory, right? A way of doing some basic arithmetic, and we have some very low level logic, right? we can build out a programming language. However, the language that

00:44:00
we're learning is still very, very, that would be very, very low level. For us, we're not gonna be writing this low level, like assembly level code on a day-to-day basis. We're gonna be writing something that is a little bit more human readable. And talking about human readable, true story, for those that don't remember, Independence Day, right? Aliens came to attack the world and we were able to destroy them. Now, if you remember when the aliens first came, we tried to nuke them, we tried to do all these wonderful things and we couldn't do anything. They had these wonderful force shields. But what we did realize is that we had one of their, one of their previous planes that had crash landed years before. And when the alien mothership got close, that spaceship

00:45:00
got power. So there's something about how power is distributed across these alien ships. Something about how the force field comes on when it's near other alien ships. And so there's this idea that if we could like turn off power on the mothership, Maybe that would distribute to all the other ships and bring their force fields down so that we could nuke them and save the world. So what did Jeff Goldblum do to save the world? Yeah, he wrote a computer virus that they then uploaded to the alien mothership that took down the power or distributed the power to these other ships, forcefield turned off And we were able to blow them out of the,

00:46:00
out of the sky. Uh, how in the world the Jeff Goldblum write a computer virus for an alien civilization that probably wasn't just writing plain English, like how could we ever write, how could we ever write code that would work on their systems? Yeah. Jeff Goldblum broke it all the way down. They reversed engineered it all the way right all the way down to the zeros and ones the on and off values We would assume that on and off is a universal constant So this idea of building up to more and more complex logic would be the same no matter If you're here on earth or your aliens far far far away, so Jeff Goldblum reverse-engineered their language all the way down to zeros and ones, and then built it all the way back up into a language that they could inject into the alien mother ship.

00:47:00
We refer to this wonderful event in history as binary upload boom. We took down all the ships and Jeff Goldblum saved the world. America. All right. National hero. And so this is a true story, right? And this idea is that we could theoretically do this because at a very, very low level, all the languages that we are writing can be broken down into on and off values, zeros and ones built up to more complex logic, to more complex logic. But us as programmers on the day to day, don't want to have to worry about writing binary, writing assembly level code. We want to to be using something that makes our lives easier, and that's JavaScript. JavaScript is the language that we're using so that we can work well together as engineers, we can communicate our complex ideas, and then underneath the hood,

00:48:00
right? Underneath the hood, this JavaScript is getting broken down into that simpler logic that our computers can understand. But it's not something we have to ever worry about because JavaScript is doing the heavy lifting for us. Cool. Now, some basics just to get them out the way, especially for folks that are kind of really new, just so that we're all on the same page as we get deeper into the review. And don't worry, we're gonna go through this kind of quickly and we'll jump into the more meaty stuff pretty soon. And also just a quick caveat again, for those that are new or kind of jumping ahead a little bit with the catch up crew today. There's a lot of stuff that we go through. Don't feel like this is the class or the moment where you have to learn it or fully understand it. This is meant to be a review, uh, for folks that have been kind of watching along. And so know that there is a class for each and every single bit of information that we're covering today. Uh, feel free to jump

00:49:00
on discord to ask questions, feel free to ask questions here in chat. I ask everyone that you answer questions that you see in chat and then, um, know that you can always go back and watch individual classes to shore up a lot of this material. All right. Variables. So variables enable us to store information. So we have this idea of when we talk about kind of computing, we have a space in memory. And our variables enable us to create that space in memory with a step called declaration. So I would create a space in memory we call it age, and then I can assign that space in memory of value. So then I would put 25 in that space in memory. So I can do this declaration, creating a space in memory and assignment on the same step. So here you can see let age equal 25. I have declared my variable and assigned it a value at the same time. Boom. We also have conditional syntax where we can check to see if a statement is

00:50:00
true. And if it's true, we wind up doing what is inside of the curly braces. We can also have multiple conditions where we're going to try and keep checking stuff until something is true. So you can have an, if, if that's not true, you can do an else if, and you can have as many else ifs as you would please. And if none of your ifs are true, none of your else ifs are true, the else will auto magically run. All right, the else will automatically run RFN 972 so where can I find the previous videos you can do exclamation point YouTube here in chat to find our YouTube But don't just watch on YouTube also join our discord exclamation point discord That's where you'll find all the materials and you'll find our community. We're at what home where we at now Let's see

00:51:00
That's wild. That's just wild to me. That's absolutely wild to me. We are at 39,589 people. 39,589 people on discord. That's wild. How many bots? Uh, we have, we have like four or five bots that run on the channel, but, uh, we are like our, like everything's dialed up to the max. Like it's, it's, um, you have to do like phone verification and all that stuff. But the cool thing is you can actually see the number of active folks and at any given time there's like 4,000. Just think about that, at any given time, whenever I do add everyone,

00:52:00
there's at least 4,000 actively online. That's bonkers. That's wild. Yeah, that's wild. Cool. So here is a lovely bit of syntax here. We have const pizza equals dominoes. Why is this pizza const? It'll never change, it'll never be reassigned. My pizza will always be dominoes from here until the end of time, right? And so does pizza equal Papa John's? Hell no. Does pizza equal Domino's? Yes. And so what gets printed to the console log? What gets printed to the console here?

00:53:00
Yeah. All aboard the train to Flavortown. Exactly. All aboard the train to Flavortown because pizza equals dominoes. So this first conditional was false. The else if was true. and then the else, right? The else never runs because the else if was true. Now let's say for some reason pizza was Bob. I don't know, just to make something up, right? Pizza's Bob, right? So does pizza equal Papa John's in this case? No. Does pizza equal Domino's in this case? No. Since our if and our else if, right? Since our if and our else if, none of them are true, our else automatically runs. Hey, thank you for the raid. Thank you for bringing the crew along.

00:54:00
We're doing a back-end super review. Cool. Our local Papa John's went out of business and closed. Good, absolutely good. That's the best news all day. Alright. What's the danger of assignment versus comparison? Pizza hut number one. Hold on. No. Absolutely not. I refuse. Time out. You're timed out for 10 minutes. Got em. And they just got reassigned assignment

00:55:00
versus comparison. Remember if you do one equal sign inside of your conditional, right? If you do one equal sign inside of your conditional, right? That's the same thing as doing assignment. An assignment will always be treated as what? True, right? So you're not doing any comparison when you do just one equal sign. You're literally trying to reassign a variable, which will be true, and then it will kind of always run, which can get you into a pickle. So the thing to be careful when you're inside of your conditionals, Let's be careful of assignment versus comparison. Two or three equal signs is comparison. One equal sign, you're trying to reassign or assign a variable. All right, now we can have multiple conditions inside of our conditional where your name equals Leon and status equals Balan.

00:56:00
They go to the boardroom for that one. You know I'm saying. You know I'm saying. Alright, I can also have multiple conditions that are or so if day equals Saturday or day equals Sunday, it's the weekend, right? It's the week I'm calling HR for that one. It's the weekend wonderful functions. Functions are just simple sets of instructions. They are reusable. A function performs one action typically as a best practice. It's something we'll start building up to later on. And they form the basic building blocks of our program. Here is a function. We have our function declaration and we have our function call. If we want the

00:57:00
instructions that are inside of our function body to run, we must call that function. We call mom to argue, right? We call mom to argue. So when we call our functions, we're telling these functions to run and we can pass in arguments, individual values that will be passed into our functions that our function can use as it executes. So here's an example. We have a function called yell and it takes in a word that it will eventually alert. And so down here I have called my function and I have passed in string Hello as a what string? Hello is a what here That would a string. Hello As an Argument exactly as an argument. So I pass in string. Hello as an argument it gets passed into my parameter

00:58:00
of word wherever I see word, it's actually this string hello. So we would see hello, right? We would see hello, right? We would see hello alerted to our users. Cool. Here is a function with two arguments, both hello and goodbye, right? And so we pass in hello. Wherever we see word, it'll be hello. We pass in goodbye. Wherever we see other word, it'll be goodbye. So we will see alerted, hello. And then we will see alerted, goodbye. Very simple functions here. Loops, loops enable us to repeat an action some number of times.

00:59:00
There are three main kinds of loops in JavaScript, for while and do while, and each type just has a different way of determining when you start and stop your actual loop. There are plenty more, especially as we get into the methods for various kind of arrays, objects, and strings. there are other types of loops, but the three main ones are for while do while. Here's an example of a for loop where we set our starting value, our initial value. We have the case that we check to see if the loop should continue. And then we have our increment, how much our value goes up by each time this loop runs. So the very first time that this runs, I is one and since one is less than five, this runs and we console log the number one to our console. Then we add one to I

01:00:00
and we check again, two is less than five, we print two to the console, then we increment again, three is less than five, so we print three to the console, then we increment again, four is less than five, So we print four to the console, we increment again, but now five is not less than five. So we stop. Right. Right. And we stop. Cool. Arrays, a data structure that we can use as an ordered collection. The little odd thing about arrays is we start counting with zero and not one. And we can create them with a constructor or literal notation.

01:01:00
And I like to think of my arrays as toasters, right? Our arrays are just one entity that can hold a bunch of other stuff. So we think about a toaster Our toasters can hold bread. It can host hosts or strudels. It can hold pop-tarts, right? It's still one toaster, but there are slots for each and every item Now if we have Bill Gates toaster Whenever we fill up our slots a new slot magically appears and we can put anything we want inside of Bill Gates toaster Cool. So here is that literal notation where we are literally declaring an array, we have a variable name, and then we have the square brackets. So we've literally created an array. And when we create an array, we can have any type of value that we've learned about so far inside of that array. We can have strings such as zebra, we can have Boolean such as We got numbers such as 21. We could even have arrays inside of our arrays.

01:02:00
Cool. Now, when we start accessing the elements that are inside of the array, right? When we start accessing the elements that are inside of the array, we use the indexes to grab those individual elements. So if we wanted the element of New York City, we would use the index of zero, right? I use the index of zero. Can you have an array of rays? Yes, you can. If I want it London, I would use the index of three. So tricky question I always like to ask. What is the second element in this array? Second element in this array. Second element in this array. Y'all are too good. Like we've been doing this for a couple months. Yeah, the second element in this array is LA. However, if I want to access that

01:03:00
element of LA, what index do I use? One, nice. I love seeing all the first time chatters. First time you chatted to say LA and one, I love seeing it. If you've been here and you never typed in chat before, today's your day. I wanna see you type in chat today. Cool, yeah, so we would access the second element of LA by grabbing the index of one, beautiful. Now, we can use these indexes to grab elements out of our array. So in this case, I'm gonna use my array of new array with the zero index, and that would grab zebra. When I do new array one, I get undefined because there's no element in that spot. Blank spaces, right? Blank spaces count, and when there's nothing in there, right,

01:04:00
right, nothing in there, right, they still count and we get undefined. YT do exclamation point unban. We can help you figure out what happened. So we can grab individual values, right? We can grab individual values and we can not only grab individual values using the index, we can also use the index to add items to our array. So in this case, right, right? In this case, I'm using the index of one, right? and I am going to give it the value of Bob. And what that winds up doing is putting that value into the array at that index, right? Into that index.

01:05:00
Objects. Objects are simply a collection of variables and functions. Objects help us represent the attributes and behavior, something that we're going to use in our program. We call these variables and functions very specific names. The variables tied to our objects we're going to call properties and the functions tied to our object we're going to call methods, right? So empty spots still take a spot. They absolutely do in arrays. Whenever I think about objects, So I like to think of a physical object. What are the attributes and behaviors of that physical object? And so I like to start off by thinking of a stopwatch, right, right, of a stopwatch, right, of a stopwatch. And so when I think of the physical properties of a stopwatch, what are some physical properties or

01:06:00
attributes that a stopwatch could have? Yeah, our stopwatch could have a color property, a size property, a shape property, can even have like a brand property, right? So we have the color of black, it could have the shape of round, it could have the brand of Nike, it could have all these different properties. What are some behaviors or methods that our stopwatch could have. Start, stop, lap, reset, pause, beep, beep, beep, motherfucker, right? So we can think about a physical object and it can have attributes and behaviors.

01:07:00
We're gonna call those attributes properties and it can have behaviors that we're gonna call our methods. So we can actually create an object using literal notation. So here I am declaring a variable called stopwatch and setting it equal to curly braces. When I am literally creating an array, it's square brackets. When I'm literally creating an object, it is curly braces. And the beautiful thing is we can use what kind of notation, What type of notation am I seeing here? The add properties and add methods here. What type of notation? Yeah, dot notation, exactly. So you can see here I did stopwatch, which is my object, right? I can do stopwatch.currentTime, which now gives the stopwatch a current time property with the value of 12. and then I can add the telltime

01:08:00
method using stop the dot notation. And how do I know that telltime is a method and not a property? How can I tell that telltime is a method and not a property? Yeah, it's a function. Yeah, it's a function, exactly. So whenever we see something tied to an object that is a function. We're going to call that a method. And then down here, we can actually use this. So, here I am using the tell time method. And I can tell that this tell time method is running. How can I tell that the tell time method is running? How can I tell that it's going to actually run or execute this function? Yeah. The parentheses. Exactly. If we look, This is the same function call. Just look right here. This is the same function call that we saw a little bit, a few slides ago.

01:09:00
We have the name of the function, the parentheses. You need the parentheses for the function to actually run. And then we're passing in stopwatch.currentTime as a what? Stopwatch.currentTime as a what? as an argument, exactly, as an argument, wonderful. So I'm passing stopwatch.currentTime as an argument. We know that stopwatch.currentTime is currently the number 12, so it's as though we placed the number 12 in here. Number 12 is being passed in as our argument, so we're gonna pass that into time, and what we're gonna wind up seeing is the current time is 12. Beautiful. Alma said, what's the difference between an argument and a parameter? Arguments are what we pass into when we are calling our function, and parameters are there when we declare our function to accept those arguments. Now,

01:10:00
why the heck do we have arguments and parameters? What does, what do arguments and parameters enable us? Like, why do we have this? Why not just like hard code everything? Yeah, exactly. It enables our functions to be reusable. I can pass in a different value whenever I want. So I could pass in the number 12 here, but I could also pass in the number 24. I could pass in the number five, right? Pass in whatever I want into this function call, right? Into this function. And this function will work with all those different values, right? So it makes our functions reusable, right? Reusable. Wonderful. All right, now, we don't have to just create our functions literally. we

01:11:00
can use classes and constructors to spit out a bunch of objects for us. We can think of classes as our templates for objects. So here I have a make car class. We can see that every single car that comes out of this make car class will have four properties and it will have two methods. All right, four properties and two methods. So in this case, we're saying make a new car. We're passing in Honda for the car make, Civic for the model, silver for the color, number of doors of four. So the Honda Civic that comes out of this constructor will have a make property of Honda, it will have a model

01:12:00
property of Civic, it will have a color of silver, and it will have a number of doors of four. It'll also have two lovely methods, honk and lock, that enable us to then go ahead and make as many cars as we would like. As many cars as we would like. Wonderful, cool. So let's stop in here for a few seconds and answer some questions. Can you explain the this keyword? So when we are creating stuff out of this class, right? When we are creating stuff out of this class, we want the objects coming out of this class to have the properties. so that this keyword is what binds these properties to the object coming out of this

01:13:00
class. So if we were to copy this class here, and we can just go ahead and open up our inspector, and we can go to our console, and we can paste this in and hit enter. If we ask for Honda Civic back, you can You see that the object, right? You can see the object that came out of this class now has a color property, a doors property, a make property and a model property. The reason why, right? The reason why they have a color, a doors, a make and a model property is because this keyword bound those properties to the object that was coming out of this class. Is this what we used for? Sorry, is this what

01:14:00
we used for our schema? Yes, holy crap, way to connect it to the end. This is exactly what our schemas are doing. Our schemas are spitting out, right? Spitting out objects, right? and those objects are the documents in our collections. It's exactly the same thing. Mongoose is using schemas just like classes to spit out documents into our collections, yeah. Constructors are just enabling us to make the object. That's all it's doing, is enabling us to make an object that has these properties. And so for folks that are like, Leon, what class is moving through so quick? Well, you have to realize that this is a review class, right? We had, what, three whole classes on just this? Like really just this. And so if you're new and you're like, Leon, this is a little too much for me. That's all right. Hang on for the review, but know

01:15:00
that you can go through three full classes on our YouTube, exclamation point YouTube, through all this material. Cool. Can constructors make arrays? Yes, technically underneath the hood, constructors can be used to make pretty much anything in JavaScript, because everything in JavaScript is still technically an object, which is a weird thing to remember. Yep. Cool. Now, I just want to take a moment. I want to take a moment before we take our top of the hour break, I just want to take a moment to think through everything we just talked about, right? For folks that have been here since the beginning, the fact that you understand variables, conditionals, assignment versus comparison, multiple conditions like and and

01:16:00
or, the fact that you understand functions with their arguments and parameters, the fact that you understand loops and the the ability to loop through content, the ability to understand arrays as ordered collections, that you know that indexes matter and you can pull stuff out of the arrays. You know that you can create objects and arrays with both literal notation or constructors inside of a class. That's wild. That is wild. world, you should be absolutely, absolutely 100% proud of the fact, right? Proud of the fact that that stuff makes sense. No, it might not always be able to do it from scratch to the day to the day, but the hell that you understand all that crap that I just said is absolutely mind

01:17:00
blowing. And you should be immensely proud of all the hard work that you put in to get to that point where this stuff makes sense. And so I need you to carry that energy into next couple of months, next couple of weeks, because you have done something that hundreds of thousands of people want to do, but don't do. They all want it, but they don't do it. You did it, you came to get, and you got. And don't ever, don't ever forget that. All the hard work that you put in, all those long days, those long nights, the struggle, the asking questions on Discord, the popping into the stream team to get more help, you did that. And now this stuff that makes no sense to 99

01:18:00
.9999999999% of the community in this world, you understand. And so carry that with you. You're built different, you're special, you deserve the good things that are coming your way. For folks that are just joining us, we're doing a backend super review. Right now we're building up to the things that we're going to need to kind of talk a a little bit more intimately about the back end. If you're new or still catching up with the catch up crew, a lot of this is going to be pretty fast. You can go back and watch all of our individual classes on YouTube that go way deeper into all these topics. Alrighty. you APIs, a simple interface for some complex action. I like to think of a restaurant menu, right? You sit down, they give you a

01:19:00
menu. This is back in the day when we used to actually go to restaurants. I sit down, they give you a menu, you point to something on the menu and then something complex happens in the kitchen. You don't really know what's happening. You don't know how it's happening, but you get your delicious food that's delivered to you, right? And so it's simply one thing that lets us communicate with another thing without having to know how those things are implemented. Our menu enables us to order food. We don't understand how the food's being cooked, how it's being cooked, how much water they're using, how much flour they're using, what type of a knife they're using. It just doesn't matter. We can request something and we can get the response that we care about. So I expanded this example in my MVC lecture, hey, let's go. And so APIs are gonna be kind of the cornerstone of a lot of what we do, especially on the backend, where we have some sort of requests come in, we do some complex action and we respond.

01:20:00
Eventually, right? Eventually, eventually our APIs do more and more complex stuff. Storing things into a database. Checking if someone's logged in. Storing images in the cloud. All the things that we're gonna do, especially as we start to build up Binary Apple Boomi, so we're gonna have our project. All these complex things can happen based off of a very simple request. User makes a request typically from the client. That request makes it all the way to our server. all that complex code on the back end happens and we serve up a response. Here is a simple API that we started off with. This is using the dog CEO API. Let me go ahead and copy this real quick. We are making a fetch request

01:21:00
to this URL. And if we get a response back, we are going to parse that response as JSON, and then we will go ahead and console log that data. Now this structure, just we're gonna get to this in a little bit, but what is this structure? Technically, what are we using here? What is the fetch going to return? Just to big brain it and think ahead for a few seconds. Yeah, it's a promise, right? It's a promise. We're gonna talk about promises in a little bit, but we're gonna make a request. We're gonna get a promise back. Yes, let's fucking go can we just stop for a second? Oh, we just stop for like What What how do you look at this code and go yeah, Leon, that's a promise Look at you seriously seriously Look at all these people in chat Seriously think about that You

01:22:00
look at this, go, oh, Leon, yeah, it's a fetch. It's an API request. API request is going to return a promise. What? That's huge. I don't care. Like that, that's, that's a really wonderful thing. Like all the work you put into to understand that, that's, that's pretty special. Cool. All right. So you made a request to this URL. You get a promise back or some data back. we can eventually console log that data. So let's go ahead and open up our inspector. And you can actually see that the promise was pending. And then we got a response back. And that response back had a message property that had the value of this link, which was a Mexican hairless. I'm really excited to see what this is. what that's a thing that's a

01:23:00
cool dog what yeah it looks like a nubis right it does zolo is that the name i don't know what i don't know what that is that's wild i never seen It has like the face of like a Chihuahua almost. Mexican hairless. Looks fast. Yeah, it does. Sleek, no drag. Cool. So I was able to make a request, right? I was able to make a request using the fetch API. I was able to make a request and fetch is an API. We're gonna talk about that in a second. it. All right. Oh, solo. That

01:24:00
makes sense. That's really cool. All right. So fetches we're gonna talk about that in a second, that enables us to make a request, right? It wants to make a request and we get some data back and the data that we got back, we console logged. We console logged it and we can see the data we got back was an object, right? Was an object, right? That had a message property that was the link to the image of the dog and also a status property just let us know that it went okay. And we can make this fetch over and over again. Like if we do another fetch, we're going to get another random image back. And this time we have, uh, Bassett hound. It was up ears. Right.

01:25:00
And so now we're able to make these requests. These requests are going to the dog CEO server, the dog CEO server. Here's the request. All right, here's the request. And when it hears the request is responding with this object, right? It's going from this object, right? It's coming from this object, right? From this object, right? It's going from that request to the server. The server hears that request. We get that information back. We're able to console log it. I'm gonna go over how we could insert the data from the fetch into the DOM, we could just change up what happens inside of the then. Instead of just console logging it, I wanted to edit that actually. Instead of just console logging it, we can do whatever we want. We can do our document.query selector.

01:26:00
We could select, I don't know, let's just say our, All right, let's say we had an image tag on the page, right, we could check our image tag. We could change the source and set it equal to data.message. All right, so that will go ahead. When we get the data back from the DogCEO API, we'll console log what we got. We'll find the image on the page. We'll change its source to whatever that URL was. So let's go ahead and hit it. There we go. It comes back and if we had an image on the page, it would have changed that image to this miniature poodle That's it Well beans we're using Express for the back end, yep

01:27:00
Cool. So we want to get into the back end, but before we get into the back end, we got to talk a little bit about JavaScript. We got to learn a few things, right? Got to learn a few things, right? Got to learn a few things about how JavaScript actually works underneath with the hood before we can do the back end. Yep. Someone's correct. The string into an object, that's what the response.json is doing for us exactly. Cool. All right. JavaScript is single threaded, meaning that it'll process one operation at a time. I like to think about this and this is very rough. It's not exactly, no code weenies today, please, right? This is rough, we're just trying to get, we're trying to teach a theoretical concept

01:28:00
here. Give me some liberty, right? We're thinking about JavaScript as single threaded, okay? And what we can do is I like to think of a paper delivery person, right? Each morning they get on their bicycle and they start riding through the neighborhood. they throw a newspaper at the first, right? Right? Throw it at the first door, right? Throw it at the first door, and then they wait. Wait for the person to get up, to go down the steps, to make their coffee, put on their robe, go to the door, get the paper, and then once they see the person get the paper, where they move on to the next house, right? They get the bicycle off to the next house, right? Off to the next house, they take the paper, they throw it against the door and they wait.

01:29:00
Same routine, the person takes their morning, they come out to get the paper and then they move on. So they're doing one process at a time. This would make the paper delivery person and not very good at their job, right? If they just do the paper and wait it, and wait it, and wait it, and wait it, we want them to continually move on. So there's one way, if we think of the paper delivery person as a single-threaded synchronous process, it would be one operation at a time. We could have a multi-threaded operation, which is where we have multiple paper delivery persons going around. And so we have to think about, is JavaScript is single-threaded, it's doing one operation at a time. And so if JavaScript is synchronous, meaning doing one operation at a time, how do we do stuff like make an API request and keep scrolling, right? Right, how do we like, if

01:30:00
we're on our binary upload boom, how do we like a photo and keep scrolling through the feed, right? how do we, how do we do all this stuff that we'd normally do when writing job or using JavaScript? Like how do we make all these requests? If JavaScript is single threaded, if it is blocking, if it should wait, like it should be the paper delivery person, it should wait until that process is done before moving on to the next thing. But that's not our experience when using the web. We're able to do all this stuff and keep moving, scrolling, clicking, doing all this stuff and we don't get blocked and the answer the reason why we're able to do all this stuff is the environment and when I say the environment I don't mean this 10-second warning

01:31:00
five seconds I mean Boom. All right, we're talking about this. When we say the environment, we don't mean this, we mean this. The environment is our browser. JavaScript is running in our browser. Up until this point, since JavaScript is running in our browser, we

01:32:00
get access to a bunch of stuff that does all the heavy lifting for us, right? So browsers have a bunch of APIs that we can utilize, make requests to, they do all the asynchronous stuff for us, right, because JavaScript should lock. So when we were doing a lot of stuff early on in JavaScript, When we were using the DOM, right? When we were making fetches, none of that stuff is built into JavaScript. The DOM does not come with JavaScript. That document.querySelector, not part of JavaScript, right? Fetch, not part of JavaScript. This is all stuff that browsers come with because we are running our JavaScript in the browser.

01:33:00
JavaScript can use all of these web APIs to do all this heavy lifting asynchronous stuff for us. And if you look, there's a whole list of these common browser APIs or these web APIs. And I remember learning this stuff for the first time and looking at this list and seeing that the DOM, the DOM was one of the APIs that we get access to when we run our JavaScript in the browser. And I lost it, right? I lost it because that document that we wrote over and over and over again, The fetches that we were writing over and over and over again. That does not come with

01:34:00
JavaScript Right does not come with JavaScript All right that document query selector is a web API It is not JavaScript and it always has been So a lot of these things that are doing the heavy lifting for us, right? They're doing the heavy lifting for us that are doing the stuff that is happening asynchronously is because JavaScript is making requests to these web APIs and then the web APIs handle all that stuff for us, do what it needs to do and then returns a response. And so a lot of the stuff that we use in our day-to-day of writing JavaScript is just not stuff that it comes with. This is like mind blowing to me. I can't tell you how many people, right, right. I can't tell you how many people,

01:35:00
I can tell you how many people probably write JavaScript and don't understand the stuff that they're using day-to-day Right day-to-day. Is. Is not built into JavaScript is part of the web APIs. It's part of the running your code in a specific environment, right? You're running your code in a browser, right? JavaScript is not running somewhere else that the JavaScript is running in your browser and the browser we have to remember the browser is a program that is installed on your computer. Let's think about that for a second. Since the browser, right, is a program installed on your computer, right? Firefox, Safari, Chrome,

01:36:00
they are programs that are installed on your computer. And since they are installed on your computer, they have access to what? they have access to your CPU, they have access to your RAM, they have access to the file system, right? Like the program, since you installed it on your machine has access, right, right? Has access to all of that raw computing power. The browser can do the heavy lifting. The browser can be multi-thread. It can do all that stuff we need to do because it actually has access to the resources of your computer. So when we run JavaScript in the browser, we can get access to a bunch of stuff that does not come with the browser. It's all a blur. I don't know if I made this or somebody else made it in the cohort. I think I did. I don't remember. It's been too long.

01:37:00
So yeah, JavaScript can do a lot of the blocking stuff in the browser because it is handing that stuff off to our asynchronous web APIs. So all this stuff that JavaScript shouldn't be able to do, it can do because it's handing that stuff off. It's literally saying, hey, browser, do this stuff for me, right? And the browser is able to take that, that stuff that we're trying to do, use the resources of your computer to get it done and then respond with an answer. Right. And so this is a version of an API, right? Our, our JavaScript is making a request. These APIs built into the browser, hear that request, go off and do some complex, asynchronous stuff, and when they're done, they respond.

01:38:00
But, eventually, those web APIs do indeed have to respond. And how do we handle those responses? We saw with the fetch, that we were using the then chain to handle the responses to a fetch. Well, we need a way of handling the responses that come back from these web APIs. If JavaScript's running in our browser, we're making requests to these web APIs, web APIs are gonna do their complex stuff, and at the end, they're gonna need to respond. And we're gonna need to know how to handle those responses. And JavaScript handles those responses with callbacks, then promises, and eventually async await. Like we've had an evolution of how we handle these responses. Pad, I'm new to programming. Is Python a good

01:39:00
programming language to start with? Hell yeah, it is, it's a wonderful language. However, if you're trying to get a job, the quickest way to a job is definitely full stack JavaScript. You don't have to do context switching. If you're learning Python, you're gonna also have to learn JavaScript, right? If you're gonna be a web developer. And so instead of having to do context switching, We just do full stack JavaScript here. You can do exclamation point 100 devs. We want to learn more about what we're doing here for the beginning. All right. So let's start off with the old school way of how we handled the responses that came back from these browser APIs, right?

01:40:00
So callbacks, you can always have a function that takes another function as an argument. So if we're gonna use callbacks, we have to learn this. You have a function that takes another function as an argument. These are called higher order functions, like functions that take in other functions as an argument. Now, you've seen this a bazillion times when we use things like click events, right? Click events, addEventListener is a function, and when it hears the click, it runs this function, right? Right? It runs this function, right? It runs this function. So this is a function, right, it is a function that takes another function as an argument. Our event listeners, our click events, our smurfs have all been higher order functions.

01:41:00
And the function that we are passing in, the function that runs after the click, we call that a callback. A callback is simply the function that has been passed in as an argument. All right, so we're thinking about our event listeners, right? We're thinking about our event listeners and we have our click event and we have the function that runs once the click is heard. That function is being passed as the argument. We call that a callback. And callbacks really aren't like a thing that's like specified in our JavaScript specification or the ECMAScript specification. It's just a convention. It's like a term for this convention. Cool, callbacks fire when an async task or another function is done, right? Our callbacks are gonna fire when the other function is done. So think about the click event. It

01:42:00
fires once the click is heard, right? And so here's kind of the wonderful callback chain that you can see here, right? So setTimeout is a function, right? Is a function that waits a certain amount of time, right? Waits a certain amount of time before it does what's inside of its curly braces. So here you can see the setTimeout opens. It has this console log of paper delivered to house one, and it's gonna wait five seconds. And once it's done that five seconds, it's gonna run this next timeout, right? That'll say console log paper delivered to house two and once that's done in a call set timeout This is kind of a lovely little callback chain and people passionately refer to this as the pyramid of doom are often recurred to as callback hell Back in the day. This is how we handle stuff,

01:43:00
right? We wanted this to happen first and once it was done, we wanted this to happen So we nested all of our callbacks because we knew that this set timeout could only run after this one because it's a function inside of our function, right? It's a higher order function. It's a function that can only run after this outer function has completed. And so this is how we did this, how we handled these really complex requests happening where we we didn't want other code to execute until other code had executed and it led us to call back home where our code got real messy it got real indented it became a hot mess and this is this is like this is like this is an easy example start thinking about when you really need real stuff to happen real mechanics not just console logging it becomes was a hot mess to keep track of. How long ago are

01:44:00
we talking about? Promises were added to the specification in, was it 2015 with ES6, I think? So we're talking about like seven years ago, plus seven plus years ago, like 10 to seven years ago. And then with that ES6 specification, we got a more readable way to handle our asynchronous code. right? So instead of having to deal with these really messy callbacks, right? We had a promise, right? A promise for a better future, right? And so promises came in on their white horse to save the day, right? And a promise is something that's somewhat hard to grasp at first, but it's really just an object, you know, like objects that kind of properties and methods, just an object that it may have a value in the future. So when you

01:45:00
make a request, you get a promise back, and that promise may not have the value immediately, but once that asynchronous task has, it can have a value in the future. And there are some methods that we use when we're using promises that enable us to handle this asynchronous nature. So basically once the promise resolves, our then methods can fire, right? And so you'll make a request, you'll get a promise. Once the promise resolves, your then will fire. You can think of these as like really fancy, fancy click events, right? It's gonna wait until it hears the click before it does anything. In this case, the then is waiting for the promise to resolve before it does anything. And whenever it does, that value gets passed as an argument. So what the heck? We've seen this before.

01:46:00
I know it sounds confusing, but it's something you've seen before and we can step through it. A promise is like an IOU, exactly. So here is the fetch that we were just talking about earlier. We made a request and what did we see? Chat, do you remember? What did we see exactly as soon as we made the request? What did we notice? We saw that we immediately got a promise, but it had a pending state. Let's see, let's see if we can get that to happen again. So we made our request, right? We made our request. Let's go ahead and inspect. Come on, work the same way again, please. We made our request, boom. Immediately we had a promise, right? Immediately we had a promise, and then eventually that promise resolves, right? It eventually gets the response back from the

01:47:00
server, and once the response is back from the service, sorry, from the server, what fires? What fires as soon as the promise resolves? the thens fire, right? The thens fire, right? The thens fire. And somebody was asking, what is this? Like, why do we need to do like the response.json? Well, the response that we're getting back from the server is not actually organized as an object, right? And so what we're telling here is that, hey, we want like a JSON object from the response that you just got. Like we need it to be an object so we can use JavaScript, right? So we can use JavaScript to like get the data, play with it, do the things we need to do with that data. So we made our fetch and immediately got a promise, right? Eventually the

01:48:00
promise resolves. It has some sort of data that it got back from the dog CEO API. As soon as the promise resolves, we make sure we're dealing with a JSON object so we can actually play with it and use it. And then we console log our data. So this is very, very important. Promises are doing something very, very unique for us here. We saw that the promise was unique, which is really important because JavaScript is what? JavaScript, what is this helping us with? Yeah, JavaScript is synchronous. it's single-threaded, meaning that it can't wait. Did JavaScript have to wait here? It made a request and it immediately got a what? It immediately,

01:49:00
immediately got a promise. Did that promise have its full value yet? No, it just had a promise for some future value. And eventually, once that promise went from pending, right? To fulfilled or resolved, right? Once it resolves, then what happened? What triggered? The then's triggered and then we could do it. Once we had that data, right? Once our promise had that data, right? Right. Once we had that data, then and only then did the dense fire, then and only then did the dense fire. Then, Oh, wow. That's really good. Then and only then did the dense fire then, and then only then did the dense fire. Then and only then did the dense fire then, and then only then did the dense

01:50:00
fire. Hey, does this work? Then and only then did the dense fire then and then only then did the dense fire. Den and only Den did the Dens fire, Den and only Den did the Dens fire, alright cool alright. Alright so we immediately made our request, we immediately got a promise, the promise just didn't have its value yet. Right? It just didn't have a value yet. Eventually some asynchronous stuff happens, right? Some asynchronous stuff happens. The value, right? The value gets resolved. We make sure we're dealing with an object, right? We make sure we're dealing with an object. And then we can do whatever we want with that object.

01:51:00
In this case, we just console logged it. Cool. Can we take off slow mode? I'd be curious to take it off. I mean, office hours, We always have less people like we always have less people so maybe we could try it. I'd be fun just to see the the shenanigans, but Maybe we'll do that the end just to see what it'd be like All right Something to look forward to,

01:52:00
exactly. All right, so we can see this. I think this is a really important concept. This is something that I really, that I really think is important to kind of understand that JavaScript is single-threaded, it is synchronous. We make requests and it doesn't stop, it doesn't block because we immediately get a promise, right? It's just that that promise, right? It's just that this promise eventually resolves. We already got the thing, so that it eventually resolves. And once it resolves, then it fires all these thens. It's the exact same thing as a callback, right? Like a callback would just wait until something was done and then the next function that was the argument fires, right? It's the same thing. It's just like a newer syntax, It's a new way of handling this type of request. And it's really important that we kind of see that. And I

01:53:00
really liked that we broke it down that way. Cool. So in this case, fetch returned a promise. Just like all the other web APIs, like pretty much all the other APIs do the exact same thing. Look at all these web APIs. Canvas, the DOM, fetch, all this stuff. We make requests, immediately get a promise, right? And then eventually that promise will have a value in the future. Cool. So here is us building some like raw promises, right? We're building some raw promises. We have a house one set up as a new promise, house two set up as a new promise and house three set up as a new promise. Basically what I'm trying to build out here is my paper delivery person. I want them to be able to go to each house, right? And move on after

01:54:00
that delivery. And so here, you can see that I have my house one has a set timeout of 1000 seconds. My other one has 5000 seconds and my third one has 2000 seconds. and so what I can do is I can use a promise chain so that when house one is done, it console logs the data and then it calls house two, which then console logs the data and then we call house three, which then console logs the data and if there's ever any errors, we have the catch that catches the error. So this is a good way for us to build out some synchronous, things that should be happening synchronously, asynchronous, right? Like it's gonna wait for one thing to happen before it moves on to the next. And then once that happens, it'll move on to the next.

01:55:00
We're not using callbacks, we're using promises here. And those promises will just call the next thing, right? The next thing when the one before it was done running. And so this would work, like if we copy this, We throw this in our inspector. So we see paper delivered to house one. It's chilling. It's chilling. It's chilling. It's chilling. House two. It's chilling. It's chilling. It's chilling. House three. So it worked, right? Even though these promises all had different values, one second, 5,000 seconds, millisecond, and 2000 milliseconds or one second, five seconds, two seconds, we would expect if JavaScript was synchronous, right, that it wouldn't wait. It would just do boom, house one, house two, house three. Right, it wouldn't

01:56:00
wait. But here, since we're using the promise chains, once one thing resolves, it calls the next. Once that resolves, it calls the next. Once that resolves, it calls the next. We get this lovely one, two, three. Now, the problem is this works, right? This works, but it don't read good. Like having to do like this chaining with promises doesn't actually look too good. Doesn't look like real JavaScript. So I want my asynchronous code, right? Like my stuff that's like waiting for responses to come back. I want my asynchronous code to look synchronous, right? I want it to look synchronous. And so that's where async await came in. Async await is simply a way to handle asynchronous responses. And really it's just some syntactical sugar, right? It's some tactical sugar on top of promises.

01:57:00
Underneath the hood, it's still promises. It's just the async await looks more like our original JavaScript. The way that an async await works is that await waits for an asynchronous process to complete as long as it is inside an async function. So what does that look like? Here we have our normal asynchronous stuff that's returning promises. And down here we have our asynchronous function. Oh, take a look at that. Beautiful, right? Look at this. We have async in front of our function, and then we can just say house one, and it'll wait house one. It'll wait that one second. Then we say house two wait, and that'll wait the five seconds. Then we say house three wait, and that'll wait the two seconds that that was supposed to take. And

01:58:00
it looks synchronous, even though all this asynchronous waiting two seconds, five seconds, one second is happening, It looks like our synchronous code. We can console log it. Oh All right It's training still seen a lot typically you'll see it every once in a while but async away is really replaced this it's just like I Said syntactical sugar Right. It's in tactical sugar that makes this look better All right, it still promises underneath the hood. It just looks like the normal JavaScript that we would write. All right, so then you're like, I need something real. Like this is great. Like you're talking about theoretical newspapers being passed around. What the heck are we talking about here? Well, let's look back at our fetch code. Before we had those like those promises and stuff like that. Well, now we can do it with the async await syntax as well. So we have our async in front of our function. we

01:59:00
have our awaiting of the fetch. Remember fetch is a what? What is fetch? We actually didn't say this yet. Fetch is a what? Fetch is a web API, right? So the web API is gonna immediately return a promise. And the cool thing is that res is now holding that promise. And then we can also make sure that we are using a JSON object. and then we can console log the data. So we don't need those, then and only then did the thens fire, then and then only then did the thens fire. We don't need that anymore. We can use this lovely async await syntax. It looks like the more synchronous JavaScript, but underneath the hood, it's still the promises. Right, still the promises underneath the hood. It just looks like our more synchronous code. I'm not catching any errors here. I would definitely still need a try and a catch

02:00:00
block, right? There are try and catch blocks is that you use with the async functions. There's not one here just for simplicity to see what it could look like. Cool. Dex said, I believe the secret to understanding the concepts of Morris to watch mine and Rufio after hours. That's not a secret. It's what I've been saying for months. If you want to understand this shit more, you should be going to the stream team. There's a reason why we say community taught. There's a reason why I talk about the stream team every freaking class, because if you're not going to the stream team, you're messing up people given time, days, hours of their week to

02:01:00
help you learn these concepts better. A community is going through the hard shit together. Piece by piece, line by line. If you're not going to the stream team, you're messing up. It's not a secret. It's not a secret. That's the point. Community time! Community time! That's the point,

02:02:00
that's the point. I got to manage my frustrations, yes. Yeah, I got to manage my frustrations. All right, let's use a web API and then we're gonna take our top of the hour break and this one will be a little bit longer. I'll be a little bit longer because we've been going for three hours already. Alrighty. So let's use a web API. We're gonna go ahead and use setTimeout. setTimeout is a web API. This broke me. Just so you understand, this broke me. SetTimeout and SetInterval are not actually part of JavaScript. Let me say that again. SetTimeout and SetInterval are not part of JavaScript. It just so happens

02:03:00
that most environments, like all the browsers that we use and Node.js give us access to these things. Like setTimeout, setInterval are web APIs. They do not come with JavaScript. They can't come with JavaScript because JavaScript is synchronous. It's blocking, right? So something that waits literally cannot happen with JavaScript. Something that does something on an interval literally cannot happen with JavaScript. These are not part of JavaScript. These are web APIs. So something that we've seen before is let's say we have this house one, paper delivered to house one, function house two with a set timeout of three seconds, and then house three. So since JavaScript, right, right, since JavaScript

02:04:00
is synchronous, right, since JavaScript is synchronous, right, is synchronous, we'd expect house one to run, house two to run, and house three to run. And will JavaScript wait? Michie, welcome. Will JavaScript wait? No, it can't. It literally can't. Let's run this. Let's look at the inspector, go to our console, paste this code, and this is what we're gonna get. We're gonna see house one, house three, and then house two. There's nothing right now that's set up to wait because JavaScript doesn't wait. JS goes brr, exactly, right? And so

02:05:00
we can see that the very, when house one ran, right, it immediately console logged. Then setTimeout, which is waiting three seconds, well, that's gonna have to happen later. It immediately moves on to house three. We see house three, and then house two finally winds up being console logged. but there was a delay of three seconds. The JavaScript doesn't wait. It just kept going down the page. Now, the really, really tricky thing is when we change this from 3,000, we change this from 3,000 to zero, we would expect that there is no longer a delay. Before there was a three second delay, but now there is no delay by today, right? No delay before is 3000. But now we're saying a zero delay, but when we run this code, we still see house one, then house

02:06:00
three, and then house two, but there was no delay. Why didn't it run chat? Why didn't it go one, two, three? Yes. The event loop. Exactly. The event loop. the event loop is still in play. Meaning that JavaScript has to hand off setTimeout. SetTimeout is a web API. JavaScript is gonna hand off setTimeout to the browser. The browser gives it a promise immediately. JavaScript keeps going. Eventually, the setTimeout resolves, even though it was a zero second delay, it still had to be passed off to the web API, right? And that passing off is enough for JavaScript to just keep on moving. So even though there's no delay by today, it still had to get handed off in the event loop.

02:07:00
So when we come back from break, we're gonna save you from getting got, right? And we're gonna learn more about the event loop. And the event loop is really important because once we understand the event loop, We can understand how JavaScript is able to do all these wonderful things, and then we'll be able to apply these things to our Node environment as well. Right now we're just talking about browsers as an environment, but we'll see that Node is an environment for us to run our JavaScript as well, and a lot of these principles still apply. So, we were talking through this really weird thing that happened where even though there there was no delay, right? Even though there was no delay, it was still going one, three, two, right? One, three, two, right? And so even though there was no delay, something odd was happening. And the odd thing that was happening is

02:08:00
this setTimeout was being handed off to the browser. It's a web API. It's not built into JavaScript. It's being handed off. And since it's being handed off, it has to wait for something to come back from that handing off, that request to the web API, right? And the way that this works is through something called the event loop. All right. So, before we get into the event loop, I want to talk about two very simple data structures. Actually, it's simple, but two data structures that we're going to use. And we're going to use them especially when we get to data structures and algorithms in just a few weeks Or what we're like what two two weeks away from data structures and algorithms. That's pretty wild. So Uh, some of the first data structures and algorithms that we're going to learn about are queues Uh, just like a real queue like you're waiting in Line, right you're waiting in line Uh, the first element was added to this queue or this list is the first element

02:09:00
out So you get in line and the first person that was in line gets out of the line, right? It's called a first in first out structure So queues are a first in first out structure where the first person in the line is the first person out of the line So a quick example of a queue Is just having an array We push two and five into the array We push two and five into the array. So now we have two and five sitting in our array. And then we shift off the first value, which would grab two. So two was the first value into our array and shift will grab that value off because it is the first in the queue. So just thinking of arrays where we had an array set up, we push two in, we push five in, and then shift will grab the first element in the

02:10:00
array out of the array. Cool. Stacks are like, I like to think of pancakes. The last in is the first out. So unless you're a monster, you put your pancakes on the bottom, right, you put a pancake on, and you put more pancakes on top, right? And the last pancake on the stack is the first pancake off of that stack, right? And so this is called a last in first out. The last pancake on top of the pile is the first pancake off. This is a last in first out structure. So an example of this would be once again, and we could use our array where we push two and five into our array. When instead of shifting, we pop it and we pop five off

02:11:00
of our array. So the last element that was put into this array is the first element out. Last in, first out. Cool. So back to getting got. All right, so if we understand If we understand that our JavaScript is running in the browser The browser is Giving us access to a lot of things that enable us to Execute our code. So when we are running our JavaScript in the browser for using Chrome we're using something called the V8 engine that takes our JavaScript and enables us to do a lot of stuff. It is the compiler that enables us to write JavaScript and then have that JavaScript understood

02:12:00
by our actual machine, right? Remember, JavaScript is good for us to talk and communicate, but it's not so great for the computer to understand. It has things like garbage collection and memory management and all this stuff that JavaScript itself might not necessarily be good at or have with it. And it gives us access to a bunch of these web APIs that we've been talking about, right? SetTimeout, SetInterval, Fetch, the DOM, right? And the way that this all works, the way that we're able to run our JavaScript in the browser is that a lot of these events that should be blocking are passed off to something called the event loop using LibEvent, right? And so LibEvent, you can tell is real serious because when you go to their website, this is what it looks like. So if you ever wondered about like how JavaScript works underneath the hood, just trust it's doing something, look at this. Yeah, I'm good. You do you, bro. You

02:13:00
do you. Don Chieh, what's going on? Welcome. This site is disrespectful. So all of this stuff that's happening underneath the hood is what enables kind of our JavaScript to run in the browser, even though it's a synchronous, a synchronous language. All right, so how does this all work? How are we able to use these things that should be blocking with JavaScript? Well, this thing called the event loop monitors the callback queue and the job queue and decides what needs to be pushed to the call stack. Let's take a look at it. All right, so here we have that same bit of code that caused us some tricky things. We have console log house one, console log house two,

02:14:00
and console log house three. Now what we saw was that we saw console logged house one, then we saw house three, and then we saw house two. So it went one, three, two. Even though there was no delay by today, right? Even though there's no delay, it still went one, three, two. Let's take a look at why this happens. We have something called the call stack, where all of our lines of code are going to be executed first. So console log one is added to the call stack, right? Is added to the call stack. And since the call stack is a stack, what does that mean? What does it mean? If the call stack is a stack, what do we know about

02:15:00
it? It's a last in first out. So the last thing on this stack was the console log. So it's gonna be the first thing off, right? And that's why we see console logged house one. That's why the house one gets immediately logged to the console. Now, the second line of code, the set timeout executes. and that's gonna be added to the call stack. Now, setTimeout is a what? SetTimeout is a what? The web API. So, since this is the last in, it's gonna be the first out, but this setTimeout's gonna be handed off to the browser, gonna be handed off, right? It's gonna be handed off to the browser, handed off to the web APIs, and it's gonna be here in this lovely, lovely

02:16:00
little area. It could take as long as it needs to do its job, but the event loop keeps going. We get to the next line of code, which is the console logging of house three. Since that console log goes onto this stack, and the stack is a last in first out structure, this console log has to run. Now, we also noticed that since there was no delay on our setTimeout, the Web API responded instantly, but when the Web API responds, where do those responses go? Do those responses go onto the stack? No, they go into the queue. Now there's the task queue, job queue. There's a bunch of different like micro queues and funds like that. We're thinking high level here. So that response came back from the web API. Now it's sitting in the queue,

02:17:00
but the stack is a last in first out structure. So this is the last in, so it has to be the first out. We'll see printed to the console log three. The call stack eventually runs again. Like the event loop goes brr. It runs again. It takes off that initial main that was there that kicked off the JavaScript. And now that the call stack is empty, where does the event loop look? The call stack is officially empty. Where do we look? Yeah, we look at the queue. We go and grab that response from the set timeout that came from the web API that's chilling in the queue. Call stack is empty. so we look at that queue and we put that on the stack. Since the stack is a last in first out structure, the

02:18:00
event loop runs, it pulls this value off of the stack and we see the last console log in our console. All right, so the idea here is that this first line ran. Add it to the stack. Last in, first out, immediately console log. This set timeout ran, but had to be handed off to the web APIs. That's asynchronous. It can take all the time it needs. When it's done, whatever comes back from it gets put in the queue, but our program kept going on to the next console log, put it on the stack. Stack is the last in first out. So that came off the stack. We saw that lovely house three. Once the call stack was completely empty, we went to the queue to get the thing that came back from the web API. We put that on the stack, it runs and we

02:19:00
see house two. So even though, even though there was no delay by today, it's still had to be handed off the web API the response still had it to be put in the queue and we only get stuff from the queue When the call stack is empty Put that on the stack exactly So some folks are asking kind of like why task UI, Java Q, this is just a way of, this is just a way of handling, handling JavaScript,

02:20:00
knowing that it's synchronous, this, this execution context, the environment in which we are running JavaScript gives us access to this event loop so that we can use this synchronous language with a bunch of asynchronous stuff that needs to happen, right. So we all go to get help on discord but sometimes we have to go over to stack overflow. What the heck is stack overflow? Well, this stack can hold a lot, right? This stack can hold a lot, but we're constrained by the resources of our what, right? We're still constrained. Where is this still technically

02:21:00
running? Where is this all still technically running? Running on our computer, right? This is running on our computer. Our computer can only handle so much. So much memory, so much stuff, right? Right? And one of the things I always love to do with my students in meet space, I really can't do it too much digitally because then you would all just disconnect from Twitch. But one of the first things I have my students do when we're in person is run an infinite loop with a bunch of set timeouts, right? Eventually you add so much to this stack, you add so much to the web API queue, you add so much to the task queue that your computer just can't keep up and it turns off, right? Chrome now has like things to stop this from happening, but back in the day, like this is still real resources that are being used and you can run out of resources,

02:22:00
right? Cool. And just think about all this stuff is happening, right? Like all of this stuff is happening lightning fast that we can see cute dog photos. I love it. All right, it's time to get into some backend baby. So let's talk about some backend. All right, now we just talked about this. All right, we just talked about this. Does JavaScript have access to the DOM natively built in? Does JavaScript have document, query selector, all that fun stuff? No,

02:23:00
nope, JavaScript does not have the DOM built in. All that stuff is a web API. Now, JavaScript needed web APIs to handle the async stuff and a bunch of the other stuff in the browser, right? A lot of the stuff that would normally be blocking that would cause JavaScript to stop running, we needed those web APIs. And the only reason we had those web APIs was because JavaScript can only do what the hosting environment allows. And when we're using the browser as our hosting environment, we get access to things like the DOM, setTimeout, setInterval, all those wonderful things, right? So JavaScript is a language that can only do what it's hosting environment allows. A lot of the stuff that we use day to day in terms of JavaScript isn't actually JavaScript. It's just what the hosting environment allows us to do.

02:24:00
So if we're going to talk about the backend and backend web development, you got to ask a very important question. What do servers need for their role in the kind of how the internet works building out these full stack web applications? Like if a server, if a server is gonna hear requests and generate responses, if it's going to store stuff into a database, if it's gonna serve up files, like at a very, very, very basic level, our servers do some very specific things. And one of the most common things we might use a server for is to serve up some files, right? Like we go to a website, when you type in a URL and hit enter, you have made a request to a site, that site then responds with some information, responds with some HTML, it responds with some CSS, it responds with some JavaScript. And so if a server is going to actually serve, well, it needs two

02:25:00
very important things. It needs access to the disk. Remember, I think a lot of us forget that those files that we're serving up, the HTML, the CSS, the JavaScript that we're serving up, that exists somewhere that's on a hard drive or a solid state drive somewhere on that server, right? Like it's not magic. Those files have to be stored somewhere. And when the server hears the request, it has to grab those files and respond with them, right? And then if it's gonna hear the requests come in and it's gonna respond to those requests, well, then it needs access, right? It needs access to a network, right? Right, it needs access to the network. If it's going to hear those requests and generate those responses, well, it needs access to the network to hear those requests and generate those responses. So our servers, our backend would not be able to do the things

02:26:00
that it does at a fundamental level without access to the disk or without access to the network. And so what if there was a hosting environment, right? a hosting environment that allowed JavaScript to have disk access and network access. Let me ask you this. Does JavaScript have access to the disk? Nope. Does JavaScript have access to the network? Like can a JavaScript file on your computer just like start accessing stuff when you, no. Every website we would go to would be horrible. If every website we go to that JavaScript could just like start reading files on your computer, just it doesn't have access to those things. So if we're going to build a server that can pull files off of the drive, that can listen to the network, we're going to need a hosting environment that enables us to do that. 10 second warning. And so the hosting environment, five seconds, that enables us to have disk access, Network

02:27:00
access All right, Sullivan said, Leon, does it mean that using the async await, the web API goes to the web stack from the call stack and returns immediately to the queue and then the call stack while the synchronous process is kept on wait? So the way that this is still working, async await is just promises, right? It's just promises, right? It's

02:28:00
just promises. And so, when we add something like the setTimeout, right? We add something to the setTimeout, JavaScript has a promise. That promise doesn't have a value until we pull something off of the task queue. So it gets handed off to the web API, it does its thing, but we still had that promise immediately. And then eventually the promise resolves when we pull something off the task queue. If you really want to know more in detail, like I'm saying, I'm giving like a very high level, very skimming the surface of how the event loops, cause I just don't think it's super, super important for you to understand, right? But if you really want to know the event loop, I shared two really amazing videos on the event loop on Discord. They were actually part of the homework. And so there's Jake Archibald's video and I'm blanking on the other ones, the author's name, But they're both on discord if you just type in that loop on discord

02:29:00
You'll see both of those videos highly highly highly recommend that you watch both of them they go in way more detail than I could ever get about the the event loop and in fact the The the example I gave you is a very similar example that comes from those two videos that I shared Yeah Cool All right, so Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. Philip Roberts, thank you. Philip Roberts is the other one. Thank you so much, Kevin. What? Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. Why? All right, basically what they're trying to say is the same shit that lets you run JavaScript in the browser can now be used to run JavaScript on

02:30:00
servers, desktops, and everywhere. So when they say JavaScripts, Node is a JavaScript runtime, all they mean is that Node is a place to run your JavaScript. Just like we were running JavaScript in the browser, Node.js is a place to run our JavaScript. Because remember, JavaScript doesn't come with a lot of goodies, it's synchronous by default. And so when we run it in the browser, we get all these goodies. So Node.js gives us all the goodies as well. and it's built on Chrome's V8 JavaScript engine. That's the same thing that enables JavaScript to run in our browser. Basically, the V8 engine gives us the compiler that breaks our human readable JavaScript down into something that the computer can understand. It gives us access to garbage collection, memory management, all that fun stuff. All right, we learned from the true story that is Independence Day that our

02:31:00
code has to be broken down into something that the computer can understand, right? Computers don't understand, right? Computers don't understand JavaScript. JavaScript is that we as developers can communicate ideas with each other and build applications, but that has to be broken down to something that the computer can understand. And Node uses the V8 engine to do this. Now we're saying engine and not compiler because V8 comes with more stuff than just the compiler, more than just the stuff that breaks our human readable code down to something that the computer can understand. And just like the browsers came with web APIs, node comes with a bunch of stuff as well, right? So node comes within a bunch of built in modules, which are kind of just like libraries or collections of functions that do all this heavy lifting for us. Node comes with a bunch of code already written

02:32:00
that enables us to handle incoming requests and generate responses. It comes with the ability to access the file system and it stores all these functions that enable us to do these things into modules. So right off the bat, we'll use the HTTP module and the FS module to listen to the network and to get file access. Now, the other cool thing is that Node is really extensible because there are millions of other packages that you can use to do all these really fancy stuff. And so packages are really just groupings of one or more of these modules that do the heavy lifting. and by installing packages, you get a lot of extensibility to make your Node environment be able to do a lot more than it originally comes with. Cool. Now, the thing that's doing these heavy lifting is no longer web APIs, right? Before we used to hand off stuff to the web APIs, but with Node, it's

02:33:00
really just C and C++ APIs, right? And so what that means is all the stuff that's doing the real heavy lifting, that's really doing the like giving us access to the network, that's listening to the file system, that's keeping opening connections, that's doing all this stuff, is actually really built with C and C++, which makes Node somewhat fast, right? It makes it fast. Now, could it be faster? Yes, and there are other environments that enable us to run our JavaScript that are trying to make things even faster. So the big talk right now is something called bun. Bun is just another environment in which to run your JavaScript that gives you these goodies that Node gives you. Access to the file system, access to HTTP. And what they're doing is they're rewriting a lot of these APIs from scratch to be faster than the original stuff that came with Node. Nowhere near ready for prime time, but it's

02:34:00
interesting to have an idea of how things might get faster in the future. Cool. It was like, that's really interesting. What's your thoughts on Dino and all that stuff? I think they're cool. I think they're fun. I think theoretically these are fun things to like learn about and think through. I spent a lot of time with Bun and just trying to see what they're doing, trying to look at some of the code so I can maybe figure out what's actually happening. But for me, none of these things are ready in prime time. As an, hold on, let me check on these dogs real quick. Whoop, right back.

02:35:00
I have the smartest dogs in the whole wide world. So my wife was trying to come back into the house and I guess they were struggling with the door. So my one dog comes into this room, like opens the door into this room and leaves so that I could come to help with the door. Like didn't come to me. They just opened the door. Other one starts barking, comes to get me. And then wife comes back in. Like what? And so that's what they were barking for. I love it. All right. So a lot of these things are fun, right? Like no, like learning about

02:36:00
Dino and bun are fun. Um, but for me, I'm not ready to use them in prime time, right? Bun's nowhere near ready for you to use in like production level code. Uh, it's not even at as 1.00 yet. Um, and for Dino, even though they're there, I don't want to have to worry about edge cases. Right. When things don't work, I want, I want years and years of stack overflow, right? I want years and years of stack overflow and people that have been building on top of it. If that's what my business relies on, right? So for me, uh, I'm always kind of slow to adopt the latest and greatest, unless there's something that's really essential for me to continue to build products. And the thing is that none of these are essential yet. Um, yeah, uh, and so as in different as saying right now, yeah, Dina doesn't have enough market to grab market grab

02:37:00
to matter yet since they're not really there yet. Uh, it's not something I'm going to use in my products, my projects. Um, some folks really like to be on the bleeding edge, the cutting edge, using all the latest and greatest tools. Not for me. I want to be able to build stuff, um, that works. There's battle tested that I don't have to guess and figure out. And, um, yeah, I don't, I don't like to chase a lot of the latest and greatest until there's a really strong community around it. Yeah. Lord Coco said pioneers die, settlers prosper. Yeah, that makes sense. All right. So we're building on top of a lot of these like really fast kind of, um, standard libraries, which makes writing node or writing JavaScript that runs in our node environment Really suitable for being on servers because all this stuff has to happen fast, right? These requests need to get the responses and back in under three seconds And

02:38:00
if it takes more than three seconds, well, guess what people bounce All right So if you haven't installed node, you can just go to the main website click install node and you'll notice this is a this is an older photo, but Now you'll notice that there are a couple different versions of Node, there's the LTS, the current and the nightly. So LTS is the long term stable, it's the version that's going to be supported for the longest period of time. Remember, people are using Node to build their businesses on top of, and so you want to know how long the developers are going to commit to maintaining that version of Node. So you'll see that some versions are in current development Then they go into like their active phase and then they go into their maintenance phase and this is an older photo I think 818 is the current version right now, right? Actually, let's just look No

02:39:00
I click the back button instead of instead of going back on my keyboard Yeah, so 18 is the current version, 16 is the LTS, which is the long-term stable. It'll keep getting maintenance, security updates, all that fun stuff for the foreseeable future, but all the newest features are in 18. So sometimes you might need like a new feature that comes in the node ecosystem might fundamentally change your business and you might start using 18 but most folks are going to build on top of 16 and not have to worry so you can kind of quickly see like when they're going to be maintained till so like you can see that node 12 is still just kind of came off of its maintenance period node 2014 is still maintained into 2023, right? And 16 will be maintained for a very long

02:40:00
time. Most folks that go through the program stay on the LTS while they're doing it, but being on 18 won't really impact you at all for this program. Just know that when you join a company, your company might be on a specific version of Node that you would have when you set up your environment, right? When you get that sweet new computer from your org, one of the first things you're gonna have to do is set up your environment. And that means like setting up the version of node that they use, all the same tools that they use, right? And so that's where this comes into play. Now, if you wanna live on the bleeding, bleeding edge, you can use a nightly release, which is where all the stuff that just got built is thrown at you, but it could break easily. Current is like all the cool stuff that's already happened, and a little bit more tested, a little bit more stable, then ALTS is the actual long-term stable version. Cool. All right, so let's look at a very

02:41:00
simple Node server. So a very simple Node server can just use the core modules, right? HTTP and FS, the core modules that come with Node, We require that module for HTTP. We require that module for FS. And then here is using that module. Modules are really, you can just think of them as an object that has a bunch of functions and properties or properties and methods tied to it. So these modules are just files that are big objects that come with a bunch of pre-written functions so that we don't have to write all this stuff from scratch. and in the HTTP module comes with the createServer method. How can I tell that createServer is a method?

02:42:00
Tucker said, oh nice there, it was all so simple back then. Yeah, we can see that there's some dot notation and then we see the parentheses, right? Parentheses opens, parentheses closes. So createServer is a method. And we can tell it's a method because it's a function tied to this HTTP object. There's dot notation here. The reason why I started off by talking about objects, right? Right? The reason I started by talking about objects and methods is because when we're writing code in our node environment, it's still the same stuff. It's still the same stuff, right? And so we have this lovely HTTP object that has a create server method. And then this create server method enables us to create our server. And then we have the ability to use the FS module to get actual files off the server. So if someone goes to our server that's currently listening on port

02:43:00
8000, just by running the code, they will go and require the FS module to find the demo HTML file and to respond with that file. So if you were running this code on your server, it would enable folks to make a request to the default port 8000, sorry, the default route on our server, and it would respond with this demo file.html. So if you just wrote this very simple code, you have now built a full stack web application. in 10 seconds, five seconds.

02:44:00
That's it. If you get this line of code to run, you're a full stack web developer. Everything else from this point forward is making your life easier. It's adding systems so you can get stuff done. It's adding systems that you can work with other developers, but it's all it's about improving your quality of life. So if you're new or you are, or you are part of the Ketchup crew and haven't gotten here yet, you can run and execute this line of code, open up your VS code, pop this in, right? Create a HTML file called demo file HTML, do node and then whatever the name

02:45:00
of this file is, and you are a full stack web developer, right? Everything else, everything else is making your life easier. Cool. I've made full stack apps and still don't feel like I know anything. Welcome to the club. There's always more to learn. And that's the beauty of being a software engineer. No one person can know everything. You're always learning something new. You're always standing on the shoulders of other people's code. A lot of folks get down on themselves because they feel like they're copying and pasting too much, that they're not doing real work, but that's what we do. We use libraries, we use frameworks, we use things that other people have written to build the things that we want to build. At the end of the day, as long as we're building, we are doing what our role as a software engineer is. There's always time to go deeper. There's always time to learn more if you choose to, but at a very

02:46:00
base level, even when we're using such bare methods, the core node methods, you could spend your whole career on just really optimizing the HTTP method. In fact, there's literally people, right? There are literally people right now that are just spending their time, right? They're literally spending their time, right? to rewrite these core modules, right? That's what Bunn is doing. They're literally a whole organization that's just nerding out about these little things to make the environment faster, right? So we stand on the shoulders of giants and it's always okay to reuse, to build, because at the end of the day, the companies that hire us, hire us to solve problems. It doesn't matter what tools we use or how we use them, is do we get the job done? Do we build stuff or not? Do we serve up stuff for our clients or not?

02:47:00
Cool. All right, so that's a very simple backend, right? All right, let's look at like a Squidward back end, something a little bit more complex, you know, a little more to it, you know? So how would we clean up this type of back end? Actually, let me pull up that code. I don't think I shared that code, but let me pull up that code. Let me show you a more complex backend here, right? So here's a little bit more of a complex backend. We're still using the

02:48:00
raw HTTP methods, still the raw FS methods. We're also using some of these other raw methods that enable us to like look at URLs, enables us to look at the strings that are part of the URLs. And we've done this in class. We went over this a bazillion times. So I'm not going to kind of do it right now with us. So if you're like Leon, this is, we have, I don't remember this full class on just using these core methods to build stuff. If we look at this, we have this lovely create server method. And what we're doing is we're checking to see the different requests that are coming in. Is it the root route? Is somebody trying to go to some other page? I try to go to some other other page. Are they trying to go to the API? Let's actually run this code. So let me go ahead and open up my terminal here. And let's go ahead and just do node. And then the name of this file, this name is called server.js, right? This is called server.js. Node will try and run this server

02:49:00
.js file. And if it works, I should have a server running on port 8000. So let's go ahead and run this. Looks so weird after using Express, exactly. Also looks weird because I don't have any notification that my server is running, but how can I tell that my server is running? How can I tell? Yeah, the REPL, I haven't gotten back my REPL to write another command. There's no place for me to write another command. So I know that this code is running. So let's go back to the browser and try seeing what happens. Localhost 8,000, and there we go. We have our very simple application. And when I went to this main route, the code that executed was this line right here. Hey, they went to localhost 8,000 on the root

02:50:00
route. what I need you to do is to grab this index.html, right? Grab this index.html and respond with it. So when they went to localhost 8,000, we were able to use that FS module to grab that HTML file and serve that up to our users. At the most fundamental level, this is what a server does. It hears that request and serves up the file. Now, the cool thing is if we look at this index.html, it makes another request. It's requesting our style sheet. And so since it's making a request for our style sheet, our server needs to be set up to hear that request, right? So if we look at our server.js, we can tell it works because we're seeing a red color here. So we have to look through this and be like, all right, boom, boom, boom, boom, boom, boom, boom, boom, boom, boom. All right, here we go. If you're asking for the style.css,

02:51:00
grab this CSS file and respond with it, right? So every single request is just here in this massive conditional. And when it's very, very simple site, right? When it's something that's very simple, there's only a few things that you're doing, this could work, right? We could build very simple servers, very simple sites that build off of this principle, right? Just every route, every file, every request is its own part of the conditional, but it's so messy. There's so much complicated stuff going on here. It'd be really hard to build off of this. Like if it was your job to just make this specific page work and somebody messed up somebody messed up a request right somebody messed up a request we'd be in a bad spot all right we were looking at this server and we were talking about each

02:52:00
and every single request right each and every single request right Each and every single request, we had to hand code. And the problem with this being all one big, massive conditional is what? What are some problems we can run into with this being all one big, massive conditional? It's ugly. Yeah, it's not manageable, it breaks easy, it's hard to read, it's confusing. It's not manageable when you're working with others specifically, right? Like if we're working together and like you bork this like piece right here, will any of the other code below it run? No, it's also not modular exactly, or there's a lot of repetition here.

02:53:00
There's a lot of unneeded complexity that gets in the way of us writing our application. So does it work? Yes, could you build a fully featured full-stack application with raw? node modules absolutely kid but How could we clean this up How can we make it so that code is more manageable that has a little bit something that that other folks that? when they come and work on our projects, that come and work on our projects, could work with us well? Yeah, Express. So Express helps us clean up this hot mess of code, right? Helps us clean up this hot mess of code. For those that don't know what Express is, Express is a fast, unopinionated, minimalist web framework for Node.js with a myriad of HTTP utility methods and middleware at your disposal, creating a robust API

02:54:00
is quick and easy. What? What? Why do people talk like this? All right, fast. Fast means it's fast, right? Like it's not slow. We get that one. Woo, got the first one. Unopinionated. What does unopinionated mean? What the heck does that mean? Do what you want, exactly. It doesn't really care how you use it. It doesn't care what you bring along with it. Express does

02:55:00
one thing and one thing really well, which is help you build out your API, but there's no specific way that you have to use it. They don't care how you use it. They don't care what you bring along with it. It just gets out of your way. It's minimalist. It's just the web framework. It's just for helping you build out your API. There are definitely more opinionated frameworks that do more for you. So one I've been playing with recently is called Adonis. Let's actually look up Adonis. So Adonis is a fully featured web framework for Node.js. And so it comes with all this stuff. Routers, controllers, file uploaders, validators, a template engine, right? Let's think about that. All this stuff that comes out the box with Adonis. Router, we're using the Express router because it's

02:56:00
helpful, but we could use any router that we want. Controllers, we kind of build our own with Express. Like we're not locked into a certain way of building our controllers. Express, you just kind of use it. File uploads. Did Express like really care about our file uploads or are we using something else? What are we using for our file uploads? Molter, exactly. We're using Molter, right? So Express didn't tell us to use that. That's something we picked up on our own. We're doing kind of the validation already on our own. We were doing it with like our signups and our logins. we were handling all the validation and stuff like that. And then there's like some other, this is actually something different, but that's kind of a good idea. And then the template engine, what were we using? We were using EJS, but we could use pug, we could use something else, right? So Adonis is opinionated,

02:57:00
right? It comes with some ways that it wants you to do these things, right? It comes with some ways that it wants you to do these things. It comes with some decisions that have kind of been made for you about how you're going to use this framework. And so this would be a more opinionated framework, whereas Express would be unopinionated because it lets you pick whatever the heck you want. Right, it lets you choose the things that you want to choose when you're dealing with Express. And so some folks find that freeing and some folks find that limiting, right? It depends on the team that you're on. Minimalist means that it just handles the building of the API. And so has a myriad, a lot of HTTP utility methods and middleware. Middleware is just the stuff that sits between the request and the response enables us to build our API. Remember the API, the request comes in, our server hears the request, what do we do to respond?

02:58:00
That expresses job, right? Expresses job is just to handle building that API. It doesn't care how you do anything else. It doesn't care how you do validation. It doesn't care how you use different templating languages. It doesn't care how you do file uploading. It's just the request response architecture to build out your API. Is there a class on Moulter? We haven't really gotten to it yet. That'll be Tuesday. Tuesday we're gonna look at Moulter and Cloudinary Binary in detail because we just haven't gotten there yet with binary upload boom. Sounds like express with extra steps. So if you're talking about Adonis, yes, it is expressed with extra steps, but there's a specific way that you're buying into when you're using Adonis. And if your team all buys into that way, you might be able to build stuff a little bit faster. So that's why some people like opinionated frameworks, because there is a way of doing

02:59:00
stuff. And some people find that, especially when you're newer, right? When you're newer to development and you don't really know what's out there, having someone out there say, just use this templating engine or just use, uh, this way of talking to your database or just use, uh, this way of storing stuff in the cloud, right. Can be a little bit of, a little bit freeing, right. It's literally telling you what to do. And so some people enjoy that, but we start with express. It's the most common thing you're going to see, right? And you're going to be able to have the freedom to use the different bits and pieces that you do. And when you join a team, your team might use a more opinionated framework. ROR or Ruby on Rails was one of the really first big frameworks that really became super super popular. It's very opinionated

03:00:00
and people call it magic, right? There's a lot of magic that happens when you use Ruby on Rails where things just work, but you might not really know what it's doing underneath the hood, right? You might not know what it's doing underneath the hood or how it's doing it, but you don't care because it's doing the thing you need to do it. Another version of that is Laravel for PHP, where it's doing a lot of the heavy listing for you. It's a lot of magic that's doing all these things and it kind of just works. So web frameworks can be really nice. We start with Express so that you understand what all these different pieces bring to the table, and then you get to choose between something more opinionated. I see a lot of Ruby jobs, yeah, because it's been around for a really long time. So a lot of companies have

03:01:00
been using it for a very, very long time. And so in a lot of specific locations, Ruby on Rails is pretty heavily relied on, but there's definitely more, if you look at legacy exactly, a lot of legacy code bases are Ruby on Rails, but it's definitely not as popular as it used to be, especially now that JavaScript and JavaScript frameworks and things like that are a big deal. But there, that's why I think it's really important to know your local area. And this is gonna be something we talk about when we start the hunt, if you're applying for jobs in Boston, it makes sense to have a quick Ruby on Rails tutorial project in your portfolio. Cause there are just so many legacy companies that have used Ruby on Rails in Boston for so long. And a lot of different locations have different, different pockets of technologies that they use that are really popular. So certain places PHP is really popular. Some places Java

03:02:00
is really popular. And so while we're using JavaScript and full stack JavaScript as our base, once we get to the hunt, once we get to the hunt, you might take a weekend to do a Java tutorial, or you might take a weekend to do a Laravel and PHP tutorial, or you might do something that's specific to your area because it might give you that leg up when it comes to the job search. And so that's something that we'll, we'll talk more as we get into the hunt, but that's something you should expect to do is to like, have a deep understanding of what's happening in your area. Cool. Uh, but before we start using express, let's talk about how the internet works. Let's talk about how the internet works. Let's talk about, let's talk about requests and

03:03:00
responses and what actually has to happen as we build out our API. So our API is just a set of rules that allow programs to talk to each other. The developer creates the API on the server and allows the client to talk to it. This is from Zell's tutorial on CRUD APIs. If you have not gone through Zelle's tutorial on CRUD APIs yet, you must absolutely walk through that tutorial. It's definitely a doozy as your first intro, but it has so many important bits and bobs that come up through the rest of the program, and so definitely worthwhile giving a read. Cool. So if we're talking about how the internet works, we're gonna be making, we're gonna be making, the link is in the slide, so you just click in the slide, Anytime you see a blue text in the slides, anytime you see blue text in the slides, that's clickable. Yeah. Yeah. I need to do Zelle again now that I understand it better?

03:04:00
Absolutely. That's one of the most important things you can do as a developer, is one of my favorite things to do is to go back through the stuff that gave me trouble and feel like a boss, right? Or at least pick up new stuff each time. One of the most wonderful things about building these lectures is going back through material I've already learned and trying to think of new ways to like teach it to others. And that concept of like, see one, do one, teach one is really, really important. It's, it's one of the ways that you'll solidify concepts forever in your brain. Uh, there are some things that like, like one of the, one of the very common interview question is tell me about OOP, right? What is encapsulation? What is abstraction? What is polymorphism, right? What is inheritance? And a lot of folks struggle with that question because that's what you think about every single day. But once you've built a lecture on OOP, right, once you've built a lecture on

03:05:00
MVC, right, those things stick in your brain a little bit better. And so, uh, the, the aspect I love about community taught is that you You should be taking time on discord to answer people's questions. Not necessarily for them, but for yourself, right? Answering somebody's question, figuring out a way to explain something in simpler language, right? Really helps these ideas cement. It is a form of active recall. it is a form of spaced repetition, and it's a way of building these like new ways about thinking about problems. And when you do that, it sticks in your brain. And so I really encourage you to be active on discord, just not even to get help with your questions, but help answer other people's questions. Right? And don't be afraid if like somebody's already answered something to like, maybe explain

03:06:00
it in the way that made sense to you, right? Because you explaining stuff in your own words might click for someone. All right, so we have these different kinds of requests that might be coming into our servers. We have create requests, we have read requests, we have update requests, and we have delete requests. So we can create, read, update and delete. So typically we'll hear these create requests called posts. We'll hear read requests as gets and we'll hear updates as puts and we'll hear deletes as deletes. Now, the reason why we have these different methods, this post, the get, the put, delete is because we're sitting on top of some very serious technologies, right? We're sitting on top of HTTP,

03:07:00
we're sitting on top of TCP, we're sitting on IP, like all these technologies that make the internet work, the methods that those technologies understand are the posts, the gets, the puts, the deletes, the patches, all these wonderful stuff, okay? Now, we call it creating, reading, updating, and deleting because it's a little bit easier for us to communicate our ideas to others when we're talking through it, But our applications pretty much every single web application that you will build is really just doing these four things Over and over and over and over again, right? DHH DZ a thank you for the hydration Cheers to you It's wild that credit is just the kind of convention exactly it is kind of All right Cool, so we can think about every major application is really just doing these four things. You're either trying to create something, you're trying to like read or get

03:08:00
something, you're trying to update something, you're trying to delete something. No matter what, no matter what type of request, it really breaks down to these four types of things. Different A, have a good rest of your day. Thanks for hanging out with us for so long. We gotta catch up. Big things coming down the pipeline. I need your help. All right. So we're going to take a look at some apps that do this crud, the creating, the reading, the updating, the deleting. And we're going to need some other bits and bobs in our flow. If we're going to really understand how these applications work. We know that we can create these different types So request, creating, reading, updating, deleting. But we're also gonna need a place to store stuff. That's why we're using MongoDB. MongoDB is the database that we start off with. We'll have a little bit of Postgres at the very end of program if we have time. So MongoDB is the database we're using

03:09:00
right now. MongoDB is wonderful because it's made up of collections and each collection is made up of documents and documents are really just what? Objects. They're just objects. So if you know how to use objects, you know how to use MongoDB. And that's what makes MongoDB beautiful. We have the ability to simply have these wonderful documents. We can pull them out of the database and use them just like the objects that they are. That's how we started off with reviewing objects because if you understand how objects works, They have properties, right? They have methods and we can use dot notation to pull stuff out of them or to consume them. You can use MongoDB as your store. Right. We're going to use EJS as our first templating

03:10:00
language, right? EJS is what we're going to use. It's just a template. We can plug data into it and that will eventually render and spit out HTML, right? it'll render and spit out HTML. And so I like to think of EJS as just a really fancy Mad Libs, where you have like this template, you plug data into it, and that's it. And so EJS for some folks is really tricky at first, but it's really just understanding that it's HTML that you can plug JavaScript syntax into. And the way you plug in this JavaScript syntax or with these b-stings here, you can open a little bit of JavaScript and close a little bit of JavaScript with these b-stings, right? And we can actually plug in individual variables with these different b-stings here. So once

03:11:00
you get comfortable with those two bits of syntax, opening blocks, right, opening blocks of code and inserting individual variables, you can build out any site that you want, right, any site that you want by just plugging in the data that we're getting, that we're getting from our MongoDB. Now, let's talk through a simple application. I had here walking through the original rap names application that we had, but I might I might skip to a to-do list.

03:12:00
Let's take a look at the original. Let's take a look at this wrap names list. Actually, no, I'm gonna skip right to the to-do list. I think this is part of the review. We can save some time here by jumping right to the to-do list. I know that that's a little bit of an extra step, but if we look at our to-do list, we still have these, we still have these create posts, right? Create, read, update, delete, and we still have this normal structure. So, I'm going to jump past the wrap names, and I'm going to jump right to the to-do list. Yeah. All right. So, if we're going to plan out a to-do list, right? If we're We're gonna plan out a to-do list, right? We're gonna plan out a to-do list. What are some things that we're gonna wind up creating? What are some things we're gonna wind up creating?

03:13:00
To-dos, yeah. If we have a to-do list, we're going to wind up creating some to-dos, right? some to-dos that are gonna go on our list, the actual tasks, the items that go on our to-do list. Nice, so our application's gonna have some creating and that creating, we're simply creating the to-dos. Now, what about reading? What is the read request going to be for our application? What are we reading? What are we getting? Yeah, we're getting the list of to-dos. Like we want to be able to get those to-dos, ideally probably from our database, right? And show them to our users.

03:14:00
Nice. How about updating? What could we update? What is something we might update about our list of to-dos? Yeah, whether or not we completed that to do so we could have like a to do that's either completed or not complete, right? And so we could we could update our to do's as to whether or not they are completed, right? So we have a to do list, each item will be either completed or not complete. And we can have a delete request. When we're deleting, what are we doing? What are we doing in our to-do list when we're deleting stuff? Yeah, we're actually like removing those to-dos. Like

03:15:00
we're deleting those to-dos from our application. Now, as we learned with binary upload boom, maybe we're not actually deleting those things. Maybe we're just kind of like marking them to not be shown so that you think they were deleted, but we still retain all the data for nefarious purposes. I mean for our purposes, right? But in this idea for a very simple to do list, we're just like deleting that to do. Cool. All right. So here is the structure, right? The structure of our application. We are going to have a client that is consuming the application from their client side device, whether it's their laptop, whether it's from their mobile phone, whether it's from their desktop, we have a client that's going to consume our application. And from this client-side device, they're going to make what to our server? They're going to make what's to our server?

03:16:00
They're going to make requests to our server. Exactly. ElectroCodes, hey, thank you for the tier three. I appreciate that. They are going to make requests to our server, right? Now, there is some code running on our server. There is some code running on our server that hears that request. What do we call the code that is running on our server that is set up to hear those requests? Yeah, we call that the API. There is some code running on our server that is set up to hear those requests and we call that code our API. Our API, right, our API is gonna be set up to hear

03:17:00
those get requests, the post requests, the put requests, which are our updates, and the delay tang requests, which are our deletes, right? And that code will be set up to do different things as those requests come in. We are in control of writing our API. As the request comes in, we get to control what happens when we hear that request. They are server smurfs, exactly. They are very, very fancy event listeners. They're listening for an event, however, this event is a request. When it hears a GET request, we get to code what happens. When we hear a POST request, we get to code what happens. When we hear a PUT request, we get to code what happens. and we hear delete because we get to hear, we get to control what actually happens. So if we were to walk through our very simple to

03:18:00
-do list, right? Let's talk through what a get request might be. What would be a get request for our to-do list application? We want to see the list, right? We try and load the page. We want to see the to-dos, exactly. Just trying to load the list would be a get request. So maybe our server is running on localhost 2121. Right, 2121. So we load that root page. We just go to the server, reload that root page, we make a request, right? We're going to make a get request from our client side to our server. The code that hears that get

03:19:00
request is a part of our what? The code that hears that get request is a part of our what? Our API, exactly. So that API code, right? That API code is sitting on our server. It hears that get request. What's the first thing? We get to write all the code. There's gonna be a lot of code, right? A lot of code that's sitting with this get request. So much code. What's the first thing that code's probably going to do when it hears the get request? Where does it need to go to get our to-dos? Yeah, it needs to go to the database, right? It needs to find its way from hearing that request to our database. And in the beginning, we were kind of just hard-coded. We weren't using models or anything like that. We were just raw

03:20:00
writing these requests, right? We were just raw writing these requests that would go to a specific database, that would go to a specific collection and would find all the documents, right? So we can hear that get request, we can go to our database, we can find all the collections, sorry, find all the documents in that to-dos collection. And once we have all these documents, these documents are really just what chat, these documents are just what? I get hype when I talk about this. This is mind blowing that you understand even just half of what the fuck I'm saying right now. Like if you understand anything that's happening right now, Like, just think about that, right? First time I heard this was so confusing, now not so much. I love that. Yeah. Each of these documents are really just an object. So we heard the get request. We went to the MongoDB database, right? We found all the documents. Now we have all

03:21:00
these documents that are just objects. Where do we send all these objects to? We send them to the EJS, right? We pump all this data into our EJS template. Our EJS template is just a template, right? It has something that says hello, and then a space that we can plug data in. So this first person's name was Bob, this other person's name was John, right? We're able to grab that data and plug it into our template so that it says, hello, Bob, hello, John, right? So all it is is a template we're plugging the data into. So our EJS, we know if we're gonna show a to-do list, somewhere in our EJS is the makings of a list, right? There's a UL, right? A list, right? And we're just gonna plug each bit

03:22:00
of data. Let's say this to-do was bread, this was milk, this was peppers, and this was rice, right? These were our to-dos. What we're gonna do is we're gonna grab these individual documents, boom. Plug in bread, plug in milk, plug in peppers, plug in rice and once we're done plugging all this data into our EJS template, what does our EJS template spit out? It spits out HTML. It spits out that lovely HTML and once we have the HTML, what do

03:23:00
we do with it? What do we do with this HTML that we just generated? We just built from our template. What do we do with it? We respond with it. We respond with that HTML back to our user. So our user went to our website. They just wanted to see the to-do list. they didn't know just by typing in that URL, they had made a get request from their client side device. That get request made its way all the way to our server. Our server had some code running on it called our API that heard the get request. We got to write, right? We got to write the code that once we hear that get request, what happens? Just a fancy click event. We said, hey, when we hear that get request, go to our Mongo database, find

03:24:00
the collection for our to-dos, grab each document from that collection and plug all that data into our EJS, right? Our EJS takes in all that data, it builds out the to-do list as HTML. And once we have this HTML that gets rendered from the EJS, we respond back to the user. They hit enter and all this stuff had to happen. And to go all the way from their client side device, all the way to our server in Chicago, all the way back, right? And since we're using Mongo Atlas, not only did they have to go to our server, then our server made a request to our MongoDB. Our MongoDB responded to our server, our server took that data and then respond it back to the user. And all this is happening in seconds. Seconds,

03:25:00
right? Seconds. I don't understand, but I'm still here watching almost five hours a. I love a rascal to said, yep. It's only a matter of time and effective study. You'll get there. You already did the hardest part and started. Oh yeah. What I don't understand is why not loading the data thanks to fetch on the front end. We can make fetches. In fact, we'll use fetches for our update requests, but we have to understand that there are some other types of requests that we can make. Simply entering

03:26:00
a URL or refreshing a page is a request. Right? Is a request. Submitting a form is a request. Doing fetches is a request. And our servers, right? Our servers, our servers are set up to hear all these different kinds of requests, right? But to hear all these requests, how many mugs do you have? Well, this is for my tea and water, or tea and water, depending where you're coming from. And this is for the magical elixir of go-go juice. I gotta keep them separate. First, everything was objects and now you're saying everything is a request, but, but, but, but, but, but rascal too. What are these requests? We seen the request, what the request, what we,

03:27:00
we console log the request, what The request body, the request object. We console log the request object, which contains the body property, you know, cool, all right. So we've gone to our to-do list, we've loaded the list, what would be a create request here? What could trigger a post request on our to-do list application? Yeah, adding a to-do. When we fill out our form to add a to-do, right? Welcome,

03:28:00
Palazzo. Hey, when we fill out the form, we add a to-do, right? That is making a post request. We fill out the form, we hit submit on that form. That request, the filling out of the form leaves our client-side device. It makes it to our server. There's some code running on our server that here's that Request and this time it wasn't a get it was a post request And so now we're gonna have some different code that we've written Right that we've written for what happens when we hear that post request Right different code that we're gonna write when we hear that post request Will this be uploaded to YouTube? Yeah, our reviews get put on YouTube, so this will be on YouTube for sure. All right, so that code for the post request, right, that code that we heard from the post

03:29:00
request, right, that code that we heard from the post request, that request that came through, that code is gonna do some very specific stuff. That code is gonna do what? We just submitted a new to-do, what do we think we have to do when we hear that POST request. Yeah, we have to add it to our database. So the request came through, and with that POST request, right? With that POST request, right? Along with that POST request came in text that TODO, right? When we submitted the form, along with that request was all the data

03:30:00
we submitted for that TODO. And so our POST request, the first line of things, the first little bit of code that we're gonna do is we're gonna say, hey, go to our MongoDB, go to our to-dos collection, and what I need you to do, right, right, what I need you to do is create a new document with the data that came along with that request, right? It goes down in the DB, exactly. So it creates a new document with that to-do in our database, right? It creates a new document that to do in our database. And then once that is done, once it's added that new document to our collection, what does the POST request do? It took the information that came along with the form, it went to the database, it created a new document, it plugged that data into that document. What's the last thing

03:31:00
the POST request does? It responds, right? It responds back to the client, telling them to refresh. Telling them to refresh. And when the browser refreshes, when it reloads, it makes a new what? Makes a new get request. Exactly, makes a new get request. So that request comes along to the server. Our API, here's the get request. We go to our Mongo database, we find all the documents, but now there's one new document that wasn't there before. We take all these documents, we plug them into our EJS. It's in the game, right? Plug them into our EJS, our EJS spits out some HTML, but this time the HTML

03:32:00
has one new LI, a part of our list, which comes from that new document that was put in there from our post request. We respond with that HTML and the user sees that new list with the thing that they just submitted in the form. Yeah, it's wild that it happened so quickly, super fast. Remember, it's so fast because we're building on top of some really impressive technology, HTTPS, TCP, IP. We're sitting on top of really fast C++ and C libraries that make up Node. Joda said, I cut this down so happy. Beautiful. This stuff makes more sense to me than CSS. I feel the same way. Backend just clicks in my brain better than frontend does. I enjoy running frontend because I find it pretty creative, but I also find the backend really creative. I don't think you should ever limit yourself in the beginning. Like all of you should be full stack developers, but you will develop a preference over

03:33:00
time. But don't narrow yourself down for the job hunt. I think that's a big mistake that a lot of folks make. They tell themselves that I'm better at front-end or they tell themselves I'm better at back-end. Don't limit yourself like that. You'll have plenty of time to develop a preference. Now's not the time. Would images go to a separate server? And then, yes. So our images are being stored with Cloudinary or like S3. So they're being stored on Amazon server. So there's even more hops and skips. Yeah Will react make the front end easier react makes more complicated front ends easier and makes uh your code more reusable We're just doing a little bit of review of our to-do list right now So we did our get request our post request and we're going to talk about uh updating and deleting very very simple full stack crud app nothing too complex. Cool. Alrighty, so we're building a to-do list and

03:34:00
so far we have added to-dos, we've created to-dos, we've read and got our to-dos, but maybe our to-dos have the ability to say whether or not they have been completed, right? Maybe when we put our documents into our collection, maybe the documents have a completed property that at first is false, but eventually we can trigger that to be changed to true. And that way when we're loading our to-do list, maybe the items that have been completed can look different than the items that have yet to be completed. So how could we trigger this updating? Let's say we have a list of things, let's say we have bread, milk, Chez, right?

03:35:00
How can we trigger this updating so that we know that this has been completed? We already got the bread. Yeah, what's the only thing that can listen for clicks? Right, what's the only thing that can listen for clicks? Oh, we could make a checkbox, we can do a little hackier, right? We can have our event listeners. So our event listeners is client-side JavaScript, right? Client-side JavaScript that's listening for that click. And when the client-side JavaScript hears the click, what can it do to make a request to our server? We're going to see method override this week, which will be pretty fun. I'm just gonna change this up a little bit, but what can we do? What can we do? We hear the click. What can we do in our client-side JavaScript to send that request to our server? What can we do?

03:36:00
Yeah, we talked a lot today about fetch, right? We talked a lot today about fetch. Our client-side JavaScript has the ability to make fetches. So we'll use that fetch that web API. That web API to make a fetch to the server, right? So we send our request to the server. There's some code that's part of our API that is set up to hear that request, and the beautiful thing about using fetches we can say what type of requests were making so we make that request from our client side JavaScript. Will say that we're making a put request. We're trying to update something. So that request comes along as a put. There's some code as part of our API that hears that request. And we have some code that we've written for when we hear that request. That code is going to do what? That code that hears the put

03:37:00
request. What's that going to do? What do you think we're going to do? I'm not trying to make fetch happen. I'm always going to make fetch happen. Yeah, it's going to update a document. Exactly. We're going to go to our MongoDB database. Right? We're going to find a specific collection. Sorry. Find that specific collection for our to dos. And we're going to find a specific document. Right? That we're going to update the completed property that was false. We're going to change it to true. Right? We're going to change it to true. And once we've made that update in our collection, right? We can respond back to our client-side JavaScript saying that everything went okay, and that you should probably do what? In a very, very simple app. No, no, no, no extra fanciness here. To refresh,

03:38:00
yep, to refresh, right? We heard the we heard we clicked we made the put request to the server our server heard the put requests We went to our MongoDB. We found that specific document. We change complete it from false to true We responded to the server saying hey everything went. Okay. We did the thing you asked us to do and We refresh and when we refresh We make a new git request to the server. That git request, just like we talked about before, goes to our collection, finds all the documents. However, this document is slightly different. We plug all that data into our EJS. That EJS builds out some HTML. However, in the list that we generate from that HTML, one of those documents, well, it's gonna look a little different because it had a completed property of true. So that HTML we generated is slightly different

03:39:00
and we respond with that HTML back to the client. Beautiful. All right. Last one, last one. What can we do with our to-do app to delete stuff? What can we do with our to-do app to delete stuff? Yeah, we can delete some to-dos. Maybe next to each of our to-do items, we have like a little trash can icon, and we click one of those trash can icons. But what can hear us clicking on that trash can, that delete request? Here's that clicking of the trash can. Yeah, it's our event listener. Our event listener hears the click on the trash can. And when it hears the click on the trash can, it's gonna make a fetch request to

03:40:00
our server. And it's gonna tell it, hey, we're sending a delete request, and it's gonna send some data along with the request. What kind of data is it sending along with the request? We're sending a request to our server to delete something, but what are we sending to the server? What data is coming along with that request? Yeah, go for it, exactly. What to do to actually delete? So we grab that to do, we send that to do along with our delete request, and we have some code that's part of our API that hears that delete request, that hears that delete request, and when it hears that delete request, it knows what to do because we've written some code for it. And our code is gonna do what? The code that hears that delete request is going to do what? Yeah, it's gonna try and

03:41:00
remove a specific document from our collection. So it's gonna go to our Mongo database. It's gonna find the document that we need to delete, and it's gonna delete it, right, from our database, right? And then the last thing that this does is we respond back to the client saying hey Everything went okay, and you should probably what? You should probably refresh because when you refresh You're gonna make a new get request to the server the server is gonna hear that get request We're gonna go to the Mongo database. We're gonna find all the documents in that collection However, there's gonna be one missing that we had deleted. So when we pipe all that data into our EJS, when there was four, now there is three. Our HTML is rendered. It only has three instead of four LIs this time that are part of our to-do list. And we respond with that new

03:42:00
HTML. Bop, bam, boom. You have a full stack web application that can listen for your create, your reads, your updates, and your deletes. Beautiful. All right, so this lays the groundwork for some complex code. On top of this one, we have to understand how all this stuff is happening, right? We have to be able to look at and see, all right, how are we crafting the get request? How are we crafting the post request? Like, how are we sending these different requests? How does it all work? How do we write out our codes that it hears it on the server side like we understand at a high level how this is working but the nitty-gritty of how we actually write the code that's what we need to get into next and once we start writing code we're also going to have to come up with systems to make our code organized so we're going to see how to write this code we're going to see how to organize

03:43:00
our code so what are we going to add once we once we know how to write this type of full stack application what are we going to add on top of it to help us stay organized. Yeah, we're gonna add some MVC structure so that we can keep our views separate from our models, separate from the controllers that are in the middle. All right, so we need to add some MVC to it. And then we have to add just the, we have to add a little bit of authentication. We have to add a little bit of authentication. And then we have to add a little bit of these extra cherries that a lot of modern web apps would have, like image storage or video storage or whatever. And once we do that, once we know how to add MVC structure, once we know how to add authentication, once we know how to add a little bit of the extras, like uploading files and things like that, you can really build whatever it is the heck that you want. So on Tuesday,

03:44:00
we will be finishing up Binary Upload Boom. We are going to see a multer. We're going to see image uploading. We're going to set up Cloudinary. We're going to set up all these things that are going to make our application run. Once we get through Binary Upload Boom, we'll come back next Sunday and we'll build it from scratch. So we'll see all these pieces come together, right, and build it from from the beginning using our template build it up so we can see all right here's how the controller comes into play here's how we use our views right and once we have this wonderful full stack application working that has authentication that has image uploading that's a full social media website once we have that since we're already using mvc what can we start to swap in and out oh angel gave me the stretch hold on one second let me get my stretch in you know it's not that kind of stream hold on hold on

03:45:00
you want to see me stretch you know what to do only a million channel points oh yeah Oh hey oh all right thank you sir cool now since we have a beautiful full stack application, and we're using an MVC structure, what can we start doing if we decide to? What can we swap out? Yeah, we could use something other than EJS, right? A good portion of you hate EJS. Well, guess what? We can swap it out if we wanted to, right? We can swap out what's handling our views with something like react, right? And if we have enough time at the end of program, we could even swap out Mongo DB and use something else

03:46:00
like Postgres. Our application was just still work because we separated out our concerns, right? Our views are in one area. Our models are another area. Our controllers are in between. So the beautiful thing about MVC is we can swap out all these different pieces and that's what we're going to build up to. So next Sunday, we're going to walk through the to-do list and binary upload boom from scratch. We'll see it all come together We'll ask tons of questions. I want to spend our last half an hour of our six hours together Doing some hunt stuff because that's coming up very soon Something that I want to give everybody a refresher on especially folks that are part of the ketchup crew This is stuff that you need to be start thinking about now anyway, so let's talk about it You can see all the slides are here. So this is all the stuff to go through next Sunday. So if you want to take a sneak peek, it's there in the slides. We're going to go through all this wonderful stuff, but let's take a few minutes to look at all this crap we're going to do next Sunday. Oh boy. Let's talk about the hunt

03:47:00
and what you need to start getting ready to be prepared. I know folks are really trying to gear up for Hunttober, but even if you're not gearing up for Hunttober, these are things you should be doing and incorporating into your daily practice so that when you are ready for the hunt, you're ready to lock and load. So the first thing is the checklist, right? First thing is the checklist. The checklist is a bunch of professional stuff that you need, right? That you need, right? To help you build the baseline for your hunt. And the good thing is the sooner you start this professional checklist and get this done, the more opportunities you'll see start to come your way. Once your LinkedIn is done, your professional Twitter blurb, all that fun stuff is done, right? Once this is all done, you're going to start to see recruiters hitting you up. You're going to start me taking a little bit more seriously when you go through your applications. So, um, I,

03:48:00
I recommend that you finish this as soon as possible. Let all this stuff start marinating, right? Let all this stuff start marinating because you want it to be showing up in Google. You want it to be showing up When somebody types in your name, right and you can do exclamation point checklist here in chat to get this checklist My first inbound recruiter contact was literally the day after I updated my LinkedIn it works. I'm just telling you it works, right? You'll notice that a lot of folks that I've been posting in the Celebrations channel. If you're new around these parts, we have a Celebrations channel on our Discord. Literally hundreds of folks have posted that they've gotten jobs and how they got jobs, boots on the ground information. Go check out that Celebrations channel. But the checklist, the beautiful thing about the checklist is that once you start doing it, it starts to marinate. And the longer you let it marinate, the easier it will be for folks to find you and for offers to come your way.

03:49:00
And we do all this stuff so we can pass the sniff test. We all have a new engineer or the dreaded boot camper smell. And when you go into these interviews, you do not want to have that smell. You wanna be treated as an entry-level engineer that you are and to pass this sniff test, there are some things that we can do so that people treat us like the engineering talent that we are. One of the things you can do to help you stand out as an engineer and to pass the sniff test is to push code every day. Some folks don't like to think that those green squares matter, but they do. It's a mental thing. When somebody's looking at your GitHub and they see that you push code every day, there's a switch that goes on in their brain that says this person's about this life. That's all you need. You don't need them to see the quality

03:50:00
of your code. You don't need them to see that you are a good developer. It's literally just the fact that they're there, they'll go, they're about this life, right? And that helps you when somebody's trying to evaluate whether or not you can code and they see that you've pushed code every day, it's one of the things that lower your smell. It starts to wash away the stink, right? Your hit list, one of the most important things you'll ever do for your career and something that's due on Tuesday. It's finding the companies, right? Finding the companies in your area that have open applications. If you weren't here for Thursday's class, I showed you some hit list magic. Some one thing that you plug in to Google that will show you all of the open roles that have been just posted. So if you haven't watched that VOD, you need that one thing. You'll find all the companies that are hiring in your area,

03:51:00
specifically with the stocks that you're using. It'll remove all the nonsense of senior and all that stuff. Use that magic, right? Fill out your hit list. You fill out your hit list of the 60 companies that you're gonna be applying to with these open rolls. And the reason why we add them to our sheet is so we can keep track of it. The hit list magic was in our most recent class, so Thursday's VOD from Thursday's class has the magic. Or you can check out the slides from Thursday as well. Right, 40 or due Tuesday. Yep, 40 or due Tuesday, you're adding these open rolls to your sheet, right? to keep track of all these open roles, right? Keep track of all these open roles, and we're going for 60 recommended applications. So that means once you add 60 companies

03:52:00
to your hit list, sorry, we're gonna say 60 open roles to your hit list. Once you add the 60 open roles to your hit list, your networking becomes focused, right? Your networking becomes focused. You are going to start reaching out, right? We're going to start reaching out, right? To folks that work at those companies. We're gonna have a whole class on this. We're gonna start reaching out to folks that work at those companies with the end goal of getting them to recommend us. Clicking apply is a waste of our time, but if we can network our way in, our applications are taken way more seriously, right? Are taking way more seriously. Right. We're taking way more seriously and it helps us

03:53:00
immediately, immediately get past the sniff test. Right? Helps us immediately get past the sniff test, and so the reason why we go for recommendations over clicking apply is because all the things that you're worried about when you apply disappear when you get recommended. Years of experience doesn't matter, right? Technologies in your stack don't matter. When you've gone past the robot that's filtering out resumes and you've gotten connected directly with the person that is hiring your application is treated differently. So we add the 60 open app 60 open roles to our hit list and then we're going to have like two to three classes where I show you how to contact those roles find people that work at those companies and get recommended not apply. I got a referral went straight to resume review with their HR no coding outside of 100 devs. Let's go.

03:54:00
Let's go. Go. All right. Once you add these roles to your hit list, you're going to find a couple people to talk to. You're going to find the hiring manager at that at that role. You're going to add them to your hit list. You're going to follow them on Twitter. You're going to find their email on Hunter.io. You're going to ask them for a coffee chat. Once you have the coffee chat, you're going to send a thank you and And then you're going to get the recommendation to the role, right? You have 60 open roles. You're going to try and find the hiring manager for each and every single one of those roles. Add them to your hit list, follow them on Twitter, find their email, ask for a coffee chat, send a thank you, get the recommendation and have a full class on how to do this, but this is what you need to start doing once you add those companies to your hit list, you're going to start finding the people at those companies to interact with, don't ever just

03:55:00
click apply. Don't ever just click apply. It is a waste of your talent and energy. This is the way that works. Get referrals into these companies, it will work. Will you have the off chance where you randomly click apply and maybe you get in? Yes, but I'm not talking about one offs. I'm not talking about one person that's been successful. I'm talking about hundreds of students that I have helped get jobs. So we have a few that get lucky, click apply and get the job. Yes. When I'm talking about hundreds macro level, big picture, the folks that get recommendations, get jobs 99 to one against folks that just click apply. Eventually once we're done with our hit list, we found the companies. We've been networking folks at the company. We're going to create 30 high value applications where you're going to have a custom resume for that application and have a custom cover letter, a custom story about why you're a good

03:56:00
fit for your, the role. And when you're talking to these real living, breathing humans at the company, you're going to show this stuff that shows and makes them think you're the perfect fit that the role was built for you. I'm going to show you how to do this. Then you're going to have 10 premium apps after you go above and beyond the call to make sure that you stand out in the job search process. You're going to do all the custom stuff from the previous page, you're going to make tweets about the industry they're in, you're going to have a blog post about the industry, you're going to have a small, simple project that you do over the weekend for that company. These little things in the end pay off huge dividends. I have so many folks that go to the top of the pile because they spent three hours modifying binary upload boom to look like to look like what company you're playing to. And then with Ali, hey, thank

03:57:00
you for the raid. Hope you're all doing well. Welcome. Welcome. Thank you for the raid. Hope you're all doing well. Hope you all had a good day. We are we are five and a half hours into a six hour review class in the back end. and we are talking about the job hunt and the things that we're gonna be doing to get our jobs locked down. We're gonna have a whole class on premium apps, don't stress. Your $100 project, guess what? You should be starting your $100 project already. You all have the binary upload boom code to use as your base for your $100 project. You could start with the front end If you don't feel comfortable with the backend yet, you should be well on your way to starting your 100 hours project. Don't delay, start today. All right. I recommend 100 hours projects that you're really passionate about, something that you would want to build, or at least something that ties your past into your present. When we did our crafting

03:58:00
your story interview, one of the easiest ways to explain gaps in your employment history, to explain why you weren't a developer for the past couple of years, is by having a good 100 hours project that ties what you were doing to what you are doing. So if you were a server in a restaurant for five years, you build a new ordering system because you hated the point of sale systems that you're using, and you use your engineering skills to change that industry, right? You can start off with your, we're gonna worry about this. You start off with wireframes, but you should be well into building your hundred hours project. Cool. Let's talk a little bit about interviewing and then we're going to save some time for questions. There is a process to interviewing. Uh, we don't click apply. We either get recruited or recommended. You're going to have a phone screen, a behavioral screen, some technical questions, maybe a take home, maybe a live coding session,

03:59:00
either in person or on, on the interwebs. Uh, and then sometimes you have like a wine and dine interview where they They know they want to hire you and then they make an offer. Every company is wildly different. And a big part of what we're going to be doing during HUNTTOBER is making sure that we're ready for this process. And whenever comes our way, uh, once we get recommended it, cause we've done the hit list process, right? Uh, we're going to research the living hell out of these companies. We're going to find every single thing we could find about this company that has ever been published online. You will be surprised the amount of time you can find the exact interview questions you are going to receive on Glassdoor, on GitHub, on Blind, whatever it may be. I've shown this before. Let's go to GitHub. Let's search Spotify interview. Not on my

04:00:00
repo. Oh, I almost got myself got there. All right. Take home task, Spotify interview, Spotify interview from April, Spotify interview, right? Like there's just so many, there's so many, and this is just the first thing we typed in, right? Like full, full date, like full code, like full answer. Right? So you will be surprised the stuff you can find by just researching the company, like somebody is going to pay you six figures if you figure it out. So the beautiful thing is a lot of times you're going to find stuff on Glassdoor, GitHub, Blind. You can ask other people, hell, just ask your interviewer what you should be prepared for. And nine times out of 10, they're going to tell you exactly what to prepare, right? We're going to talk a lot about this. We're going to have full classes on how to find this stuff and how to be prepared for those interviews, but something that you can start

04:01:00
now that you're ready for these interviews is the bank. So you can click the link or you can do exclamation point, uh, bank here in chat. The bank has all the questions that you can prepare, uh, both behavioral and technical, so you stand out in your interviews, don't listen to me, go into the celebrations channel and read the number of people that said my interview consisted of exclusively questions that were in the bank. There are literally dozens of people that have gotten jobs that are in the celebrations channel that say, every question I was asked or pretty much every question I was asked was literally on the bank. You could be prepping the bank. You should be prepping the bank, right? Fox, yes. Fox has, remember the stream teams has tons of streams where they work through the bank. So you don't have to work through the bank by yourself. You can do it live with the stream team.

04:02:00
You can do it live on Discord, jump into a voice channel, say you're doing the bank and work through it together. Right? The bank helps you pass these interviews. It's literally the stuff that's gonna come up in your interviews that helps you Excel stand out and pass the sniff test. You can practice your behavioral questions. You wanna cause action result for every question on that list. Cause that my last company at my last opportunity, action, the steps that you took result, why you're the best thing, the best thing that has ever happened. Since you took that action, you have a full class on cars on YouTube. Um, you can watch that. We've gone through this before, like on how to interview. So if you need a better breakdown of cause action result, the stuff you should be practicing your technical questions, EU explanation, use example For every questions on the bank EU or your technical whiteboarding, you can be practicing your code wars using

04:03:00
prep. Every single coding challenge you ever do, you should be prepping through that coding challenge. Don't ever solve another coding challenge without walking through the parameters. What's coming in? What am I returning? What are some examples? What is some pseudocode I can write before I start solving the challenge? because during the interview, that's what you're gonna do. Coding challenges, coding challenges in the interview process do not, it doesn't matter if you get the answer right, I have had people that have gotten the complete wrong answer, still get the job because the interviewers love the way that they walk through the things they were doing, walk through the code that they were writing, that they prepped themselves through the process. Make sure you're practicing your prep. All right, so your homework is to start prepping the bank. It's the complete your hit list cause it's due Tuesday. And to review the binary upload boom code that we're going to walk through on Tuesday

04:04:00
together. We'll probably also do Thursday. Because once we get through that, you can build whatever the heck you want. And all these other things that I just powered through become the thing that we focus on towards the end of September and through October. We're just going to add a little bit of React and a little bit of data structures, algorithms, with big O notation on top and we're ready. We're off to the races. We need to start getting ready for the hunt. So we're going to do that this upcoming week. Next Sunday, we'll come back and we'll work more through the to-do list and binary upload boom. We'll see that code come together, but I want to end with some questions that folks have been throwing in the Slido. Since I was here when the first cohort, I have companies in my hit list from last year. Should I remove them from my list? Yeah, if the role is not open, you definitely want to remove them. You definitely want to be making sure your hit list stays fresh, right? Make sure your hit list stays fresh.

04:05:00
You're welcome. How do we respond when interviewers ask what dev top, DevOps, I said DevTops, DevOps tools we've used. So you could say, hey, I'm not a DevOps-y person. I'm a full stack software engineer. I've used normal processes when contributing code. I mainly use GitHub, but typically I make my pushes. I submit my pull requests and the DevOps engineers that I've worked with handle everything from there forward. So it's not definitely part of my expertise, but it's something that when I'm working with a team, I work closely with the DevOps engineers to get that stuff done, but what part of the process what DevOps tools do you all use on the job? And how have you seen your your kind of everything from pushing code forward change over the past few years? All right Don't full-stack devs no DevOps.

04:06:00
No No Most full stack engineers push their code, it goes live, and then everything else that happens after, like everything else that happens after you commit your code, that's on DevOps, to get it live, to get it into production, to get it staying up and running. Yeah, that's a whole different skill set. Now do a lot of engineers know a lot about that stuff? Yeah, but DevOps is a whole different career. Shout out Mastermind if you're interested in DevOps stuff. They do a lot of that on their stream. Rec.body versus rec.params. Rec.body is all the information that's coming through to NIP typically with, typically coming through with like submitting forms or information that came along with the request. So you can submit a form, You can submit data with like a fetch

04:07:00
or some sort of client side request. That's all the information that comes along with the request will be in the body. When you make a request, there's often stuff that's encoded in the URL. So we saw that last class with like the, um, the ID names being in our URLs, we can grab the stuff from the URL with, uh, with our parameters. So rect.body grabs data that's sent along with their requests coming from like forms or from our specific fetch requests, stuff like that. That's what the examples that we've seen. And then rec.params name is just to pull stuff out of the URL. Circus, there's no wrong way to do Anki. you literally create cards. And as you do that

04:08:00
more often, you'll find that some cards are useful for you to remember, and some cards suck. And that's why you have to make your own cards, right? As you do it more and more, you get better at it and better at it. And then eventually you have your own way of doing Anki. Everybody does Anki a little bit differently. And so, everyone does a little bit differently. And so it's really just creating a simple card. There's some good videos on our discord of how to set it up, but there really is no wrong way of doing it. And doing them by hand is definitely not using Anki. When you do them by hand, there's no algorithm behind what you're doing. And so you don't flatten your forgetting curve because you're going to review the material at the wrong time. Yeah. That's why we use Anki because it has the algorithm behind it. That's why we don't use like regular flashcards, but ask for help

04:09:00
on discord. I'm sure more than half, I'm sure more folks are more than happy, um, to like walk you through on like a voice channel. You just download Anki and you can create it's it's you just create a card, but Yeah, jump on a voice channel on discord. I'm sure folks will walk you through it. We also have, there's tons of YouTube videos that show you how to set up the cards as well. So we've shared some of those videos on discord. Watch one of the videos. That's gonna be way more important than anything else. Yeah. Cool. When will we know if we got accepted into Hunttober? If you submitted everything on time, you're accepted. So that'll be it. Um, once we get, once we start hunt Tober, um, we'll send out a message, you'll get added to a specific channel on discord that you normally wouldn't have access to. Um, there'll be some special channels for like, like inside of hunt Tober.

04:10:00
There'll be breakdowns of like resume portfolio, that type of stuff. A hundred hours. Uh, we'll have a special voice channel for our daily calls. So you'll just get a role that says like hunt Tober and you'll get added. So as long as you're submitting all your stuff and it's on time and it's not like fake stuff, you'll get accepted What if you were in the catch-up crew then you continue on like normal like I said hunt over is nothing special It's just a group of folks that are ready to start the hunt right now That's all it is. All the materials are already on YouTube or will be on YouTube and discord We're still gonna have normal streams. All Hunttober is is just for folks that are ready right now to start applying so I can give them a little bit of more attention as we go through October. Okay,

04:11:00
I've already answered that. About how many coffee chats do we have so far? I think I've been asking for at least one coffee chat a week. So like 30 plus, and then you're going to really pick up steam as we get into the hunt. We can't access channels without that role. Exactly, yeah. So it's just that folks that are going through the hunt for that week, for that month, have a place to do it. Do you have a note of time off your head that will be for the dailies? Not sure yet. We'll do a poll to see what works best for most people. I think during mega summer last year, we did six o'clock every day, six to 6.30 every day. Yeah.

04:12:00
And then if we figure it out, we'll probably do like another version of HuntTober in the future. Like I said, nobody's ever done this before. We've never done this type of education at scale before. And so a lot of the stuff I'm just trying to see if it works, what doesn't work. And so HuntTober will be one of those things. But when we did MegaSummer last year, it was really helpful for folks that just need that last little push to start actually going through the job process to do it. So that's why I want to do it again this time. So I'm just looking at the questions on Slido. What's a practical example when you would use setTimeout or setInterval? Whenever you need something, I mean, setTimeout's like whenever you need something to wait before it happens. Sometimes there's like UI flourishes where the user clicks on something, You need to wait some time before something else happens.

04:13:00
Um, sometimes you need to delay something in the UI. People use that. I don't know if it's the best thing to do, but it's something I see quite often. Uh, set intervals. If you need something to show up on a recurring basis, you can do that. Yeah. Are you still adding more people to stream team? Uh, yes. We eventually want to add more folks to the stream team. Uh, we also really want to take time to highlight the folks that are already part of the stream team. So we're gonna be rolling out quite a few changes just to make it easier to find folks. We'll be sharing some special like bios and just really making sure folks know how to interact with the stream team that we have it. And then once we've done that, then we'll kind of open up applications again for more folks to join us. But I think the stream team is the ultimate extension of community taught. And so we can do it in like a really nice sustainable way where we highlight folks that are doing good for the community, uh, yeah, we'll keep it going.

04:14:00
How would you recommend navigating the hunt while working 40 plus hours a week? Uh, so that's you, right? Nobody knows how much time you have and what you're doing with that time. Right. But give me somebody that's really disciplined with the hour that they have, or somebody that kind of waste that hour every day, and I'll take the person that's disciplined with that hour, one hour of really good focus a day is better than kind of doing something every single day. Right. And so, uh, I think most folks, when they get into the hunt, spend two to three hours on top of work, um, to get prepared because it's a lot, right. And a lot of folks are going to have to take some time off to interview anyway. Uh, and so the, the beautiful thing is that, uh, the beautiful thing is that yes, it's a, it's a really hard month and you're going to have to take

04:15:00
some time during that month to do it, but at the end it could end up with a job. Right. And so I think most folks during the hunt take like two to three hours a day, including weekends, and then some folks, uh, take a couple of days off because they need to interview, um, which is a privilege not everyone has, but that's kind of the normal pattern I'll quit my job right now. No, please don't quit your job. Um, I don't like when people quit their jobs to do program, uh, I want you to be gainfully employed because when you don't have a job, you introduce even way more stress, right? Way more stress. Uh, and that stress impacts you from actually doing, doing well in the interview process. Um, burn the boats is only one direction. Yeah. That's a, it's a, it's a, it's a, it's a strategy. Some know what, for some people that works. I will say for some people that that works, but for the most part, for most folks, it can be something that could be rather debilitating.

04:16:00
Will there still be streams after the cohort ends? Yes, absolutely. I've been kind of dropping little hints about this, but there's a couple big things that are coming. One is the job board that we've been working on. My big step is finding and working with companies that wanna hire specifically 100 devs graduates because our graduates are amazing. They can build full stack web applications. They can do so much more than a lot of folks coming out of traditional CS programs can do. And so I wanna work with employers that are good people to work with and get them on to hiring you all directly. So that's something I've been working on in the background for a long time and working with some good companies so far. And the other thing is the agency. And it's not gonna be perfect when we first start it, but the idea is to have a place where folks can work on real code for real companies and get paid to do it.

04:17:00
And so the vision in my head that I've been trying to figure out and I've been doing a lot of like weird tests and breaking some stuff. And the idea would be that we would have an agency where folks come to get their development work done. And we turn the issues on GitHub into issues that anyone that's part of the program can do. And when you submit your pull request and it gets merged, not only have you learned how to build production level code that'll get reviewed by some senior engineers that'll give you feedback, but when you close that issue, you also get paid, right? And so, um, I think having a truly equitable bootcamp, it's not equitable just for it to be free, but if you can also make some cheddar as you're going through the program, uh, I think that's my ultimate goal. And so I think those are the, the big things that are on the plate right now that once, once cohorts done, I can really sink a lot of time into those two things

04:18:00
and I want to stream it. I want the work that we do in the agency to all be public. I want all the finances, everything to be public. And so I imagine members of the stream team streaming themselves, working on the issues that are on the 100 devs GitHub repo that have bounties on them. And not only is it a cool way to learn how to code, but then once we're done that project, I want it to still be open. I want anybody that's learning to be able to come and see the project that we built for that client, and see the decisions that we made, see that we've been able to do the things that we were able to do. And so that's the idea. And I'm gonna need a lot of help. And so I think once we get through cohort, that's what I'm gonna be leaning on all y'all to help bring that to life so that once we get all that figured out, the next cohort can be even better. You tell us the site. So who should we move to from Heroku? So the cool

04:19:00
thing is every company that does hosting has pretty much reached out to me and what I'm trying to do is like finagle something special for us and so I'm not ready to make my recommendation yet. Traversee Media has already put out recommendations on the hosting providers that they like, so I think that's a good video to start with, but maybe we can get some stuff special for 100 devs and then that'll probably impact my decision. So I have calls with a lot of folks next week. I had some calls this week And then based on how those calls go, I'll make my recommendation. So we're not there yet. We don't need our binary upload boom on Heroku right now. We'll get to that next week. For the hit list that's due on Tuesday, do we need to find the hiring manager each company by the 13th? No, it's just the open roles that you need to find, right? It's just the open roles that you need to find. And then it's going to be up to you to keep building

04:20:00
on top of that hit list to find the hiring managers all that stuff How do we respond when we've asked if we've tested code before If you've been doing code wars every day, you've been using tests every single time You submit your code war solution Every single time you submit your code it runs those tests to see whether or not your code is correct So you've been using tests for months now. We'll eventually have a little bit of testing that we do during class that'll help you better answer that question. Hey Leon, I'm having trouble finding 60 companies. I'm just shy of 40. I've used the magic, I've done local sites and I'm still struggling. You might live in an area that does not have local opportunities and you're going to have to pepper in some remote as well. Yeah. Yeah,

04:21:00
you have to pepper in some remote as well. If you know you live in an area, the thing I tell folks is if you live in an area doesn't have a ton of jobs, there's always there's always some for most folks, right? Uh, you, you, you can select the next major metro area and add that as well. And then you want to add remote on top of that. You always add remote last because being local is so much easier to get a job. Right. I just, I just, I just really need to emphasize that local for most of my students is just easier remote. You're competing against more people and the process can be a little bit more difficult. So you start local and then you work your way up and you fill in the gaps with remote opportunities. Are we going to do some bug testing? Well, we'll do testing and yeah, we'll use a little bit of jest. If we're in the catch up crew, will

04:22:00
you be flexible for now? The deadlines are kind of deadlines. Like I said, it's just for folks that are absolutely ready to go into the hunt right now. There's nothing that you're losing by not doing Huntober. It's just so I have a place to give folks a little bit more attention since they're ready to start the job search. After going through all the local jobs, would you start with remote jobs or local jobs that require languages you don't know? I think if the company looks good And it's a company you want to work for and you don't know the language that's still okay to put on your list I wouldn't necessarily count that as part of your 60, but they should go on the list If it's a cool company that you would want to work for You'll go through the interview process. And like I said, you can take a weekend to build something small that uses their stack Most folks will join a company that does not use the language that they've learned here at a hundred devs

04:23:00
A job listing closes in four days. How do I speed run the hunt? We have three classes on YouTube, exclamation point YouTube, and you'll see my classes on the hunt. You can definitely watch those and learn how to speed run the hunt. What's the most important thing to focus on if you don't have much free time and are also a slow learner? You're not a slow learner. You just need better study habits. Every single student that has ever told me that they're a slow learner just does not have the appropriate study habit that works for them. So what I would recommend, if that's something you're saying about yourself, Definitely watch Dr. Barbara Oakley's learning how to learn. Watch all of Ali Abdaal's videos on like evidence-based study tips and really incorporate them into your daily practice until you feel differently about that. It really is study habits, right? You have to understand that. It's not something intrinsic about you. It's not your aptitude or ability to learn how to code. It always comes down

04:24:00
to study habits. And this is, of course, taking like, like non-neurotypical stuff off the table. Everyone else, it comes down to study habits. Yeah. I swear this is true. If you think you're a slow learner, you might want to evaluate how you learn because schools do not teach us how to learn. They do not teach us. They do not exactly 100% you do not learn how to learn in school. It's on you to find the study habits that work for you, especially as an adult to continue your career. Cause this is a cumulative career. Alrighty folks, we've been live for over 6 hours. We've walked through the foundations of everything we're going to need for the back end. I have everything planned out for my MVP, but I can't seem to make myself do what needs done. Do you have any advice on dealing with mental blocks like this? There's a lot to unpack there and only you know your situation. As someone that has

04:25:00
pretty debilitating executive functioning when it comes to ADHD and my bipolar disorder, like I get you, been there, done that, happens to me a lot. For me, it's therapy, it's medication, it's getting good sleep, it's taking breaks. It's doing a lot of the stuff that we've talked about since the beginning. But I feel like when folks get to this point in program, it becomes very overwhelming, right? And that's something that's worth for us all to talk about for a second, especially before we get ready to spend the next three to four hours together working through binary upload boom. This point of program is the hardest. It is the most grueling. It is the most demanding. It is the most in your head because everything feels like it's on the line. It feels like there's so much to do you're constantly getting critiqued as you're applying you're constantly getting rejected like this is this is the

04:26:00
the the the Part where you are tested the most and it's the thing that I showed you day one when we looked at that Trough of sorrow, right? We looked at that trough of sorrow. I don't know if I have the trough of sorrow in the slides So I have the trough of sorrow in the slides Here we go, here we go When I showed you this Trough of Sorrow, there's something here that was the secret, right? This is the secret, right here. Why won't it let me draw? Okay, here we go. This was the secret right there. The crash of ineptitude. That's where you're at right now. If you didn't know,

04:27:00
this is where you're at. And so you've slogged through the trough and now everything you've done becomes real. You need real projects. You need your networking to come through. You need your culmination of everything we've built to actually pay off. And now you're tested, right? You're going into these interviews. You're talking to employers that are critiquing your experience, your resumes, what you can and can't do. And most people crash. So it seems like your blocker is the crash. That is a very real situation that most folks find themselves in when they get to this stage of program. So know that you're not alone. Know that that feeling is something that was planned. Know that that feeling is something that you will have to work through. And we're gonna spend time throughout Hunt-tober

04:28:00
and through our next few classes talking through those feelings because it is the thing that stops people from getting the job. Right. It is it is something that we lose a chunk of folks because that part of the process becomes stressful. And so. The three things I asked you to do in the very beginning were manager frustration, be consistent and take care of yourself. Hopefully by now you've you've realized that you know what? This stuff is very frustrating, but I can fucking do it. Right. HTML is frustrating, but I can fucking do it now. CSS was frustrating, but I can kind of do it now. Basic JavaScripts, functions, variables, conditionals, loops are fucking frustrating, but I can do it now. Right? Building a backend application was really frustrating, but I can do it now. Understanding what Express was bringing to the table is frustrating, but I can do it now. I can take binary envelope, boom, I can turn it into my MVP. it was frustrating, but I can

04:29:00
do it now. So if you've learned anything over the past months together, is that when things are frustrating, you have the power to actually do them. And so when this part of the process gets frustrating, just rely on the things you've been able to do over these months, because you can actually fucking do it. So as it gets frustrating, remember that you can still do it. The being consistent is where this part of the process needed most. So making sure that you've you're not going into your days like an accident, make sure you're not going into your weeks like an accident. Make sure that you are planning out when you're doing your networking, your hit listing, make sure you're planning out when you're doing your code wars and make sure you're planning out when you're working on your hundred hours project. Like don't go into these weeks like an accident, especially once you start the hunt and you're applying to jobs and getting recommend to jobs like then you're you really need you're like managing a pretty intense schedule of stuff that needs to get done start

04:30:00
now at that consistency and then the last and most important bit was always take care of yourself make sure you're doing palmidoro make sure you're taking breaks making sure that you're trying to stay healthy that you're trying to stay hydrated that you're doing the things they're gonna help you have the mental capacity to get through this crash of ineptitude, right? And so it's not an easy ask. It's a very hard ask. Just know that you're not alone. We're community taught. Make sure you're jumping on discord. Make sure you are reaching out just for support. And then also know that sometimes you need help and it's okay to get the help that you need, whether it's the mental health providers or things like that. No. And you're a baddie. All right, if we're anything, we're baddies. Be right back, let's go.

04:31:00
Cool. Like I said, I wanna go through some of these kind of quick questions here. We'll do the first hour just kind of like these questions. So we got like 15 more minutes left of questions And then we're just staying all back in from from that point on I'm just seem like there's most people are uploading these types of questions So it's one takes some time to do it because we haven't had an actual office hours The hit list networking method keeps being a fail people don't have a Twitter or an active on LinkedIn Tried with over 25 companies use hunter. You should be emailing them Most people won't have a Twitter and most people won't be on LinkedIn. You should still be able to find them using Hunter, which will give you the way that their emails are formatted. It also sounds like you're probably targeting too small of companies. If you're targeting too small of companies and they're a 10 person

04:32:00
team, there's a good chance that they won't have a really strong online presence. What do you say when you email them? We're going to actually cover that. We're going to do hit lists live. So we're going to do like how to build out your hit list, how to actually start the hunt, how to start reaching out to people. I'm going to show you all the messages that I would send, the emails that I would send. And so we're just not at that, that class yet, but yeah, if you're worried about like, how do you reach out to these people, I got you. Yeah, it's not creepy, it's networking, exactly. There

04:33:00
are so many interconnected parts in a project. If you were building from scratch, what order would you make the files, MVC order? It's up to you. Everybody kind of does things slightly different. I like to think about my data first. So I'll often think about the different types of data, how that data is going to be connected. And then I'll typically think about my views. So I like to think about my data first, And then I like to think about my views and so I'll I'll code out maybe like my model first just to know what type Of data I'm gonna be keeping track of and then I like to cut out my view And then I kind of just walk through loading that view. So I'll build out the route. I'll build out the Like the router file. I'll build out the controller And then I'll connect that controller to the model that I wrote out first So that's the way that my brain works the best some folks do it the opposite order where they do the view last It's kind of up to you and how your team works.

04:34:00
Can you walk through setting up Tailwind on the binary upload boom code? Yeah, that's a pretty cool idea. We can definitely probably do that. With Tailwind though, it's just linking the CDN, that's it. It's just, it's wherever you're grabbing Tailwind from, you're just adding that in your head and then you have Tailwind. So where you see the bootstrap link, you would just replace that with a Tailwind link and that's it. Especially if you're not like using it like as part of like React or anything, you're just like using the Tailwind classes. You're just gonna swap that bootstrap line with the Tailwind line. Yeah, and then yeah, there's a script. But like the Tailwind website shows you exactly what to add, you know.

04:35:00
What's the difference between principal, staff and senior positions and which one should be a priority? Principal, staff and senior for folks that have been coding for a very long time. Typically, when you're when you're at a company, there's two tracks that engineers can go down. You can eventually go down like a managing track where you're managing other engineers, or you can go through like a principal engineering route where you're going to keep not worrying about managing folks, but just continuing to own more and more of the product in terms from a technical perspective. Um, so you're not managing people, but you're the expert at that thing at that company. Uh, and so once you go decision to say, you know what, I'm not going to keep managing, you might start seeing other titles that become staff engineer, principal engineer, things like that. where it's just kind of demonstrating that you kind of are like the most senior person or one of the most senior folks in that org or that particular thing. But

04:36:00
I don't think that's something we have to worry about for right now. You won't be applying for like principal or staff engineering positions if you're kind of completing the program. Or maybe you will, don't let your dreams be dreams. I'll know your life. I had a recruiter reach out if I knew React, what would I say in that scenario? Of course I know React. Actually, do you want to see the project that I've built with React? Then you would show them the project that you built with React. You could show them, hey, like I build very simple UI elements. You could have literally shown them the code that we did on Thursday. If you've worked through the travesty media video, then you got something to show. If you did the Kent C. dot course, you definitely have something to show. And then if you come on Tuesday, we'll build a simple app with react. And so,

04:37:00
yeah, you never answer, you always answer those questions with, do you know? Absolutely. You want to see what I've built? Like that should be your just default. Yeah, of course. You want to see what I built with it, right? And then you show them. And that's why having like a really good up-to-date GitHub that has like a repo with that type of code in it that has the readme template that we always ask you to fill out so they can see kind of like what it looks like, what it does, maybe have it hosted. Is it possible for someone to work and be in CS at the same, for college at the same time? Yeah, I've had a few students do it in the past. I don't actually recommend it. They always were having the most hectic of lives. Yeah But if my thing is like a lot some companies will pay for you to go to school So that's kind of like the only time I recommend university is like if somebody's paying for it And so

04:38:00
this my past students that went back to university is because their company was paying for them to go It just made sense Spain said, how would I showcase back in stuff in my portfolio since it's not something visual? Yeah, you can still take screenshots of the code, you can still have any type of demo for it. If you're still following the readme template, even if it is back in code, welcome MP. You Can we do Pokemon cards

04:39:00
if we have time, yeah. Are we getting info for 10 premium apps? Once we get into the hunt, we'll talk more about those. I'm still fumbling through my JS understanding and still need assistance. Lots of Googling with Code Wars, is all hope lost? No, absolutely not. I mean, welcome to learning how to code, right? So if you're still fumbling, that's great, right? If you're still Googling, that's great. Just all the things that you're learning you should have in your Anki. And the only time that that fumbling or that feeling of lost is warranted is if you're seeing the same problems over and over again and you're not able to solve them. That means that there's probably some gap in your learning how to learn that needs to be addressed so that when you see the same problem or the same type of problem, you're able to apply all the hard work that you've done to that problem. So that's the only time that it's a problem. But a lot of times most folks adhere to the 20 the 20-minute rule with specifically

04:40:00
with code wars where? When I do really advanced code wars, there's a lot of times I can't solve it in 20 minutes I don't beat myself up about it. I stop look at the solution and make sure I never forget that solution for the rest of my life But uh, you're gonna be googling every day on the job Like every day, especially as an entry-level engineer, you're gonna be googling hundreds of things It's a skill, and so it seems like you're developing that skill in the appropriate way. The only thing that I find troubling is the all hope lost. No, the only time hope is all lost is when you decide to give up. That's it. As long as you're not giving up, you're still putting in the work, and you're developing skill sets to learn better, you're in a good spot.

04:41:00
All right, we're gonna do like seven more minutes of questions. We'll take our top of the hour break and then we're jumping right into binary blue boom and spend the rest of the time doing back end. Uh, I've been struggling a lot with class. I've done every class twice, done every homework twice. I do Anki. I do two daily code wars, but I still feel like I don't know enough. Welcome to the club. Uh, you will never know everything. There will always be somebody that knows more than you. Are you progressing? Are you able to build stuff? Um, are you doing the things that are required of you? You'll be fine. Yeah. Do we get club jackets, the I don't know enough club. Yeah. I mean, it's, it's part of being a software engineer, right? Like that, that's, that's the, for some folks,

04:42:00
that's the reason why they don't like engineering. It's every day you sit down to solve a problem that hasn't been solved before. You have no idea how you're going to do it. You maybe have some educated guesses. You got to send a lot of research. You got to figure it out. You're going to get stuck. lots of bugs, lots of like things like, um, and that's just part of the, the job. Right. And so, um, definitely don't get down on yourself, make sure that you're still being consistent and, and give yourself that grace to pick up things, right. Um, I think a lot of folks come to coding, right? Well, we know this, like a lot of folks come to coding, like, like it's, it's like joining a gym, right? Most folks join the gym and a month later, they're no longer in the gym. Once you realize the amount of work that it takes, once you realize how difficult it actually is to learn anything you need to learn, that can be very overwhelming for a lot of folks. But that's part of the gig. Eventually some folks

04:43:00
find that the most enjoyable part of the gig is the sitting down and having no idea and coming up with a solution that can be fun for some folks. And so you wouldn't beat yourself up with, like, let's say that you are learning Japanese for the first time, right? After a month of learning Japanese, you said, you know what, Leon? I went, I watched, I watched my Japanese lectures every day. I did them twice. I did my homework twice. And you know what? After a month, I'm not fluent in Japanese. Like, what is wrong with me that I'm not fluent in Japanese after a month, right? That's wild talk. We would never expect anyone to be fluent in a very hard language after a month. We wouldn't expect someone with daily practice for three years to be fluent in a language like Japanese. There are some things that we can see. For some reason, we can see language learning in terms of a difficult language like Mandarin or Japanese and see, you know what, yeah, it's gonna be a

04:44:00
lifetime time of practice to reach fluency, right? But when it comes to engineering, we're like, we gotta get this done in three months, right? Like, if I don't have this done in three months, like if I'm not, if JavaScript's not clicking, if everything's not making sense, if Node's not making sense, React is not making sense, and I don't get this done in one month, like, it's over. No, it's the same thing. You're on a lifetime journey of learning to code. Some things are gonna come really easy, something's going to come really hard and that's part of the process, right? So, um, I just don't like when folks kind of get down on themselves about that. It's not easy. It's hard. The trough of sorrow is real and you shouldn't expect that fluency to come quickly. Keep managing your frustration. Keep being consistent and keep taking care of yourself and it will come. Always seek out better learning resources. Always seek out help on discord and it'll. All right, let's talk about binary upload boom folks. We, we let's, let's, uh, let's take a look through it. Let's kind

04:45:00
of see all the bits and bobs and functionality. And then let's take our journey through, make sure everyone feels comfortable with the code. Should we code along today? No, there's not any kind of code along, especially for this part. We're just gonna try and talk through all the major pieces and see if there are questions. So feel free to ask lots of questions in chat. Also feel free to use the Slido and upvote the questions that you want to see answered. Let's keep them more backend focused though. Alrighty, so I'm gonna log in, do ron at ron.com. Boom, what we have right here is that we have a nice signup for me, a nice login. I can submit the signup or login. I have the ability to have a post. I can add a title, a

04:46:00
caption. I can choose an image to upload. On my profile, I actually have the ability to see all the photos from my specific profile. I can go to the feed. I can see all the photos from the feed, which is pretty cool. and then on individual posts, I have the ability to like individual posts, I have the ability to add a comment, right? And I believe there is one that already had comments. Let's take a look. I think it's this one. There you go. And so we can see that there's already some comments on this post. So very, very simple kind of social media application, some very, very kind of simple functionality, but, right, but it can be extended to do whatever the heck you want. So as we were looking at these MVPs coming in,

04:47:00
seeing everyone that was able to take Binaural Bloom and kind of run with it was great because the core bits of everything you need is here, right? The ability to have user authentication, user logins, to have individual collections for the different things that you care about. In our case, we have users, we have posts, we have comments that we eventually built out too. And the ability to tie all these things together using IDs that were inside of our URL strings, like our parameters, is huge. and so we can take a journey through this code base because at the end if you can get this running you can you can understand how this works you can really build whatever it is the heck that you want it really does have everything you need to kind of get started for most applications we have all of our simple CRUD applications here are creating our reading or updating our deleting and

04:48:00
so it's It's all kind of here for us. Ron is Sarah's brother. Just saying. For those that are keeping up with the lore. We see the MVPs. We did ask if we could share them publicly, so there will be a thread that I'll post on Twitter with all of the cool ones that people asked, that said they could share publicly. All right, so let's, we kind of walked through the key bits of functionality. I want to take some time to whiteboard out the application just like we did before. So we have these different kind of views here. We had a profile page, we had an individual post page, and we had a feed. So let's start with an individual post and that post,

04:49:00
let me refresh this whiteboard, there we go, all right. So let's talk about an individual post to start and on this individual post, there's gonna be a little bit of data. So on individual posts, So we're gonna have probably like the actual image itself. Right, so we'll have the actual image itself. And then we want some other bits of information here. We want the caption. Right, the caption. And we want, what else chat? What else do we want on this post page? Want to catch them a little bit bigger so we can see Yeah

04:50:00
All right, i'm saying caption like it's just like the the actual like text for the for the post right text Cool, uh, we want like the title I think we have like a title for them as well. So and we have like the title We have the title for the post. We have the text for the post. We also had the number of likes. So let's go ahead and put likes. Zero, cool. And then we also had the ability to have comments down the line. So we can just put like a little place for a comment for right now. So we'll have comments and then for our comments to work. We're also going to probably need like a form or something But for now, let's keep it simple Like our post page will have a title number of legs some text for the post and then there'll be comments down here at the bottom We're

04:51:00
gonna need a button for the likes. Exactly. Let's go ahead and say like there's like a button for the likes Let's just do a circle This is like the like button Oh, and then if it is our post what we want to be able to do If it's our post what do we want to be able to do? Yeah, I'm gonna be able to delay Tay so we're gonna need a delay Tay here let's go ahead and just put like a Trash can or delete. Cool. So our individual posts are gonna have a lot of little things going on here. We're gonna have a title, we're gonna have the number of likes, we're gonna have some text. We'll worry about comments a little bit later. We're gonna have a like button and a delete button. Beautiful. So like and

04:52:00
delete. Okay. And if we're gonna have this type of post, we're going to need a collection for each post. So each post will be its own document in our collection of posts. And since we know that this is an application that has users, we're probably gonna need a few collections. We're gonna need a user's collection, we're gonna need a post collection, and then eventually if we have comments, we're also gonna need a comments collection. And so I really have to break down my applications into the different types of data. And each different type of data has its own collection. I remember collections are just groups of documents. Documents in MongoDB are really just kind of objects. They have a little bit of extra, right? A little bit extra, but we can think of our documents as just objects. So let's go ahead and set up those collections real quick. Let's go ahead and do

04:53:00
users. Oops, I need to change this to a square. We'll have our users collection. And inside of our users collection, let's just go ahead and put users on top of here. Users, cool. So each user will be its own document in our collection. And what type of information are our users going to have? What type of information do our users need to have for this to work? When we create a document, we know that what is always created when we create a document every single time? Yeah, we get a unique ID just by default. So we know there's always gonna be an ID that's created for each user. So we have, let's just pretend that it was like,

04:54:00
let's do 200 for that user. What else do we need for our users? Username. Say like username, cool. What else do we want for our users? Email. Nice. Password. Nice. Anything else that we should keep track of here? Cool. All right, let's stop here for now. We might come back and add something later. Yeah. We could add things like display name here. We could add things like a

04:55:00
profile picture, things like that. But for now, we'll keep it simple. Great, so let's say that this user is Ron. Their email is ron at ron.com and their password was ronronron. But we're gonna be doing something that's going to hash our passwords. And so it'll look something that's kind of just all over the place. Because remember, we are using hashing, which will take the password we enter and do some fancy maths with it and give us a hash version of that password where we can then, whenever somebody types in that password, we can compare the hash of that password versus the hash we have stored in our database. If they're the same, we know that the user typed in the right password without having to store that password in

04:56:00
plain text. If we were to get hacked and all of our passwords were leaked, we wouldn't put people's other accounts at risk. Cool. So this is just one user. Let's go ahead and create another document that's similar. Cool, so I'm just gonna go ahead and copy this, put a paste, and so we know we have another user in here, which is Bob, so we'll say that that Bob was user 201. We had Bob, we'll do bob at bob.com, and they would have a different password, so it'd be a different random mix of stuff after it got hashed. Cool. If I wanted to sort input data,

04:57:00
not just by users, but what department users were in, should I go about signing each department's own collection? You could, but if the department is just an attribute of the user, I would just create a department property on the users, right? And then you could just put like sales or whatever, just in that user. And then each user would have its own department just as a property. Yeah, I think that's the easiest way. Would it be technically possible for two users to share a post? The way that we're probably gonna code this out, no, because each post will be made by a specific user and each post will be unique, meaning that when the post is created, it's also gonna create that unique ID, which will never be repeated. So the post could have the same

04:58:00
title, the same likes, the same text, everything, even the same comments, but on our backend, like in our database, they would still be unique because the random ID that's created for that post would be different. How would you add friending functionality to Bubb? Very quickly, you could add like a friends array if you wanted to, right? And you could just push people into that friends array. Not necessarily how we might do it long-term, but if you're talking about for like an MVP real quick, boom, that's it. Friends is an array, you push people into it and call it a day. You just put their IDs in there. That's also how we could restrict like liking

04:59:00
to one, to just new users. So you could push the people that have actually liked that post into an array, and then when they try to like it, you check to see if they're in the array or not. Cool. All right, so now we've got our two users here. And we're also going to talk about posts. Let's go ahead and build out our post collection here. Cool. And our posts are gonna be made up of individual documents as well.

05:00:00
Let's go ahead and just put some documents in here. And I know that this process is a little, can be a little tedious, especially if you're not the one actively doing it, but it really does help to plan out your applications like this. Like if you're planning out your MVP, please do this. When you're like that first, like when you're in those first three months on the job, do this for your, for your, the job, right? but like really sit down and think through the application and specifically the area that you'll be focusing depending on what team you're on. And a really good way to try and get a handle on what's happening is to like sit down and do this type of architecture on your own. Even if it doesn't match what's actually going on in the code base, try to think through critically like how you would build the application that you're working on, how you would segment data and things like that and then and then going and looking to see if it matches up to what you what you thought

05:01:00
can be really helpful and by the end of like your first two to three months on the job writing out some really good documentation that lays out like from beginning to end your entire application will help you but also solidifies the process making it easier for that comes after you. Uh-huh. Alright, so let's talk through our posts. We know that our posts are going to have an individual ID as well that's created automatically when the document is added to the collection. So let's go ahead and do underscore ID. And let's just say that this ID started off at the, let's say,

05:02:00
I don't know, 600 mark. Let's do 700. I'll start off, the post was the unique ID of 700. And then what do our posts need? What's gonna be in this document? What are some things that are gonna be in this document? Yeah, we're gonna need the title. Like if we're looking over here at this post, we need the title. So it would just be some string like cool photo. We're gonna need the text for the action. Actual kind of post This was outside We're going to need the image and In this case where our image is going to be stored Are

05:03:00
we like storing the images like locally on our server? Where are we storing our images? Yeah, we're gonna use cloudinary and so that's we're gonna use cloudinary we'll upload our image to Cloudinary and then Cloudinary will give us a image URL back. So we're gonna say, all right, this is Cloudinary and it'll be something URL and like it'll just be an image from Cloudinary. And so we're not actually storing images on our server. We're uploading those images to a service called Cloudinary and they're giving us the link to that photo. So in our database, we're actually not storing any photos. we are just storing the links where those photos are existing. Cool. We need a poster ID. We need to know who made this post. So we'll say poster ID. And so we can know who made each post by tying the poster ID to a specific ID

05:04:00
for a user. So we'll say poster ID equals 200. And if the poster If the poster ID was 200, what would I know about this post? If the poster ID was 200, what would I know about this post? Yeah, that Ron made the post. If the poster ID was 200, we know that this post was made by Ron. Well, we're also gonna need the number of likes, which at this point right now is zero. and is there anything else that we're going to need? Jedi says delete. So when we delete something off of Instagram, is it actually deleted?

05:05:00
Wait, I don't know, I don't work at Meta, but what we could do is we could have this set as just like a Boolean, right? We could say, all right, if they delete it, just mark it as true, but don't actually delete it, you know? Soft delete, exactly. So it won't show up in their feed or on their post anymore, but we're actually gonna delete it from the database. Do you have any advice on a user only being able to post once? Should we store an IP? Well, since they have logins, you could just restrict the ID of the logged in user. If you're trying to like stop people from creating multiple accounts and posting, that's definitely something you would need to like invest engineering power into figuring out. Now there are definitely solutions to stopping that, but probably outside the scope

05:06:00
of our time together. Why not actually delete it? Cause I want the sweet, sweet, sweet data to resell to advertisers later on. Now there are like new regulations that came out specifically through Europe about like actually being able to delete stuff. So things are changing, but back in the day, yeah, probably nothing was ever being deleted. Cool. How could you stop them from liking a post a million times? We could have a users who liked, and it could be an array, just to like keep it real simple, right? So we have users who like, and so we could put in here 201,

05:07:00
right? And so when I look at this post, right? When I look at this post, we would see Ron, who's Sarah's, let's just think about this for a second folks. Ron, who is Sarah's sister, made a post and Bob liked it. Do with that information what you, what you will. But if we look at this, we can have this array of users who like, right? And what can we do with that information? Like what could we do? Now, now we know that Bob liked it. What, what, what could we use this information for? Blackmail. Yeah, we could use it for preventing Bob from reliking,

05:08:00
right? So if Bob was to try and click that like button again, what would happen is on our end, we would check to see, all right, all right. Person who just tried the like was user 201. Has 201 already liked this? If so, don't let them relike. We could also, what else could we do? Like when we build out the DOM, right? What could we do as we build out the DOM for this post? Yeah, we could literally just not show it, right? like we could just not show the like button. So if they've already liked it, we could just literally not show the like button again. We could maybe have some style on it if we want to keep it there, but once we know who's liked it,

05:09:00
we get control of what they see, particularly in the DOM as well. And the cool thing is once you're using these arrays, I think somebody said it in chat a little bit up there, There are methods built in with MongoDB that we've seen. We've seen like increment, I think we saw was one, set was another, but there are these other methods that make it easy to like push and pull and do all that fun stuff into arrays and things like that. Yeah. Yep, exactly, peace. Cool. All right, so we have our users, we have our posts. We should probably have like one more thing and that would be our comments, which will definitely be extra, but let's just talk through it for now at high level. It's just to have like a high level overview, just so that it's in our brains.

05:10:00
All right, cool. Let's go ahead and label this comments. Cool. And we want each of our posts to have a comment. We want each of our posts to have a comment. Let's go ahead and put our first document into this comments collection. Cool. and so we know right off the rip it's gonna have an ID just like any other document that's created. We'll just go ahead and do our random ID. Let's start these off in like the 900 series. We have a comment ID 900. What's the information we're gonna probably need with comments?

05:11:00
Yeah, we're going to need like the text, right, like the actual comment itself, call it comment Text, cool. And so it'll be like, cool post, bro. All right. We need to know who made the comment. So we could say like, commenter, ID. And right now if this all right, what's the only what's the only comment or ID that this could be? Like what's the only thing this could be right now?

05:12:00
If you can't comment on your own posts, what would be the only answer to this right now? Yeah, 201, right? So let's take it back and think through what that means, right? So we have a post. This post was made by whoever had the idea of 200, right? So we can see that this post, whoever made it, had the idea of 200, which means that this post was made by Ron. So if Ron can't like his own post, sorry, comment on his own post, then the only person that could have left this new comment would have been Bob. And Bob has the ID of 201. And that's why we see the commenter ID 201. There's nothing right now that's actually stopping Ron from commenting on their own post.

05:13:00
It's just a thought. Cool. I'm so thankful Leon is not drawing this. Cool. Hey Leon, one thing is very specific but I can't figure out. My work uses MFA to log into their terminals and have a self-hosted internal site. When you like someone's comment, you can't like it a second time. And when you post a comment, it shows your actual name. How did they hook it up? So we kind of just talked about the comments, right? So we could have, we could have like a likes on the comments, like we have likes on posts, But we could also have likes on

05:14:00
comments as well, I guess. And so you could have likes and it starts off at zero. And then we could also have a liked by array. Right? And whoever liked the comment, their ID would go in here. So if Ron in turn liked this comment, we would throw their ID into that array. And now Ron wouldn't be able to like that comment again because it's already recorded that they have liked it. And so on our end, we would have to do some logic that would stop them from liking, but we know who liked it already. That would be the liking part. And then shows your actual name. That would be what we would do is we would in the rendering of this view,

05:15:00
right, the rendering of this comment, what we would do is when we load this document, we know the ID of the person who made the comment, so we would load the comment into the post view, and then we would query our database again, right, we would query our database again to get who the heck 201 was, and we find that 201 was Bob, and then we'd be able to append that Bob into the DOM as well. So you kind of be doing, and this, like I said, this is like high level, we're building MVPs, right? We're being baddies writing bad code. That would be the two, you could think of as two individual queries to our database. There isn't a login, yeah, there's still some sort of way that they're authenticating you. So whatever they're using to authenticate you is tied to

05:16:00
the backend. Yeah, there's still some sort of authentication happening if they're able to have that information. and it can be tied to your authentication scheme, it can be tied to your IP address, you know. Yeah, a lot of big companies have a VPN exactly, so if you're already on the VPN, they already know who you are. Cool. And we actually did, last cohort I did a class with Microsoft, uh, where we showed, uh, Microsoft's authentication. So kind of similar to like the homework where we watched, uh, uh, Brad walk through the Google authentication. We did it with Microsoft. And the cool thing about using those types of authentications is that you often get a lot of other goodies baked in. So, uh, with the Microsoft off, which is free, you can do like two

05:17:00
factor authentication like text message verification like either like a two-factor application or text messaging stuff like that and they handle a lot of like the heavy lifting with user stuff and so you might find for your MVP that you do some like local login but then you might take the passport strategy and use a different strategy that gives you some sort of other login if you you want some other stuff like two-factor authentication, things like that. And so that's on my YouTube if you wanna watch that. Same thing with password resetting and stuff like that. That's not something that you would necessarily know how to do. It's something that you're just gonna take from Passport. And so you're just trying the strategy that does that and use it to your will. I've also shown in class things like the hackathon starter

05:18:00
kit, right? So like if you look at like the hackathon starter kit, let's pull that up. Hackathon starter. Right? If you look at like the hackathon starter, the reason why I actually kind of like reference this every once in a while, because they have everything here. Let's look at their hosted site. Cool. So when you create an account, you can do like the local email signup, but you can also log in with Google, Facebook, Instagram, Twitter, LinkedIn, Twitch, GitHub, Snapchat. It already has the forgot your password and everything set up. And so you could yoink these strategies for the bits that you care about. And so that's just something that if you cared to do it, you could pull it out. I just like that because the strategies are kind of all

05:19:00
there already. You might have to see if they're completely up to date. I know this is a little bit older of a project at this point, but it's a good starting place for if you care about those things. Yep. That's kind of like the timeline we're on. Good guitar guy. Cool. All right. Keep asking these questions. Like that's the point of today. We're going to be going over the code. Yep. I like to whiteboard through the big concepts first and before we start jumping into the code. I think it's too much. But yeah, keep asking questions, please. I'll keep an eye on chat. That's the point of today. Like, we've already done this, right? So we've already built out this code base. We've already had, what, four to five classes on it across different

05:20:00
pieces. Today's about kind of revisiting it, seeing it, being able to ask questions about it, things that are still stumping you. Please ask so we can go through them together. That's the point of spending so much time together today. Do you think three months of learning 10 hours per day is enough to get a job? Yes, but you'll probably burn out. Most folks can't actually do 10 hours a day of learning, because learning is very different than just like regular work. Um, have I seen people do it? Yes. Is it rare? Yes. Manage your frustration, be consistent and take care of yourself. And hours a day, maybe not the easiest way to take care of yourself. Cool.

05:21:00
Everybody's different, so I know some folks that can grind out 10 hour days, no problem. I have some folks that after two it's rough and so it's a spectrum, like there's not one time fits all. And if anybody tells you like, oh, 12 weeks X, Y, Z, nah, it's all cap. It's so dependent on you, how you learn and the community that you belong to that's helping and support you through your highs and lows. Everyone's different. Yeah, everyone's different. Cool. Alrighty. So we have, let's finish up these comments real quick and then we're gonna start looking at the code. So we

05:22:00
had an ID for like the actual comment. So every comment will have its own ID. We said comment text, so like the actual text of the comment. Now we did a commenter ID so we know who made the comment. So the idea here is that all of these pieces are connected through the IDs. Like that's the trick here, right? And so our comments, we know who made the comment because the commenter ID is tied to an ID of a specific user. We know who liked the comment because that ID is tied to a particular user, right, the 200 to 200. But where I think people get tricked up by is like, is commenter ID a thing? Is poster ID a thing? Like, is that something that's built into MongoDB or that is given to us through Mongoose? Yeah, no, it's not built

05:23:00
in, we made that up when we built out the schema for our model. Exactly. We made that up, right? And so the, the, the, the, like those bits, those words, we're making them up. And so that's kind of tricky for folks in the beginning, but we're kind of making them up. We can call it whatever we want. There is something that we still need for the comments. Like what's one thing that we need for this comments for this to actually work? We're missing one piece. Yeah, we need to know what like post the comment is tied to, right? Like if we have like thousands of posts, how do we know which comment goes with which post? So we need something like a post ID,

05:24:00
right, we need something like a post ID, and that post ID would tell us what post this comment belongs to. So what would be the post ID for this comment? Yeah, it'll be 700. Right, we only have one post. So since there's only one post, we know that this comment is tied to this post with that post ID. Now, like I said, it's all made up. So I could call this unicorn and it would still work, right? It would still work. That text has nothing to do with it. It's just that when we are consuming this data to build out the post and to build out those comments, we're not doing something like .unicorn, right? That would be a little bit hard for us to understand what unicorn is supposed to represent.

05:25:00
We call it post ID because when somebody looks at it, they go, oh, this should be the post, the idea of the post that this came from, yeah. Can anyone hack data by underscore ID? Technically, yes. Like if there's, like the way that we've built some of this up is that if they're able to manipulate like what's in the DOM, maybe they might be able to do some tricky stuff in the background. But I think that's something that maybe after program we can spend a little time talking about. And each company kind of handles that a little bit differently. All right, so now we have users, we have posts, we have comments, we have an individual post page. One thing that I think is important to note is what would the URL be for this post? If we had to come up with a URL, we're on localhost right now, 2121.

05:26:00
What would this URL look like? Yeah, we might give it a route of like post, right? And then what would be the, what would we put the last bit here in this URL? Yeah, it'd be 700, right? So if we're building out this post, we'd give it like a post route, and then there's only one post that we have in our database here, and that has the ID of 700. So we put that ID in the URL, right? We put that ID in the URL. And so that way, when we go and load this URL, we can make a get request to our server to go and get all the information from that post that has the ID of 700. Yep, give it a refresh. That's kind of the only thing

05:27:00
you can do. Yeah, so now we're leaning really heavily into these IDs, right? This idea of 700, right, is being tied to this post. And so we load this URL, we're going to have in our code base, the ability to be like, all right, we're looking for something on this post route, you're looking for something that has the idea of 700, we're going to go to our post collection and find that post that has the ID of 700, yoink all this data, to plug in what we see here in the post. Cool. So that's the post. Let's do one more post, just so that we have some other stuff to show here. And paste that. We have another post,

05:28:00
let's call it 701. We're gonna call this AO, text, we online. There'll be a different image from Cloudinary. The post ID, the poster ID, let's say it was made by Bob, so it'll be 201. Bob's gonna have like thousands of likes, so that's easy. It's not deleted and who liked it. We'll say that Ron liked it. So there will be 200 in there Well, oh man, we can't control ourselves, huh All

05:29:00
right, so now we have a new post as a new ID, because whenever a document's created, it gets its own ID, has a title, has some text, has a new URL that came back from Cloudinary, has a poster ID, has a number of likes, and we can see who liked it. So once again, this poster ID, right, this poster ID is tied to the person that made the post, in this case, Bob. All right, so the last thing I think we do before we take our break is let's plan out the feed. Let's plan out the feed here. So we're gonna have, boom. Let's call this our feed. And so our URL, just be localhost2121. 21, 21, I'm able to say slash feed for now. There we go. And so on the feed,

05:30:00
it'll be pretty simple. What are we gonna do in this feed? What are we gonna do in the feed here? Yeah, we're gonna show all the posts, right? We're gonna show all the posts. So when we go to this route, we know that we're gonna do is we're gonna make a request to our posts collection and we're gonna grab each post. And so if we were to go to this feed, we'd wind up seeing two posts here. Right, we can maybe just put them all maybe in order here. We wind up seeing two posts. Boom. Boom. And those posts will be pulling directly from all

05:31:00
the posts in our collection. So the feed is probably the easiest. We don't really need to check for anything. We just make a get request to our post collection, grab the documents and use those documents to build out our feed. We do also have a profile that we want to build out. We still got like five minutes. Let's talk about profile real quick. So our profile is a little bit more complicated because our profile, we're gonna have a couple different things on here. Maybe we'll have like our, um, like our username. All right. It was like our username. And then maybe we'll also have our actual posts that we submit it. Boom. So if this was, if this was Ron, so let's go ahead and say this is Ron that will show up,

05:32:00
right? We know that this post would be the post that had which ID? What ID is the post that's showing up in the profile? The post, the post ID. Cool, yeah, post ID 200, right? because we know that this is Ron. So we're gonna find all of Ron's posts. So we would find the post that had the poster ID of 200. This one here has a poster ID of 201. So I know Ron didn't make this post. So only one post has the poster ID of 200. And so Ron's posts would show up. Now in terms of the URL for the profile, there's kind of like two routes we could go. I think in the binary upload boom right now, we don't actually have individual profile pages. Like we don't have something like localhost

05:33:00
2121 slash profile slash 200, right? Like that would make it so that we have individual profiles for Ron. Right? So that means we could have, this would be Ron's profile. If we went to 201, this would be Bob's profile. Right now, the only way we get to a profile is by what? Yeah, once we're logged in and we have that session, we're looking at the logged in user that's a part of that session. And so what we have to remember is that when we're logged in, every single time we make a request, we're sending all the information about that logged in user as well. So when we go to look host

05:34:00
2121 slash profile, we're able to see that we're logged in as Ron. And since we're logged in as Ron, we are able to grab all of Ron's posts. So right now we're not actually having individual profiles for individual users. We're just looking at whoever is logged in, right? whoever is logged in and grabbing their specific photos. How would you implement a public user profile? Kind of exactly what we just showed, right? Like we would just say, all right, slash 201. And then when somebody makes it to that page, right, when somebody makes it to that page, what would happen is we would go ahead and make a request to the users, find out the information about the user, which would be

05:35:00
201, we'd grab Bob, put it in there. And then we make another request to our post collection and find any posts that were made by that 201 user. So we'd find the post ID of 201, we grab that post, put it in the profile. And if we were doing profile pages for users, what wouldn't show up on this profile page? There wouldn't be showing up. Look, remember we have the ability to create posts as well. And we put that form on the profile page. So if you were on your profile page, you would have the ability to create a post. But if you're just visiting anybody else's profile, we'd probably have some like EJS logic that wouldn't show that form. Yeah, it would just be the person's information

05:36:00
and all their posts. So how do you do what LinkedIn does so we can edit the profile URL to be something else. There are a lot of different ways to handle that. It could still be the same concept, right? Where the URLs are unique, and so you could just grab the URL and show that profile, same thing. When you're working on a project like this, building it out, how do you discipline yourself to not jump straight into the code? I'm finding that laying out my stuff on the whiteboard first is overwhelming. For me, it's the complete opposite. If I don't lay my stuff out like this, I just know I'm gonna get lost in the sauce. And so I rather come back to the whiteboard than go back to my code. Because the whiteboard, I can make changes really quickly. I can think about the problem from a high level perspective. If I just jump into my code,

05:37:00
I'm lost in the sauce and I don't even know where to go. So I always whiteboard out all of my applications. I actually have a big ass whiteboard on the wall. One of my walls is entirely a whiteboard. I do this for every single project I will ever work on. And exactly how I'm doing it right now. This is why I know I showed it during class. And it's why I'm also showing it again. I'm spending a whole hour showing you how I whiteboard through things, because I think it's just that important of a skill, especially early on when you don't have that like intuitive sense of like what different types of data should be their own collections, how you're going to link things through together. Taking the time to do this, right, would be well worth your effort, I think, in the long run. And it can be overwhelming, but I'd rather think about the decisions here than think about the decisions in the code base, because then you're adding a whole other level of complexity.

05:38:00
Do we need a collection for profiles if we decide to have public profiles? I don't think so, because I think a profile is just the combination of user data and post data. So you'll grab information about the user and you'll grab information about their post to put into the profile. I don't think we need anything more than that. But if you're thinking something extra, then maybe. Been at five hours doing the mine for your hijab, it's probably gonna be dope. Yep, and you do refactor this whiteboard a lot. Like a lot of the stuff that we have here right now won't make it into our code base, right? Like we're not gonna, we don't have liked by, we don't have users who liked or anything like that in our actual code. but it gives us some next, um, um, next features to add. Like you will, like, this will come up. You'll be in, you'll

05:39:00
be interviewing and someone will say, this is an amazing project that you built referencing your $100 project. What optimizations would you make? What features would you add? It's a very, very common question, right? Very common question. Somebody, you spent 15 20 minutes talking through your $100 project with a potential employer and they'll end with being, oh, what optimizations would you make? What features would you add? And you'll be like, well, let's take a look at my high-level wireframe here, my high-level wireframe here. And let me show you exactly what optimization is about to make, what features I'm about to add. I already got this planned out. You're seeing day one of a long-term vision, Right? And then you show them the whiteboard. And you put that in the readme too, exactly. What other high-level diagramming tools do you find

05:40:00
useful? I don't really use anything else other than kind of like whiteboards. I mean, I've done it all. I've used Basamic, I've used Figma, I've used Sketch. They're okay. I just like whiteboarding. I think there's a, there, I, I personally fall into the trap of trying to build better and better productivity systems instead of just doing stuff. I'm a person that'll take like a, like three weekends to build a better productivity system to only not use it a week later. All right. So now we have a good overview of our app. We're going to be having the ability to have posts, a feed, profile pages. And so we're at the top of the hour, went a little over. So we're going to stop here. We're going to take a break. Cranberry cat added two minutes to the timer. So we'll do a seven minute break. When we come back, we're diving into the code, folks. We're looking at this binary upload

05:41:00
boot from beginning to end. We're going to make sure we understand all the bits and bobs, all the quirks and features, and make sure we feel really solid for folks that are still finishing up their MVPs. So we kind of broke down the application. We have our three major views. We have our three collections. We're gonna have some data for each of these tied to our users, our posts, and our comments. Let's go ahead and take a look at the code. So this is just the normal binary upload boom code that we've been running for a while. Grabbed the URL just for folks that need it. There you go, gonna throw it in chat in case you need it.

05:42:00
Am I sipping on anything today? It's been it's been a long Been a long day already having been Locked out and dealing with all that fun stuff. So I'm on the diet coke wave today And a little go-go juice, you know, I mean Well Is the version with comments available? Yeah, it was available since we did it. I just put it on a different branch. So if you go to GitHub, oh, not my GitHub, and you go to the binary upload boom, and you look at the branches, You'll see that there's the main branch

05:43:00
and there's a comments branch. So I pushed my comments code to the comments branch just so that, because we did the class, we had to build it yourself. And so if folks need to take a peek, they could, but it wasn't on the main branch. So the comment code has always been there. You want the comment code that I'll be showing today, you can just grab it from that branch or use your own. I think I've drink, I think a Rossi says, I think that's the first time I've ever seen you drink soda. Cause I did a diet coke like a week or two ago. Oh, that's where I was headed. Yep. All right. Let's go ahead and take a look at, should we begin coding along? It's not really a coding along thing today. We've kind of

05:44:00
already done all of this before. So this is kind of a review. This is like a chance to ask good questions, the chance to see things again. But yeah, it's not something that you're gonna have like fingers on keyboard today. All right. So when we take a look at this Binding Upload Boom Code, we have quite a bit of stuff that's here. I'm gonna kind of collapse all my folders here so we can see everything. On the whiteboard, there was a third view, the feed, the profile, and the actual post. The actual post itself. Are we gonna code from scratch? The goal is to go through it, understand everything that's here, and then whittle it away to have a template that we could use to go forward and build it from scratch.

05:45:00
I think that's gonna be a little bit better of our time, and then I think I'm gonna do a part three. Yeah. Cool. So let's take a look. It depends on how much time we have. Yeah. If we can do it from scratch today, we'll do it from scratch today. If not, then we'll probably do a part three. Yeah, to kind of like code along, yeah. All right, so let's take a look at the folder structure that we have here. We have a VS Code folder, which is gonna show up on my end. You won't have that anymore. I when I pushed I repushed the code to not have the VS code folder the VS code folder The VS the VS code review the VS Code the VS

05:46:00
code folder is It timed up The VS code folder is where I put kind of my settings so that what I'm streaming I have a a larger, like screens, like a larger text size and my terminal is bigger. And so that just makes it a little bit easier for folks to see on screen. But that's the only kind of, that's the only thing I have in my VS Code folder, right? And so we have a font size and I have auto-cloaking turned on now. And what the auto-cloaking is going to do is that when I show you my env file, Oh, that didn't work. That didn't work. It kind of like tries to hide it. It doesn't matter, you can't do anything. Yeah. That's kind of the idea.

05:47:00
Cool. All right, so that's kind of what's in my VS Code folder. But what you'll notice is in my gitignore, In my gitignore, it is not being pushed. So the gitignore will have the VS code folder, my env folder, and my node modules folder. So none of this will actually make it up to GitHub, right? It'll actually show it. it will show it on my end, but on GitHub, this folder and these files won't be there. Cool. All right, let's go ahead, one second. Cool. All right.

05:48:00
All righty. What else do we have here? I have my config folder, which is gonna have a couple different bits of information in it. And so we're gonna just kind of work through all the stuff that we have here, right? And so we're gonna have, as we kind of go down the list here, I'm gonna start the server.js. The server.js is gonna be everything we need to set up our server, right? Everything we need to set up our server. We're gonna have all of our, all of our different modules that we need for this to work. We are going to have all the requiring and making sure that we have everything to get this running and working. We have our readme, which we'll be using to, on GitHub, be able to see kind of everything you need to get this up and running, all the different bits and bobs you're gonna need for this to work. and this is what will be showing up on our GitHub repo. We

05:49:00
have the proc file rip. This proc file was originally used for Heroku, but we'll be talking about other hosting later this week. And so this is just to let Heroku know like what we should be, what file you should be running to set up the server. Of course, that's the server.js. Our package.json includes all the dependencies that we're gonna need to make this project work. And so we have a lot of these different dependencies that we're gonna see specifically as we work through each of our files. We have the package.lock, which is created when we do our lovely like NPM install. And then we kind of have the folder structure, a nice MVC folder structure. Our views contain kind of all of our EJS files, right? Has all of our EJS files. And it has all of the, it has all the EGS files and even has some of our partials that we're using, right? Has our partials

05:50:00
that we're using so that we can, we can kind of start to separate out things that we're kind of redo it, like that we're doing over and over again, like our headers, our footers, stuff like that. Very simple components, exactly. We're gonna have our routes, which will help us listen to the different requests that are coming in. As these requests come in, we're going to be able to tell it what controllers to use. Our public folder will be all of our public assets, things that we need for all of our different pages to Lowe's, like our CSS, maybe something like logos and stuff like that if we had them. In this case, it's just our favicons. We have our node modules folder, which are all the modules that we need for this actual application to work. Our models, we'll be modeling the different data that goes into our database, our middleware, which helps us handle everything in between the requests and the responses, right? And so we have a request that comes in and we generate a response. And

05:51:00
so this middleware is kind of the stuff in between everything we're going to need for helping us with authentication, getting our images on Cloudinary, doing things in uploading our files using something called Molter. And don't worry, We're going to see all these as we kind of go through and just doing like high level overview. Our controllers, which is where the real work is happening. We're following that MVC pattern. Controller is going to know when to talk to the model. It's going to know when to pass stuff to the views and it's going to help us kind of return the final product back to the client. And then the config is just the stuff we need for this like to actually work. So the link to our database, the link to our passport JS, all that fun stuff. Cool, so that's super high level overview. We'll spend some time kind of going through each of these bits and bobs, just to make sure we're all on the same page. And then we're gonna try and get this down to a reusable template.

05:52:00
Are we gonna swap EJS for React? We're gonna do the basics of React. We'll build some small React projects, yeah. Yep, if you're posting to Heroku, you're going to want each of your environment variables on Heroku as well. So you can do it as like a config, like you can do it directly in the terminal if you would like, but you can also just go on Heroku's website and type in each of your environment variables if you want to. When we switch to a different hosting provider, I'm going to stop, I'm going to walk you through step-by-step how to kind of make sure that your environment variables get carried over to that hosting provider. Would React totally replace EGS in our MVC? It can,

05:53:00
yeah. All righty, yeah, we'll see some existing apps in React together too. All righty, so let's take a look, starting with our server.js file. Express, what we've been using since the beginning is gonna help us build out our API. Instead of having to constantly kind of require it to get to run wherever we see app that's us actually using Express. Mongoose is gonna help us talk to our MongoDB database. Passport is what we're using for our authentication. Remember Passport, we're using off the shelf solutions to do our authentication. Passport is gonna enable us to use different strategies for the different types of login that we would like to produce. So when it comes to Passport,

05:54:00
we can find all these different strategies. These different strategies will enable us to do different types of login. So I showed the hackathon starter, we could do Twitter, we can do Facebook. In this case, we're doing local, so just email and password. We're gonna have Express Session. Our session is what we're gonna need to make sure that our users can stay logged in as they move across our application. And so this session uses cookies. And so we actually saw in class that the cookies are stored on the lovely client. And so we're able to kind of see that cookie that stays there. And we're able to kind of like use that cookie because every single request, we're sending all this information about each of the users as we make the request. And so with this session, we're able to keep our users logged in as they move throughout the application, and across the different pages, and we're actually able to see who is logged in, and we can use that to build out things like our profile pages, et cetera.

05:55:00
We also have the Mongo store. What would the Mongo store do? What are we using Mongo store for? Remember what we were using that for? Merge. Yeah, it's storing our actual session, right, storing our actual session in the MongoDB. And why would we do that? Why would we store our session in our database? What is that doing for us? Yeah, it keeps you logged in. even if you leave the application, even if you leave the Pays, you come back, maybe you close the window exactly, maybe

05:56:00
you leave the browser window and you come back, you can still be logged in. So it helps us keep that connection no matter what our users are doing on their client side. Then we had method override, and this was the last big addition. What we're realizing is that what we're realizing is that the clients we've been using, aka the browser, really only does which methods? Yeah, it only really does get and post. So we've been using Web API, specifically the fetch API, to handle delete and put, but we can use this method override to not really worry about what the client exposes, like what the client actually gives us. We can override the methods that are

05:57:00
coming in to be what we want them to be. And so we can just use the get and post throughout our entire application, but treat them as puts and deletes as we need to, to do different types of things we wanna do inside of our application. So it does make sure that your code works across more clients that may not always expose things like delete, put, et cetera. All right. Somebody said, what is this extra set of parentheses here? And so what do we know by looking at this syntax? What do we know that this is? What do we know that this require is gonna return? Require connect Mongo. What's it gonna return? Yeah, it's a function, more specifically a method, right? Is it actually a function? And so what is this right here? What is that parentheses

05:58:00
with the session inside of it actually doing? Calling it, like it's running it, right? And that means session is, it is our argument that's being passed in, right? So here's this session. We're passing it in as an argument. So we know that this connect Mongo is gonna return a function and we're passing that value in. And so it's just kind of like a way of like passing the correct data into the thing that you're using. Yeah. It's not technically executing right here, but that's kind of the idea. All right, we have the express flash, right? We have the express flash, which is gonna help us show us all of our notifications. So when they enter in the wrong password, or there's somebody that already has the same email, those little notifications,

05:59:00
we're gonna be using that flash to do it for us. Morgan is our logger. So you see all these lovely logs that I'm getting down here that's telling us the different methods that are being made, what the routes are, all of that is coming from Morgan. And then we are just kind of starting to set up our basic routes here. So first we're grabbing our database. So we're going to connect to our database. And then we have the basic routes. The routes for like our main routes, like the homepage, the login, the signup. We're going to have routes for individual posts. So like when you try to load a post page, your feed. We try to load your profile. And then we're going to have routes for our comments as well. Cool. Cool.

06:00:00
We could name these variables anything, yep, you can name them whatever the heck you want. Yep, you can name them whatever you want. All right. I could have called this Bob, that would have worked. You just got to make sure that if you're like running it or like running it down below that you have the same name. Morgan is our logger. It's how we're logging all the requests that we're making. I'm kind of in the way. Right, see how we're getting like our gets, our posts. Like we have like our gets, our posts, all that fun stuff. That's all the logger right here. That's all Morgan.

06:01:00
All righty. So let's look at the rest of our server setup. We have us requiring our ENV files. Remember, even though ENV files are such a crucial part of how our applications work when it comes to Node, they are not baked in by default. And so if you wanna use your ENV files, you need to require your lovely .env module, and then you need to tell it where to find your ENV file, or else you just won't be able to use your ENV files throughout your application. You can see that we are also requiring passport. And it's kind of that structure I was talking about where you are requiring the file and you can see that you're calling or executing that file that gets returned. So when we do require config passport, we know that this is

06:02:00
returning a function and we're calling that function and we're passing passport in as the argument. If we were to go and take a look at our config, and we were to look at our passport.js file, we would see that it does indeed export a function, right? It is exporting a function, and that's what that syntax is showing here. The syntax is showing, hey, you went and got a function? Great, run that function. Should this be memorized eventually? I don't think you need to have the code memorized, but what each bit is doing, definitely. Yeah, definitely each bit, what it's doing is what you need to know, but like coding this from scratch, probably not. No, you shouldn't. Is Morgan a dev dependency? Yes. You might,

06:03:00
so a dev dependency, meaning that like you would use the dependency see while you're in development, you might not have it running in production. So you might say, all right, I'm going to use Morgan while I'm building my application. But once I put that live, maybe I'm not going to include Morgan anymore because I don't need my server doing that. There are a lot of things that we might use during development that we might not use once we pushed our code to production. Is it okay if we have a lot of comments explaining what each piece does? I don't think you should delete your comments. I think I think specifically if it's like your 100 hours project, leaving your comments in is probably really helpful because it'll give you something to bounce off of during the interviews. Also, you're going to

06:04:00
forget, right? Hey, if you're interviewing for two, three months and you are like in the heat of it, it's nice to have the comments there because you won't forget the things that you were doing. Now the thing is, if you have comments that are silly or something that you wouldn't want an interviewer to see, then maybe you want to get rid of those. Get rid of like your cursing and stuff like that. Remember, if you're trying to play the game, right? Most interviews probably won't care, but there'll be the one or two that do. Cool. We're connecting to our database, right? That connect DB is gonna use that config file. So we're gonna go the config folder.

06:05:00
we're going to find the database file, config folder, database file. Here's how we're connecting to our database. And so, it's just a little bit of code here that helps us connect to our database using Mongoose. And that's it. Once again, not something that you would have memorized, something that you're just going to have in your template and you'll reuse. So, we went ahead and connected to our database. we are going to head and say, we're gonna use EJS for our view engine, meaning that our server now expects EJS files to be what we're using to spit out our views in terms of like the HTML that's ultimately sent to the client. And we're gonna use our public folder for any of our static assets, so our CSS, our JavaScript files, any like basic images or things that we would need for the base application to run. Goes in there.

06:06:00
And then for our body parsing, we use these two lines of code to be able to pull stuff out of the requests that are being made. So when you submit a form, you're sending a request. We'll be able to pull this stuff out of those forms. That's where the body parsing comes in. We're using Morgan. So we're actually telling it to do the logging. So if you don't have this line, even if you've required it, you're not actually using it yet. we're using the method override here, and we're telling it, hey, when you see any types of requests come in, if they have this query parameter of method, and I'll show you that query parameter in a bit, they have this query parameter at the end, let's override it. So we're looking for specific methods here. So if a post comes in and it has this query parameter, and it has delete after it, well, then we're doing a delete. If a request comes in and it has this query parameter, and it has put after it. Well, that's a put. We're not doing whatever the original request was. So this method override enables

06:07:00
us to override any of the requests that are coming to the server. Right now, our users are accessing our application through the browser. The browser only exposes natively the get and the post, like refreshing the page gives you a get, submitting a form gives you a post. the puts and the deletes that we have done, those requests have come from our JavaScript and they use things like fetch to make those requests, but fetch is not something that natively comes from the browser, fetch is a what? Yeah, fetch is a web API. So there could exist a scenario where you are trying to run your

06:08:00
code and the place where your client is trying to access your site doesn't have access to those web APIs. Like maybe they're trying to run your application on a refrigerator and the refrigerator is using some weird browser that doesn't have the FetchWebAPI, well, your site just wouldn't work. Your client's not gonna expose the puts and the deletes. And so this method override becomes client agnostic. It doesn't care. As long as your client can make a request, we can override any of the requests that come in and make them the request that we want, a get, a post, a put, or a delete. Mm-hmm. All right, we got our session, this

06:09:00
is just the stuff that we need for the session to be implemented. And then we have our Passport middleware, just saying, hey, we're using Passport, which is gonna help with our authentication, letting Passport know that we're going to have a session where the user stays logged in. So if you want to use Passport, you need these two lines. We're letting Flash get set up. So whenever we have those error messages, we get the Flash that shows up in the DOM. And then we have our main routes. So we're saying, hey, when these requests come in, if it's just a root, if the request comes in on the root route, we're going to use this main routes file, right? So if we look at main routes, this main routes is a in the routes folder, the main file in the routes folder is gonna list all of our main routes. If the request that comes in is like localhost 2121 slash post, but we're gonna use this router, which is the post routers. And if the request comes in and it's slash

06:10:00
comment, where we're gonna use the comment routes. So JavaScript talks separately to the server. So that whole kind of idea of web APIs comes from our class where we talked about what it actually means to be running JavaScript. JavaScript is single threaded. It can't block. It can't do these things that take time. making a request to a server, like a put or a delete request to the server, it takes time. JavaScript can't wait. It should not work, right? And what we found is that the reason why we're able to do these things, we're able to do

06:11:00
stuff and keep moving and keep clicking and keep scrolling, is because all that heavy lifting is not actually JavaScript. JavaScript is handing off those requests to the web APIs that come with the browsers where we're executing our code. Now, we could be executing our code in an environment that doesn't expose those APIs, that doesn't give us fetch, right? And so, if we were in one of those environments, and this is really a thought experiment, pretty much all your users will be environments where they have this stuff, right? But the idea still goes that we were using fetch, which does not natively come with JavaScript, which only works because the browser we were executing our JavaScript in actually had access to it. When you use the method override, that doesn't matter anymore. If they natively have any way of making a request, a get or a post, we can override them as they come in. Is there

06:12:00
any reason why delete and put do not have of a built-in way of using them. It's part of the specification, right? When the specifications were built for HTML, post was included. I do believe they tried adding post and delete and then like they removed it from the spec or something like that. But yeah, it's part of the folks that have decided how the web is built. Remember, these things are built by real people. There are committees that like approve these decisions and we live with those decisions. How do we know when we have to use something more complicated, like this syntax versus like a different bit of syntax, the docs tell you? Yeah. So this is something that you would read the docs on like NPM or something like that, and it would show you how to like actually run it. So a lot of times when you're using a new module, like if you want to use the NPM package for Flash, and

06:13:00
you didn't know how it actually worked, well, you would go to that npm packages page and it would give you all the instructions on how to use it. With PyScript, what happens to JavaScript moving forward? People keep using JavaScript because no one's going to use it. People have been trying to replace JavaScript for, since JavaScript was created, it's just too big of a beast now. Can you explain lines 40 through 48 again? So these lines right here is not something that you actually need to know. this is just setting up our session so that our users can stay logged in and specifically telling it to

06:14:00
store that session in our database meaning that when someone comes to somebody logs in they stay logged in and they can even close the browser window and come back to the Application and they're still logged in. This is all the code specifically that helps us do that Can you remind us how to find our ENV file? I put my ENV file in the config folder. I believe if you clone down, let's see, let's hit ignore. So if you clone down my code, that ENV file won't be there because I don't want you to have my credentials,

06:15:00
right? So that ENV file won't be there. That's why the readme walks you through how to create your ENV file. So you're gonna put it in the config folder and then you're gonna have these following values, the port, the string to your database, your Cloudinary name, your keys and all that fun stuff. So I recommend anything extra for session management and single page applications. I think once you run into an issue, then you kind of research what you might need for those additional issues. I'm still using off the shelf stuff for everything, so it's not something I'm going to hard code myself. I'm going to use a specific strategy to solve any of the errors that might pop up. What does body parser do again? Body parser enables us to pull stuff out of the request. So think

06:16:00
about when you send a POST request, like when you submit a form, all the data in that form is being sent to the server. Well, how do we get that information out of the form? The body parsing, which is what enables us to do that. There used to be a package called BodyParser that was used for years and years and years until Express incorporated their own way of doing body parsing. We don't need that package anymore. How do you handle password resetting? You would need to use a different strategy to get that working. So I showed earlier that you could use like the hackathon starter to see how they implemented it using Passport. That's where I would start if you wanted that. Do Cloudinary keys change or I need to put once for every project? Yeah, I'd recommend separating your different Cloudinary instances for each project. That way you're not storing

06:17:00
different types of media that don't go with each project. Yeah. That's just a personal preference though. How much of the known modules will be required to know for an interview and on the job? Nothing, none of this has to be memorized. Like having a good understanding of like what you would use, how you would use it, but like as terms of like what you're like, the day to day is you Google, right? Like over time I start to know, like I know what I'm gonna need, I know that I'm gonna need, Like I know that if I want to log something, I'm probably going to use Morgan. If I want to use a session storage, I'm going to use Mongo store. Like I want to use, like, I know the, like I know to use these things, right? Because I've done it enough and I've put it into my Anki enough to know that these are the things that I want to use. But I spent a big part of like before, like we walk through like the,

06:18:00
the setting up of this project. This is like a big deal. Like if I'm starting a project from scratch, I'll spend over a week Just whiteboarding it Researching the different packages. I'm going to use Researching the best technology to do what I need to do um Before my fingers even hit the keyboard once you're on the job and like it's a little bit more Established like how you do things um and you're kind of like fixing stuff or like adding stuff to like a framework that's already there, that's a little different because you're just gonna like follow their guidelines, their style guidelines, their, the tools that they're already using. And so that takes some of the planning off of your brain. But if I'm starting from nothing, I spent a certain amount of time on this, on this, on this like actual process,

06:19:00
really important. When you say production, is that when the app is live? Exactly. Quad, I believe Adam is coming to end of life, so I don't think they'll be supported going forward. At least that's what I recently heard, so I would definitely switch to something else. Yes, yes code is owned by the same company. Cool, all right. So we walked through the beginnings of our server.js file.

06:20:00
Um, what I want to be able to do now is like think through from beginning to end. Uh, maybe the feed page, I think the feed page is, is, um, the easiest for us to, to render out, um, because we can, we're not really doing anything fancy there. So let's go to our application. Uh, let's log in, uh, Ron at Ron.com. And let's go to our feed. All right, so here in our feed, we can kind of see all of the images that have been uploaded. And so look at the route here. Localhost 2121 slash feed. That's pretty straightforward. Actually, let's do an individual post. So let's look at, here we go, loosen. And when we look at this individual post, We got

06:21:00
a lot of little things that are happening here. We're on localhost 2121, we're on a post route, and we have this string of letters and numbers here in the URL. What the heck is that string of letters and numbers that's in the URL? Yeah, it's the ID, right? It's the ID. And so we know that when we hit refresh, or we hit enter on this URL, we have made a request to our server, right? Just by hitting enter here, I have made a request to my server. That server is going to have to go through a couple different steps to ultimately figure out how to respond, right? And so if I want to load this page, let's walk through what those steps would

06:22:00
look like. Very high level, let's draw it out. So from the client side, we're gonna make a request to our server. That request is going to be a get request. And when we hear that get request, we're gonna have to do a couple of things. we're going to have to, one, get the ID from the URL. Once we have the ID from the URL, we need to go to our MongoDB to find that specific post. Once we find all the information for that specific post, we need to pump all that data into EJS. That EJS needs to spit out some HTML. And once we have that HTML, then we need to respond. And so if we are going to be doing this throughout our application, we built up over time. In

06:23:00
the beginning, we just used raw modules, FS, HTTP. Then we added express into the mix. And at first our express was just one giant server JS file. And that works so does using the raw modules that works right and so we could build our application that way but It begets to become pretty hard to maintain When we're working with other engineers, they don't know where to go to make changes and heck when you come back to your MVP In a year, right? Let's say you go to work somewhere you work in there for a year or two and then you're ready to start interviewing again you're gonna come back to your 100 hours project, make it look better, incorporate the things that you've learned over those one to two years before you move to your next company, and you're gonna forget everything. And so having a better architecture, like an MVC architecture, makes it easier even for yourself to come back and look at your past projects. So we have moved from kind

06:24:00
of that massive server.js file to more of an MVC architecture, which means that we're gonna have our models, our views and our controller split up. And the way that we have it right now is that our server.js hears that request come in. It hands that request off the appropriate router. The router knows the appropriate controller to talk to. And then that controller does what it needs to do. Maybe sometimes it's going to talk to the model so it can talk to our database. Sometimes it's going to pass stuff straight to our views using EJS. But the end goal of generating that HTML and responding with it. Does it make it slower? Technically, like if you have to jump from one place to another, it does. But we're talking like speed of light on the same server, you won't notice. But at like a technical level, yes. Possibly. So coding gets you models? Yes,

06:25:00
absolutely. I'm going to say definitely ask your question on discord. I don't, I don't know how you generated that error, but yeah, cool. All right. So let's take a look at this and then we'll take our top of the hour break. So I'm gonna go quickly through this one this one pathway. We'll come back. We'll spend way more time digesting it So let's go ahead. We we hit enter boom hit enter and let's follow that so that request was locals 2121 slash post and then the actual ID of 631 and the end is 874. So if we look at our server.js file and we look at our routes was that a a main route, a post route, or a comment route? Let me show you the URL one more time.

06:26:00
Localhost 2121 slash post, and then the ID was that main post or comment? Yeah, it was definitely a post route. We could literally see slash post in the URL, right? We saw slash post in the URL. So that means we're gonna be using our post routes, right? Using our post route. So if we go ahead and we look post routes means that we have to require our routes folder and we're going to find that post File in there the requires just saying hey go to this folder find this file So we're gonna go to our routes folder boom find the post file. Here we go And we look at this post file. You can see that we're using a lot of different stuff here Once again, we're using Express and specifically Express router, which is gonna help us to handle our routing We are asking for multi, which will eventually help us upload our images. We're saying this is where we can go and find our post controller.

06:27:00
And we're bringing in our middleware that helps us make sure whether or not somebody is logged in or not. So all these bits will go through deeper as we need to. But right now we're really focused on, all right, we know that we are on a post route And was there anything else in the URL after that post route? Like, is there any other part of this path that we need or is it just the ID? I think some folks get tripped up on this a little bit. As we look, we go to our server.js. We know that we are on the post route. So we don't need to say post again. We don't need to say posting. When we look at the post routes, we don't need to say post again. and it's assumed that you're saying post there. And so if we look at the URL, there's nothing else after that post except for the ID, right? And so if we look, we have the different types of requests

06:28:00
that we could have made when we hit enter, right? When we hit enter and we made this request to the server by hitting enter, what type of request was that again? It was a get request. All right. So we know that we're already on the post route. We know it's a get request. So the only get request that we have here is this one. This is a post, this is a put, this is a delete. All right, so this is the get request. It looks like the right route because there's nothing else after slash post. And what we know we're going to need to do is grab the ID out of that URL. when we look at this URL, I'm just going to paste it in here just so it's a little bit easier to see. When we look at this URL, we need a means of grabbing this string right here. Right? We need the ability to grab that string right there because that string is

06:29:00
the actual ID of the post. Remember, we go back and we look at our whiteboard, we know that each post, Each post is going to have its own randomly generated ID. You know, each post is going to have that ID. And so what we need to do is be able to yoink that ID out of the URL so we can go and find that post in our database. And so here we have this parameter. When you put the colon and then a name after it, this gives you a variable that you can use inside of your controller that'll grab this value. It's as though we're passing this string of letters and numbers into this variable, and then we can use that variable inside of our controller. All right. So we found the right route. We know it's the right method because it was just a loading of the page as a general get request. We know that

06:30:00
we're on the right route and we have a parameter, or just a variable that's holding that string of letters and numbers that is the ID of our posts. What is InsureAuth doing for us? Making sure that we're logged in. We don't want folks that aren't logged in to be able to see posts, right? You could remove this and then anyone doesn't have to be logged in could see it. So I am just making sure that they are logged in. All right, and then what I want them to do is if they've found themselves at this route, they're logged in, let's go ahead and execute this controller and specifically this method on that controller. Now, where does it know to go to find the controller? Well, I've already required it up here. I said, Hey, go to the controllers

06:31:00
folder, find the post controller. And so post controller is our post controller. It's going to have a bunch of methods and we're going to use the get post method. So let's go to our controllers folder, our post controller, and we should have a get post method, get profile and no get feed. No get post exactly what I'm looking for. Boom. That lovely group, that lovely get posts. And we're gonna do some stuff here. We're gonna do some stuff here, right? The first thing we're gonna do is we are gonna use post find by ID. What the heck is post find by ID? What am I doing there? Post, what is post? Post find by ID. It's checking the database, exactly. if we look up top, post is requiring our model.

06:32:00
So the model is how we're gonna talk to the database. Mongoose is gonna enable us to use this model to talk to our database. Wherever we see post, it's our post model that we required up top. All right, so we're gonna go to our post collection. We're gonna find in that collection something that has the ID of rec.params.id. What the heck is rec.params.id? Rec.params.id. Yeah, we're yoinking the ID out of the URL. Remember, when we looked at this route file, we looked at this route file, we said, hey, this is gonna be the variable that's holding that ID that was in the URL, that big string of letters and numbers, it's being held by ID. So when I do rec, which is the request, params,

06:33:00
which is the parameters that might be a part of that request, and I look for the ID variable or parameter, whatever you want to call it, I'm going to be able to grab that string of letters and numbers. So it's as though I have grabbed this string right here. Boom, grabbed it. it's as though I've grabbed that string and I've placed it right there. Right? As though I had grabbed that string out of the URL and placed it right there. Oh, sorry, that's get posts, my bad. That's it, all right. And I placed it right, sorry, right there and also right here. Boom. All right, so we were almost done with the original getting of a generic post. So we went to this page. We

06:34:00
saw that that request was a get request sent to the server. Our server heard that request, used the post routes file. There was a specific route for the get request. And luckily that get request route but also included a query parameter. So we'll be able to use this query parameter, this parameter, sorry, inside of our controller to grab that string of letters and numbers so we can go and find that specific post. So when we look inside of our post controller, we found the getPost method that we said to use in the routes, right, that getPost method. And that getPost method will have the ability to say, all right, using that post model, using the Mongoose ability to go to that collection, find a specific document that has the ID that came from the URL. And so what we're gonna be able to do

06:35:00
is go and look in our MongoDB instance for, right, inside that post collection, something that has that ID. So if we look, this has the ID of 2874. If we look in our MongoDB and we look at our posts, we should be able to find something that says 2874. A lot of posts, there we go. All right, 2874. So we're able to use that ID to find this specific post and we're to grab all this information from the MongoDB and we're able to store that in this variable called post. So we were able to go to our post collection, find the document that had the ID that was in the URL, and we stored that in post. We're also loading comments. And so on this line, we went to our comments collection and found the

06:36:00
information we needed for the comments, but we'll hold off on this for right now because it's a little too far. So we were able to go and find all the information for that post, we were able to store that in the variable post, and then down here, we're rendering our post EJS. We want that HTML to come from that EJS template. And we pass in all the information we got from the post with the name of post into that EJS template. So if we look inside of our EJS, we should see the variable of post. And wherever we see that variable of post, we know that it is the information that came back from the database for that specific post. So let's take a look at that post ejs. We go to our views. Go to our views. Go to our post ejs. And here's our lovely post ejs. There's a lot of stuff going on here, but if we look,

06:37:00
we can see that we are able to pull out from this EJS, all right, here's the post title. As we grab that singular post, we can grab the title property off of it. We can grab the image property off of it. We can grab the ID property off of it to populate our EJS. If we look here, we have the title property of their name. We have the image property of the URL that's stored in Cloudinary. We have all this stuff that we're able to now use because we went to this collection, we found this post, and we passed all of that into our EJS. So now, as we're building out our EJS, we can have an H2 that has the title that came from that document. We can have an image that has the URL that came from that document. And we can start to build out the other things too that we'll use later on, like the ability to have the like button, the ability to

06:38:00
have the trash can as well. That'll be some down here. Here we go, the trash can down there. And we'll also be able to put in the number of likes. So we're able to grab all that stuff from that collection, pipe it into our EJS to build out the page that we see here. Can you describe controllers? So

06:39:00
if you've been following along, we've been using an MVC architecture, Models, Views, Controllers. The controllers are kind of like the person in the middle. they know the request that came in and can go and talk to our database via the model. They can go and help generate the HTML via the views. And they're kind of the orchestrator in between that knows how to go get the data if it needs it, knows how to pass that data to the EGS if it needs it. And then once it gets the response, knows how to get it back to the client. Why isn't post capitalized in the EJS? Because for that, for it to be capitalized, we would have to have capitalized it here. You could do that, and now you're gonna be looking for capital P, but we gave it this name here of post. If we change this to unicorn, then anywhere we saw a post in there, we'd have to change

06:40:00
to unicorn. But since it's a post, it just makes sense to call it post. What's the routes role in MVC? The routes is just the server understanding what request was made and getting it to the right controller. You build something out like this, what parts usually start with the views or the routes? I actually start off with my model first and then my view. I find if I have my model clearly laid out and I have my view laid out, then I'm pretty good. Can you give us examples of projects people have made? I'm going to be tweeting this week, uh, everyone that gave me permission to share their, um, their hundred hours project.

06:41:00
I'm just like a big like thread with them in there. I think that'll be cool. And uh, yeah, I'd be able to see, but there's hundreds and hundreds of projects have been built off of this template that do all really different, cool stuff. Yeah, definitely if you ever want to just give the a hundred devs tag a peruse on Twitter, you'll see some really cool stuff. Is there a way to encode the information sent throughout? Not sure what you mean by that. How does the post ID get into the URL in the first place? So what we're actually realizing is that when we build out like our profile or our feed, so if we go back to the profile or the feed, as we're placing posts into the feed, if we use the inspector,

06:42:00
we can see that these are actually links. And we can see that these are actually links. And if we look at the link, the link has the post ID already in the link. And so when we build out the feed or the profile page, as we're building out the individual things that we're gonna click on, the ID is already there. And once again, to build out the feed, we need to go to the post collection, find all the posts and then build out LIs that have anchor tags inside them with each individual post ID.

06:43:00
Why does MongoDB have capabilities like Cloudinary to store the images of the images of the images because it's two different types of data that you're storing. Like MongoDB is meant to be a database. You could technically encode images into a database if you wanted to, it's not technically, like you shouldn't, it's not very efficient, but one is like raw text data and the other is media. And you wanna have those separate because media has to be stored on an actual drive, right? Like that image isn't magic, it has to be stored somewhere, right? Think about like an image on your computer, it's stored on your desktop, but that's actually on your hard drive or your SSD. So what Cloudinary is doing is storing that media on a server for us, so we can grab those files off of our hard drive. And then they actually do a lot of other stuff for us too, like putting it behind CDNs and all that other fun stuff to make it easier to get those images back and forth. But a database is not really designed to hold that type of information. Could it technically? Yes.

06:44:00
Should we break the connection to the original repo so it doesn't look like a fork of bub? Oh yeah, absolutely. You should definitely have your own repo for your project. Cool, all right. I just think that it just depends on what you wanna do. Yeah, it depends on what you wanna do.

06:45:00
So let's finish up looking at this post by also just looking at the model at the end. So we kind of skipped this part where we're saying, all right, we're going to use this model of posts. So let's go to our models. Let's look at our posts. And what we're going to see here is that we are using Mongoose. So Mongoose is what we're going to be using to help us communicate with our MongoDB. Mongoose is helping us connect to our database. And it's also helping us use these schemas so we know what type of data is going in and out of our database. Why do we use schemas? What is that bringing to the table for us? Because we didn't use them at first. Or are we using MongoDB without any schemas at all? Yeah,

06:46:00
so the database isn't a mess, so that we have some structure, so that we have a format or a template for the data that's going into our database exactly. That's that maintainability, right? It adds to that ability for us to know what the heck is going on in our database. Now, if you have a good model with a good schema, do you actually even need access to the database to know what's going on? Now, I can look at this schema and know what's happening. Oh, MidMule said also for Google, schemas is a term that's used in a lot of different places when it comes to kind of programming. There are schemas that refer to SEO. This is something different, yeah. Cool. So yeah, we wouldn't need access to the database. We know that any

06:47:00
post, right? Any post is going to have a title that's a string. It's going to have an image property that's a string. It's going to have a Cloudinary ID, which is a string. It's going to have a caption, which is a string. It's going to have a likes, which is going to be a number. It's going to have a user and we're going to be able to actually grab the object idea of a user. It's going to have a time that it was created and we're just going to use that that current date as the created at. So we're able, right, we're able to just by looking at the model, know what's going into our database. So if you didn't even have access to my MongoDB instance, you could still be a developer, working on this model, working on this information and be able to get your job done.

06:48:00
Yeah, once we start using schemas, we make it required that you use it. If you try to create a post document right now without using the model, you're gonna get an error. It's gonna like it's gonna say like you can't do it It's gonna stop you from doing it because what that does it makes sure that my collection is clean, right? Every single document my collection will follow this schema. So there's no extra data on some documents That's not there on other documents everything that's on this schema Will be represented in that collection with that document All righty, so let's step through this and

06:49:00
kind of talk through one more time, beginning to end. Now we've seen all the bits together, I'll step through very briefly and then we'll move on. All right, so we're going to click on this various photo and when I click on it, we can see in the inspector that it already has an anchor tag that has a specific route. We can see that it's a post route with this actual string in it and this string is the ID of this post. So when I click, it's gonna take me to that URL slash post and it already has the ID and the URL. And this is a get request. This is a get request. That get request makes it to my server. And if we look at the server.js, right? That get request makes it to my server. The server.js has said, all right, you made a request on slash post, use the post routes. Post routes is saying

06:50:00
go to the routes folder, find the post file. So we go to the post routes, we find the post file. Inside of it, we said, all right, well, what type of request was it? Was it a get, a post, a put, or a delete? As I was just trying to load this page, it was a get request. So we looked, do we have a get request? Yes, we do, beautiful. We can see that we're gonna be able to grab anything that comes in that URL after slash post, and it's gonna have the value of ID. So we're gonna have like this variable that's holding that string, that 631 all the way to 2874. We're gonna check to make sure that we're logged in. Since we're logged in, we'll continue. We're gonna find our post controller and use the get post method. So here is the post controller. This is where we're gonna find it. We're gonna go to our controllers folder. We're gonna find the post file. And when we get there, we're gonna run the get post method. So we go to our controllers. We go to our post controller. We have all these different methods that are here on the controller, but we're looking for

06:51:00
that get posts method. We're going to use post, which is our model. If we look up top, require the models and posts. So if we want to look at it, we can go to models, posts. We can see that Mongoose is helping us with this model. We also down here, we saw in maybe two or three classes ago that when we do this Mongoose model here, what is it going to do with posts? What is it gonna do here? What's it gonna do if post? Yeah, it's gonna make it a plural by default. It's just what Mongoose does by default. We saw something cool in the class where we went over this with like ox being turned into oxen because it knows how to make a plural of ox, which is wild. So if we actually look in our database, we're gonna actually see that it's post. That's where the name is coming from, it's post. And what

06:52:00
we're doing when we are using this model is we're saying, all right, go to that post collection and find a document in that collection. Oops, sorry. Go to that post collection, find a document in that collection that has the ID. And what ID do we want? We want the ID that came from the URL. Remember, we looked at the routes. It has this ID query parameter here. We're able to use that parameter. Whenever we see ideas, the parameter was in the URL. If we look at the URL, we look at the URL, it's there. That 2874. So we're able to go into our post collection, find a document that has that specific ID and store it in the variable post, right? We also actually do some other stuff here too cause that post page needs more. We use our comment model, right? We use our comment model. If we look at our comment model here, models,

06:53:00
comment, we can see that it's gonna be comments will be the name of the collection. So we're going into that comments collection. We are finding something that has a post property of the ID we just pulled from the URL. Remember each comment is tied to a particular post. So if we want all the comments that are tied to the posts that we're on, we're gonna use that same query parameter to get all the comments tied to that particular post. We're sorting them in descending order and we're using that lean. Do you remember what the lean does? And get you, you know, you know what I mean? Gets you a little, eh. Yeah, it gives you the POJO, right? the plain old JavaScript object. Documents aren't one-to-one objects that we're used to using, right?

06:54:00
Right? It's not a one-to-one of an object. There's a bunch of other stuff that it comes with that's like five times the size of a normal object. So that lean kind of just gets rid of all this stuff that we don't need and just gives us it's the raw object that we care about, which can make this faster, right? So we found all the comments tied to the particular post that we're on by using that same ID that came from the URL. And then it's time to hand off all that stuff to our EJS. We're handing off the posts and we're giving it the name of posts. We're handing off the comments and we're giving it the name of comments. And then we're also handing off rec.user user with the name of user. What the heck is rec.user? What is that giving us?

06:55:00
What is rec.user? Yeah, it's the user that is currently logged in, exactly. we know that since, since we know that we had to be logged in for us to make it to this page, right? We never would have ran this get post method if we weren't logged in. So we already know that we're logged in. And whenever a request is made with a logged in user, part of that request, remember I showed that request object, it was massive, so much stuff in that request object. Part of the stuff that's in that request object is info in the logged in user. and we could yoink it from that request and grab that information from the logged in user and pass that to the EJS. So going into this EJS template is everything about the post. It's everything about the logged in user. It's everything about all the comments tied to that post and it goes into this EJS and

06:56:00
this EJS is the template that we've built that takes in the title, it takes in the image, it takes in and builds out all the things we need like our likes and our deletes, and a place to put all the comments, right? We have like a loop where we loop through and we put all these LIs that are each comment into the UL. So that way we can see Fosho and Baddy as the comments that were on this post. And so that's the lovely world of EJS, it's in the game. And then finally, once we're all done, we've rendered that EJS, we spit out the HTML, we respond with it. That's what the res is for, we respond. Is the user passed through the request? Yes. Since we are logged in, we have an active session. Every request that is sent to the server has information on the logged in user.

06:57:00
Is rec.user also coming from the URL? No, it's part of the request that's being sent to this server. Remember, when you do any type of request, whether it's a get, a post, a put, or delete, you're sending a metric crap ton of information to the server with that request. How can we log the request body? you can just console log request, or right now our request is in the variable REQ. So you can just console log REQ and you'll console log every single thing about the request. Thank you, Moon. Those unsafe files make me twitch. It's because I'm doing a lot of like examples. So anything I'm typing really isn't, shouldn't be part of the code base. It's just like me

06:58:00
typing the URL into spots and stuff like that. So I don't save. Can you explain Mongo schema types object ID, please? I tried to read the docs and I got lost in the sauce. Absolutely. So if we look in the post model, there is some weirdness right here. we know that each post, right? Each post is gonna store the user that made the post. Like if we go back and look at our original whiteboard, each post is gonna have like this poster ID that we care about, like who made the post. Well, that has to be modeled in our schema somehow, right? And so here we have a user, we could call this whatever we want, but since it's the user that made the post, we'll just call it user. and what you're noticing is that we get to put each different type, like what type of data we're storing. So title is just a string, number of likes is obviously a number. Well, what is a

06:59:00
user? Like how are we keeping track of the users? Well, we're keeping track of the users based off of their ID. So Mongoose just enables us to say, hey, we're keeping track of the user based off of its ID. so we don't have to do anything fancy like turn it into a string and then parse the string to get the ID. We can just tell Mongoose, hey, we're gonna store that ID because when we look at the IDs, right? When we look at these IDs, they're not, it's just not this number, right? It's not just this number. It's like this object ID. It's something more than just a string for the ID. And so Mongoose knows how to deal with that when you give it this information. Like, hey, it's gonna be this thing that's the object ID, which is not technically just a string. It's an object that incorporates other stuff. So instead of having us to like encode, decode, and figure it out, just treat it as an object

07:00:00
ID. And the ref is just kind of letting us know where the data is being modeled from. So it can like know the use that user model, which is how we're creating our users. Dejesus, hey, what up, Nick? Yeah, it's a primitive of MongoDB, so if you've read the docs, you know that it kind of comes with it. Yep, and then you can take this a step further if you've read more about like populate and stuff like that. Mongoose does so much. It can do so much for you, right? Mongoose can do so many things. We've just skimmed the surface of what it can do. And so as you build out your hundred hours project, I'm sure you stumble into more and more that it can do for you. What'd I bring?

07:01:00
Rascal says, yep, Mongoose has superpowers. It really does, yeah. The Mongoose documentation is overwhelming. You know, I used to feel the same way, and then I kind of just realized it's just big words, Like for me, when I was first reading this back in the day, when I was first reading the Mongoose documentation, I just didn't get it because the big words I didn't understand. But once I took time to like, just like Google, like, well, here's how it used to happen. I would Google what the word meant and it would take me back to the documentation where I was currently stuck. Right. And so that's how it used to be. Right. Like I would Google like, what the heck is this? And then it would take me back to the docs where I was currently stuck. Uh, which is one of my problems with documentation.

07:02:00
I wish people would just like break everything down as though you'd never heard of what that topic was. Um, but once it matured a little bit and I was able to like, look up things like individual words. I find the documentation like oddly comforting. I feel like it does tell, I feel like I was being blinded by the big words, but now I think it's been filled out enough where they do actually do a good job of breaking down the words with an example. And so whenever you're using something really like heavy that you haven't been encountered before, you have to run the examples and you have to spend time dissecting the examples. So I don't really get a lot of value, honestly, out of the text and the big words, but I get more out of looking at the code and trying to figure out what the code is doing. I don't know if I'm explaining this as well, but I think it's just for me over time, you get better at reading documentation. And I actually think the Mongoose documentation does a good example of showing, but maybe not telling as well. Yeah,

07:03:00
and that's why I assigned so much reading, right? The reason why I assigned so much reading for homework is you get more comfortable with it the more you do it. Like the reason why I didn't start you off with like the video or the tutorial for react and I had you read the docs versus one, the react docs are pretty damn good, but that habit of reading first and that being your primary way of understanding is going to be a skill set that you absolutely need on the job, right? Like you absolutely need that skill set on the job. And so I really, really encourage you to spend time reading through documentation. Even if it's painful at first reading the mongoose docs and trying to walk away from it understanding what the heck's going on is a really good exercise reading the react docs first before watching a video or a tutorial is a really good

07:04:00
exercise I can't stress how in a few months you're gonna well for a lot of folks very soon you're gonna be on a team by yourself, there won't be a lot of tutorials for the weird tech thing that they're using. You're gonna have docs and you have to play with it and try and understand it. And it doesn't mean you don't get help. I spent a metric crap time on communities where I get help. Our Discord is amazing for that, right? But that act of reading, I can't stress it enough how important it is. Yeah. Cool. All right. We also have like a, we also said like,

07:05:00
it's cool that you can have like a type that's like date, right? And you notice like this default, you can put defaults on any of your kind of your, your properties here, like title image, you can have a default. So like if something's not passed in, so what do you know about our post? When I create a post, what do you think's happening in terms of created at? Am I passing that information along with the form that I'm submitting for creating that post? Nah. So when I actually create a post, I'm not submitting the timestamp myself. It's the default is running. So it's like, all right, it didn't have that. The default will be date now, boom. And so when I create a post, I actually don't pass a created at property. I'm just using the default.

07:06:00
And what does that look like? Yeah, and that uses like the normal date. Cool. All right, so we walked through the ability to render a specific post, right? We rendered a specific post. I would like to render out the profile and then look at submitting a post. So let's render out the profile, let's look at submitting a post, and then we'll look at kind of updating likes, we'll look at deleting, and then we'll kind of regroup and see where we need to go from there. Well, questions before we look at the profile

07:07:00
page? Hold on. Rascal. Why can't I just VIP from here? Hold on. Let me try it on this side. One second, I just want to see if I can. Oh, you already have VIP. Why is it limiting you when you have VIP? I'll figure that out after stream. You should be able to post links. Thank you for all the help that you provide in

07:08:00
chat. I really appreciate it. Cool. Alrighty. So let's take a look at the profile. We put this on our resume. We're putting our $100 project under our consulting company name. It's up to you. I think it probably stays underneath if like your 100 dev section, your consulting is probably the consulting that you did. But we'll look at that throughout this month. Cool. When will you say that models are files that create data we need to the server? We use the information in our views. Yeah, I think you're on the right vein there. The models are the structure of the data that we'll be storing in our MongoDB database. And eventually we take that data and pass it to our views to render the pages that we see.

07:09:00
I use the package moment.js. That's a very, very common package folks use. The MVP ends up showing you Leon as a contributor since it's built off the bub template. We do something about that? Yes. Clone it down and don't make it a fork. Like don't fork it. Before we end, can we do a speed run on doing the models and views from scratch? I think that might wind up being a different day Because we're about to hit four hours right now, and we're still not even done working through the entire code base So we'll see how far we can get but that is my goal I do want everyone to be feel comfortable with the code base and then I want to be able to like Speed run it. Yeah, like adding stuff

07:10:00
All right, looks like we got through most of this stuff. Let's take a look at the profile. All right, so here's our profile page for Ron. So far we've just loaded the profile page. And so let's talk through how we loaded this profile page. All right, so we're at localhost 2121 slash profile. So if we take a look, was it a post route, a comment route, or a main route that we just went to?

07:11:00
I don't know if it had a confirmation on that one, because don't worry about it. We're going to resubmit everything on Tuesday anyway. Yep. Main routes. Let's go ahead and take a look at our routes folder, routes, main JS. And we can see that there was a get request for profile, which is great. We noticed that it's using insure auth. So we know that we're checking to see if they're logged in. Remember our profile is a little interesting right now. It's only the profile of the logged in user. So we're checking that profile. We're making sure that they're logged in. If they are logged in, what we're gonna do is go ahead and use this controller and specifically with the get profile method. So we loaded the profile route. It

07:12:00
was a get request. We checked to see they're logged in. we're gonna use the post controller in the get profile method. So is our post controller linked to correctly? Yes, we're gonna require to go to controllers, find the post controller, and we're gonna use the get profile method. So post controller, let's find the get profile method. Boom, here is the get profile method. What we're gonna do is we're gonna go using our post model to find all the posts from that specific user. So right now, does Ron have any posts? No, Ron doesn't have any posts. We don't see anything over here. And so this line of code still runs. It's trying to find a post that has the ID of Ron. Ron is a user. Since Ron is logged in, every single time Ron makes a request,

07:13:00
part of that request body is a user property that has Ron's ID. Like if we console log this, we can. Let's console log rec.user. We'll save that. And if I refresh, What we should now see is in my console, you can see that rec.user that was console logged, right? And so we can see that we got Ron's ID. We were able to grab their username, their email and their hashed password. All that came, right? All that came with just making a simple get request. You gotta think about this. Every single request you make, all this information is being sent.

07:14:00
And the cool thing is we can yoink it. So we know that we're on the profile page. We already know that somebody's logged in. What we're gonna do is we're gonna yoink their ID from the request, right? So we grab the 633-1BD6 from the request that was sent to the server. and we're gonna look in our post collection for an document that has the user property of Ron. So we can go, we can like look in our post collection and we're looking through all the posts and we're looking for a user that has Ron's ID and we're not gonna find it because Ron hasn't made a post yet. So nothing happens in terms of rendering out the profile in terms of the post, it sends in a nothing burger and the EJS just doesn't build out anything for the posts. But if we were to make a post, it would show up

07:15:00
here. Cool. You can see that we pass along any of the posts that would have gotten from the database, which is zero. And it also passed along all of Ron's information into that profile.ejs. If we look at this profile EJS, what we'll see is that there's a lot of goodies in here. There's not only the putting of the form for like adding a post, right? Like we can submit posts on this page, but we can also see all the posts that were already submitted by that user. We have like a loop for submitting, for showing all the posts. Right now, Ron doesn't have any posts, so this loop doesn't do anything. Yeah, so we have the ability to show the post, we have the ability to upload a post with that form, and we're also showing Ron's basic information, the username and the email that we got back as well. So if we look at this post route,

07:16:00
sorry, post controller, you can see that we passed not only the information about the post that they made, but also all of their user information to that EJS that when we look at the profile, we can see Ron and Ron's email. All right, so let's go ahead and create a post. Let's go ahead and get this post. Let's go ahead and say, let me see real quick what images I have on my desktop. Let's see. I still have like a lot of screenshots of people getting jobs. That's pretty much like a full, like all of them is just screenshots of people getting jobs. So we're just gonna call it random job. look at this job. Let's choose a file. Desktop. There we go. Boom.

07:17:00
All right. So now we have a new post that's a random job. Oh no, totally drowning in all these job posts. What will we do? I don't know. All right. So now we have a new post. And so a lot of stuff had to happen for this post to show up. So let's take some time to step through step by step how we went from filling this form to this post showing up. And since we're already in the post EJS, let's start with that post EJS. So, sorry, the profile EJS, boom, boom, boom, profile EJS. All right, since we were already on the profile, right? This is already on the profile. What we'll notice is in this profile, like we had places to put the username, to put their email. We also had this lovely form here. And this form is

07:18:00
doing the heavy lifting. One of the things to note is that we're using Moulter to help us upload the files, the different types of files that we're uploading, in this case, image files. Like the code that's helping like take that file and eventually get it up to the server is something called Moulter. And we have to have this ink type multi-part form data for it to work. So a lot of times folks get pretty frustrated. Like they have everything working, like everything looks like it should work, but for some reason the files just aren't uploading. It's almost always you forget the ink type. So you need it. You can see that we are sending a post just like we would send with this form before we had method override where it could do a lot of other stuff. So in this case, we are submitting this form. It'll be a post request and this will be the route. It'll be slash post, create post. So when we submit this form, we know that it's gonna be a post route and we're gonna be

07:19:00
using this as the secondary piece in that route. So we're gonna look for a post request on this route. And if we look in the form, we have our input for the title, we have our text area for the caption, and we have the input for the file upload. And so we need this input type file, and we have a lovely submit button so that we can submit the form, and we'll be able to upload our actual file. Cool. How do we update the multi-file if we want to upload short videos? You would just take off the check that's looking for images, which I'll show you in a second. All right, so. We have our lovely form. It looks good. We know that this is the action of the routes. Let's follow that route. We'll start all the way to the server.js again.

07:20:00
Is the submitting of the form a post route? Yes, it is. Right? Can the action route be anything? It can be anything you want it to be. You could change it to unicorn and it'd be totally fine. Right? And so in this case, it is post. So we're gonna look at our post routes and we know that it was a post with the create post route because we could have multiple forms that are all doing posts, right? So we could have one form doing maybe image uploading. We have a different form for video uploading, whatever we want to build, but we could have had multiple posts on that page. And so each post needed its own route. Like each of those forms needs their own route. And so when we look at this profile.egs, Yes, yes, it's on the post route, but how do we differentiate between different forms? Well, this is the create post form. So that's what we're looking for. In our routes, we're looking for a post route and

07:21:00
create post, which is in there. And then we have this upload single file. And so if we look at the upload single file, we can see upload is actually requiring Molter. So Molter is a little bit of middleware. Middleware is the stuff that sits between a request and response that helps us do our job. And so if we actually look at our middleware and we look at Molter, there's a lot, there's a lot here. But this is just something that you can yoink from from either the npm package or now from this, this bit of code here. But the idea is that Molter is going to handle uploading the files for us. And you can see right now it's checking to to see if it's like an image, like if it's a JPEG, a JPG, a PNG. If I tried to upload like an SVG file, this wouldn't work. If I would try to upload anything that's not a JPEG or a PNG, it just wouldn't work. And so if you want to do different types of files, you can just get rid of this check or change it to be the check for the stuff that you care about. So once

07:22:00
again, do I have any of this memorized? No. Is this something that I could probably code from scratch? Probably not. This is part of all my templates. I just know to grab this Moulter is going to help me handle my file uploading So if we go back to our post routes, we can see all right It was a post request on the create post route we have Moulter helping us grab that file that was uploaded and We're gonna go to our post controller and use the create post route All right All right Cool, yeah, and so right now, yeah, this is like oddly restrictive, right? This is oddly restrictive, yeah. Cool, all right, so we used Molter to help handle that

07:23:00
image uploading. Right now all Molter's doing is helping us get the image. We haven't done anything with the image yet. We're going to go to our post controller and the create post method. So let's go to our post controller. Let's look for create post. Ah, here's create post. Now, this is where some of the heavy lifting starts to occur. What we're doing here, the very first thing we're doing is we are using Cloudinary to upload the file that Molter just helped us upload. So Molter is what helped us grab the file that was being uploaded through the form. But what Cloudinary is doing is taking that file and putting it on their servers for us. So Cloudinary sees the file that we just tried to upload. It takes that file and it puts it on their server. It puts that file on one of their drives somewhere out there on the internet.

07:24:00
And so Cloudinary, you can see that we've required it. We have this lovely middleware for Cloudinary. And once again, it's just trying to grab, you need like your cloud name, your API key, API secret. Like you need all this stuff that's coming from your ENV file to be able to use Cloudinary to do that uploading, right? And so Cloudinary, the very first thing we do is, hey, that file that you were just trying to upload when you submitted that form, we're sending that to Cloudinary. Now, how do I know to do uploader upload rec file path to use Cloudinary v2? Like how did I know to use any of that stuff just from their docs, right? Just from their docs, right? You read the Cloudinary docs, So it shows you exactly what to put in. It shows you specifically what to put in with, with Moulter. So you copy and paste and that's kind of it.

07:25:00
Yep. So it's not something that like you deduced somehow you read the docs, it told you how to do it. And that's what I did. And so now my images will be uploaded to Cloudinary. Cloudinary is going to do its thing and it's going to send a response that I'm going to store in result. And the cool thing is, once I've sent that image to Cloudinary, Cloudinary sends me back a bunch of information that I'm storing in result. And I'm going to use that information to create my document in my MongoDB collection. So, we see that here. I'm actually going to create a new document in my post collection. That document is going to have the title that came from the form. Remember, we can get the information from the form by using rec.body. So I'm able to look at the form that was submitted and grab the title out of that form, right? I'm

07:26:00
storing that in the document that I'm creating. And I'm also storing the image URL that came from where. I'm gonna store the image along in that document. and where did that image url come from? Yep, that's part of the response that Cloudinary gave back to me. Part of that response that's stored in result. I'm able to grab that url that they gave me and put that as part of my document. They also gave me an id for that image that I'm going to store or a part of my document, why might I want the IDs and not just the image URL? Why don't I just want the image?

07:27:00
Like I have the image URL, why do I need anything else? Well, remember, we eventually want to be able to delete these posts, right? And we want to be able to know like what image to not only delete from our database, but we also want to start deleting the images from Cloudinary as well. Because if we don't start deleting the images from Cloudinary as we delete them from our application, our Cloudinary instance is gonna become bloated. It's gonna have all this media that we're never gonna use and eventually we'll get past the free tier and have to start paying. So we want to make sure that we're not only storing just the URL for the image, but also the ID so we can eventually like delete it and do any other fun stuff we need to do later on. It's 2K1, 300 bits. Is a degree in cybersecurity web design development good? Depends on what you need it for. You just spent 300 bits to ask that question.

07:28:00
That could be the last dollar you ever spend and get an amazing job in web development without needing to spend anything more. So we've been doing a free 30 week software engineering program here that takes from everything you need to know from zero to how to get a job. You do not need a degree for that to happen. Now, degrees can be useful for other things, especially if you're coming from a country that requires degrees for certain jobs or you need a degree for visa status, things like that. But in terms of getting a high paid job or a well-paid job, no, you don't need it. Cool. Yep, and the IDs are unique, exactly. We might have multiple images with this. They might be used that URL multiple times, but that ID should be unique. Cool. We're also gonna grab the caption that came from the form. We're hard coding the number of likes, right? We're hard-coding the number of legs at zero.

07:29:00
And then we're also saying what user made the post by grabbing that rec.user.id. I love this right here. This right here, this blows my mind. Like, can we just stop and think about this for a second? Right? Like if you, if you can get to the point, come on, let me highlight it. If you can get to the point where just what I have highlighted, like makes sense. Think how far you have come. We're gonna walk through it one more time. Because if you understand what's happening right here, this is like mind-blowing stuff. Because to understand what's going on here, we have to understand a lot of key stuff, all right? One, we made a request to a server. That server heard the request and told us to come to this controller, Controller, controller, right? To come to this controller. And when we come to this controller, the first thing we're gonna do is take that file that was part of the form

07:30:00
that we submitted and send that to a third party service that is then gonna respond back to us with a lot of information. It's gonna say, all right, here's the URL to the image that's stored on our server so that you can use that image in your application. Also, here's the ID for that image. So in case you wanna do any stuff with it, like delete it from our service, whatever you can later on, right? And then we're gonna go ahead and create a new document in our post collection. So we're using this post model, we're using Mongoose to actually create a document in our collection. We're grabbing the title from the form. Like when we look at the profile EJS and we look at the form, right, that form has a title, an input with the name of title. So we're able to grab that title from that input because the input had the name of title, right? So we're able to grab that title

07:31:00
from the form that was submitted and store it in our document with the name of title. We're able to grab the URL that came back for our image from Cloudinary and store that in our document, the ID in our document. We were able to grab the caption from the body of the form as well. We were able to hard code a number of likes and we're able to grab the user ID from the logged in user because we have a session and while the user is logged in, because we're in an authenticated route, we're able to use that session because each request we're making is also sending the logged in user's info and we're able to take that logged in user's ID and store that along with our document. And when we go to our MongoDB and we refresh, and we go all the way to the end, we have a lot, let's go to the next one.

07:32:00
And we have random job, we can see that all that stuff is there. The title that came from the form, the Cloudinary link that came from Cloudinary, the ID that came from Cloudinary, the caption that came from the form, the hard coding of the likes, the user ID that we got because the user was logged in, the default created at timestamp because our schema told it to use the default of date now. All of that stuff comes together to create this one document that's inside of our collection. And when we were done creating that document, we told them to refresh the page, which made a get request, which used a whole different route, which was on our main routes. The main routes for the profile, we checked to see that they were still logged in, they're logged in. We go back to the post controller, we go to the get profile

07:33:00
route. And this time when we go to our post collection, and we try to find just the post of the user that's currently logged in, we're gonna find that new post. We're gonna take all the information that's from that document, pipe that into the EJS, pipe all the logged in user information into the EJS, and that's why on that reload of the page, we see the post. If you understand that, 10 second warning, Maybe lights and music. If you understand that you are in the the echelon of echelon of people that have tried to understand this stuff and did not get there, so let's party.

07:34:00
Congratulations, that's fucking huge. you should be overwhelmingly proud of the hard work you put in to get to the point where 90% of that makes sense. You can still have 10 to 25% that doesn't, but if you understood most of what I said, that's ridiculous. Absolutely ridiculous. Oh yeah. Cool. All right.

07:35:00
Questions while we're here. Questions while we're here. How does, how does this take me to an individual post? How did that know to go to a specific post? When we loaded this page, right, if we go back and I look at our profile EJS, when we look at this profile EJS, we're going to see that in this profile EJS is is this link, sorry, sorry, this loop for building out LIs for each of our posts. And what you're

07:36:00
gonna notice is that each post had this link that we hard-coded. I hard-coded the slash, I could have called the slash unicorn, but since we have a routes file for our posts, I wanted to make sure that I used that route. So I said, hard-coded the route post, and then I'm plugging in the ID that came from the post collection. This for loop is gonna run once for every single post that we have. And so it's gonna create all these allies that have an anchor tag for each post. And so the actual anchor tag is gonna have the ID for that post in it. And so when I inspect, I can see that. Let's take a look. When I inspect, I can see that that ID is already there. So when I click, I'm going to go to localhost2121 slash post slash this ID. And then I can use that ID that's in the URL to load this specific post

07:37:00
that we did first. Beautiful. Can any JavaScript be added to EJS? Yep, you can link to any, you can link to anything. You can put it in your public folder if you have like individual files. But yeah, you can, the EJS is pretty flexible. You can put whatever you want in there. If you wanted to display text fields associated with the image, would those EJS templates go inside the UL? You mean like on the profile page?

07:38:00
On the profile page, yeah, you would just put like inside that for loop, you would put whatever you wanted in there. So if we look back at this for loop, remember you still have to use the array syntax because it is looping through the array of posts. And so you can't just do like post underscore ID. You have to use the array syntax. You can put whatever the heck you want in there. You could put, it was like title. I guess we could do like title if you wanted in there, on whatever you want. So let's, let's try it. Let's do H2. And we can just yoink this here. And I believe it was title that each post has. Cool. And so now you can see that it has like the title there as well.

07:39:00
Where did we get the array though? So good question. When we, inside of our post controller, pass this information into the EJS, like, So we went to our our post collection and we find all the documents Right, we find all the documents and we store those in the post variable Back in the day before we were using mongoose what we had to do, right? You Man it's Sunday. We outside y'all. We outside. We outside.

07:40:00
It's Sunday as heck. It's five Hours in the mods are sleeping. It's been five hours Either of those would be fine Either of those would be fine, all right. Either of those are fine, my friend, all righty. So, where were we?

07:41:00
Oh boy. We were talking about, oh, this part right here, this post. All right, we were talking about this post. So back in the day, back in the day, we used to do things like db.collection, post, find, and then we had at the very end, right? At the very end, we got the two array. So before we were using Mongoose and we were just working with raw MongoDB, right? We had to say, hey, whatever we had back from that collection, turn it into an array and then send that array to the profile EJS. So the beautiful thing is that we've been building up, right? We've been building up to understanding what's kind of happening behind the scenes. So like, if this is your first walk through this code base,

07:42:00
know that we took like two, three months to get up to this point. There's a lot of little things that we took stepping stones through. I hope you appreciate that. Like, I hope that you appreciate that we started off with like raw stuff, raw modules. Then we added Express, we added raw MongoDB. we saw that we had to do two array to get an array. And now we sprinkled on some magic. And when we use Mongoose, Mongoose knows, hey, when you get all this stuff back from the collection, you probably want it in a what? You probably want it in an array. So we don't have to worry about doing the two array anymore or anything like that. Like Mongoose has already handled that for us. and it already kind of has like this, like implicit array return. So it already returns it as an array for you. And so I think when folks jump straight into Mongoose, they lose that understanding. They don't really see that, oh, we actually used that to go back in the day and like grab this, turn it into an array ourselves, and

07:43:00
then use it. Mongoose is doing that heavy lifting for us, that when we pass posts into our profile EJS, we're actually passing in an array already. All righty, that loaded the post, I think there's one other thing I want to see for today. Like I said, I wanted all this fresh in your mind. I know we had done this and then we kind of like took like two weeks while you're doing MVPs and other stuff. We introduced React. And so I know a lot of folks just from from people have been reaching out like kind of forgot some of this stuff So I want to spend five hours today at least four hours going through it together and then on Sunday We'll do the from scratch I really think doing it from scratch can help solidify the last like Final like neural connections you need for this to link in The last thing I want to look at today before we answer some questions before we do a raid is

07:44:00
of the liking So we're on this post, right? We're on this post and we like something, how the heck did that work? Right, how the heck did that work? Right, and so when we look at the individual post EJS, let's go look at that individual post EJS. We can see that we have a like button that is here. Oh, this is for the comments, sorry. Here is the delete and here's the like. So here we have this like button. And what we're gonna notice is that the like button is actually a what? The like button is actually a what?

07:45:00
It's actually a form. So before we had method override, what would we use? We wouldn't use a form, we would just have like a button that they could clicked on and what did we need for us to hear that click? What did we need before we use method override? Yeah, we needed a Smurf, we needed an event listener that was listening for that click. We needed some client-side JavaScript that was listening for those clicks. And when it heard the clicks, it would make a request to our server using fetch, which we talked about earlier. Fetch is not something that's native. The browser has to provide that as part of the web APIs for us to be able to make the request at all to our server. Whereas a form that's making a post, that's native to any browser. And so we can have

07:46:00
a form that submits a post, but if we look, we have a query parameter at the end. And so this form, when we submit it, is going to submit a post request to our server. It's going to use the route of post like post. But if we look at the end, and it's going to have the post ID that we're on, right? Like if we look, it's going to have the actual ID of the post that we're on. But at the very end, and it has this query parameter, underscore method dot put. And so what's going to happen is this request is going to be a post put to our server, but our server is going to see that query parameter and know to treat this post as a what? It's going to treat this post as a what? As a put, exactly. So we don't need any client-side JavaScript. We don't need any event listeners. we can use the forms that we're comfortable with. However, we just add this little query parameter that tells it, hey, server, treat this post as a

07:47:00
put. And so let's go ahead and take a follow that through. We know that's on the post route, like posts, and then the ideas in there. Let's actually take a look at that in the inspector real quick. We can see that it has the like, so slash post, like post, and then the idea of the post that we're actually on, the underscore method equals put. So when this form submits, that's the entire route that we're submitting. The entire request is a post on slash post, like post, the ID of the post that we're on with the method override of put. So when we submit this form, that's the request that's making it to our server. If we follow that step-by-step, starting all the way at the server.js, it's a post route. So we have to go to our post routes. We know in this point in time, If we look at the server JS, since it has that underscore method as the query parameter, the method override does what it needs to do. It no longer is a post, it is now a put.

07:48:00
So when we look at our post routes, we're actually looking for a put. We're looking for a put on the like post route, and we're grabbing that parameter, which was the ID of the post that we're actually on. So when we go and look at our post controller and we look at the like post method, we'll be able to yoink out the ID of the post page that we were on. Let's go ahead and look at our post controller. Let's look for the like post method. All right, here's that like post method. And what we're gonna do is we're gonna use our Mongoose model to talk to our post collection. We're gonna find one post and update it. We're gonna find the post that has the ID that came from our URL. If we look, the actual ID right here, the CC5 ID for that post, that individual post, its ID was FCC5, right? We're able to find

07:49:00
that actual ID, right? We're gonna find that actual ID. We're gonna find that post. And when we find that post, So we're gonna update it by incrementing the likes by one. So the likes were originally zero. We're gonna increment that likes property from zero to one, and then we're gonna redirect them back to the post that they were already on, right? So we're just gonna refresh that page. And when we refresh that page, we now see that the likes are one instead of zero. Let me check a look. Is it possible to restrict one like to one post per user? Yeah, you just have to keep track of the users that already liked. Lots of ways to implement that. Maybe we'll do that as part of our spree run next week.

07:50:00
Yeah, so far we've only dealt with using the actual parameters after the slashes. And we're not actually using any of the query parameters that come after the question mark. Yeah, if we look at our original design, we actually said, all right, well, we could have a users who like property on our document and then just put in the users that have already liked it. And so if the user already liked it, we just wouldn't even render the like button anymore. So like in our EJS, we could just have like a conditional that legitimately wouldn't show the like button if they'd already liked it. That's one way we could go about it. Are we gonna do any more 100 Dev Search? Boy, are we. Boy, are we. It's Huntober. We got a lot of surprises up the sleeves, you know?

07:51:00
Is using fetch not recommended? I think it adds a lot of extra work and it assumes stuff about the client that you're using. Right now, the client is the browser. Maybe we turn our code into what? Where else could our code run? Where else could our code run eventually? Yeah, maybe we build a mobile application, maybe we put it on a refrigerator, maybe we put it on our TI-83+, right? And so running this code in different environments means that you might not have access to fetch, right? And so this is one way to kind of simplify a little bit, yeah. And I'm talking client side, not server side. Yeah, good point, Nick.

07:52:00
Give me some 100 devs coasters. Actually, that's actually not a bad idea. I think that'd be a good one. All right. Hey, Fernan, good luck. Alright, so I think that kind of takes us through some of the trickier bits, right? It took us four hours, but we got through the big pieces. We got through the ability to see posts, to create posts, to like posts, to kind of do the big pieces here. We saw the cloudinary again. We saw kind of like what I think are the heavy, the heavy lifts, right? The heavy lifts. So we got about a little less than 15 minutes left. I said we'd go for another hour. I want to just kind of go through some of the stuff that's left here in the Slido, just to answer some questions

07:53:00
because we haven't really done a true office hours in a little while. So we'll take like the last 14 minutes or so, then we'll do a raid, get those sweet, sweet, sweet channel points. And then we'll come back next Sunday. Yeah, we'll plan for next Sunday for right now that we'll do the speed run from scratch. I didn't want to jump right into it just because I felt like too many folks would get lost without having reviewed it. So review it. If you need to watch back the VOD, you can to be ready for next Sunday and then we'll just go from scratch. Raisin A, thank you for the hydration. Cheers to you. Izzy with the bra. How you doing Izzy? It's been a minute. What time are you planning for tomorrow's Discord session? It's gonna be later than we normally do Most likely like 8 p.m. Eastern Time But I'm still finalizing Like I said, I'll share everything in the morning and then we'll give we'll have more advanced notice for everything in the rest of October Mm-hmm.

07:54:00
All right, let's look at some of these questions here On average what cue will coding challenges be in interviews? I know this varies I just want to gauge around that I think for most entry-level roles if you can do up to like six cues You're probably good now if you're trying to get into like fang or something else, like that's a whole different ballpark, but like normal companies If you can do six cues reliably, you're probably in a really good spot Is MVC lecture requirement for Huntover homework homework is required. So if you haven't submit your homework, that's a requirement How do you grab a variable that was set in EJS? I use the beasting syntax to use any of the variables inside of EJS. Is it best for the controller to sort items that have things sort on the client side? Yes, I prefer all my like heavy stuff to

07:55:00
happen on the server as opposed to like rendering out the EJS or that happening client side. So, but that's a preference depends on what you're doing also. I need more time for my MVP. Can I work at my own pace and remove the stress from my life? Of course. Remember this, this is, this is, you always go at the pace that works for you. We always have the catch up crew too, that you can work through that pace with others as well. October is just a focused month for folks that are absolutely ready. That's it. You don't lose anything by not participating I have my first meet with a recruiter tomorrow nervous af any words of wisdom. You're a boss Why are you worried? You're going to go in you're going to show them all the cool shit You've been able to do all the things you've been able to build you're going to talk your talk and you're going to get the job That's it and uh, it's 160 All right, it's one of 60. That's it, it's

07:56:00
one of 60. Why get nervous with one of 60? You can literally go in, slap the stuff off their desk and walk out one of 60, who cares? You gotta take the pressure off yourself because it's literally one of 60. And in terms of recruiters, don't ever sign exclusivity. That's the only thing I have to tell you about recruiters. Don't even sign anything that smells like exclusivity. So like if you work with recruiters that aren't like in-house recruiters, sometimes they try to lock you into a deal to where you can only get a job through them. Don't ever, ever do that. People say the job is being a good Googler. We have a class on being a better searcher. Uh, not really, um, it's, it's kind of on you to Google, how to Google better.

07:57:00
I know that's, that's pretty funny, but, uh, yeah, it's, it's, it's, it's what you've been doing. You've, you've gotten better. If you've been here since the beginning, you've already gotten better at it. Um, there are like cheat codes with Googling. I showed them with the, um, the magic hack for finding open roles, uh, those like that style of entering queries into Google works. So like, there are like ways you can do to make your, your queries better. Um, but you don't really need any of that stuff day to day. Yeah. Yeah. I would, I would look into like the, the different ways of like actually searching on Google that would make it easier to find results that you care about. I use the timestamp thing that I showed you a lot. Like sometimes I don't want to see tutorials from 20 years ago. I want to see like something that was made in the last six months. Right. So often I'll throw on my Google queries, the, like the timestamp

07:58:00
piece so that I only get results that are recent stuff like that. How do we manage SDKs with MVC? Depends on what you're doing. Sometimes you just incorporate them as middleware. Sometimes you do other stuff. It kind of really depends on what it is. I do Code Wars and Anki daily and homework for methods. I still have to refer to Google for syntax and looking up methods, do technical interviews let you use Google? That's a really good question. A lot of them, it's a bad look. That's just true. A lot of them, it's a bad look to, it just increases your smell, right? Like if I had an engineer that had to look

07:59:00
it up and an engineer that knew it, of course the engineer that just knew it is gonna look better than the engineer had to look it up. I don't know why that is. I don't know why people care about that shit. You're gonna be using Google all the time, but it's just, it's true. Some interviewers will hold that against you. Some interviewers are blatantly obvious. Google the fuck, like they don't care, right? It really, it's a personal thing and that's why it's better to have them memorized so that you don't have to look them up because some folks will care, some won't. And you never really know who you have in an interview and that's just the truth of it, right? I'm gonna show you how to play the game so see if you wanna play it. So the reason why I introduced Anki And why I always talk about Anki is because these methods should very easily already be in your Anki I've given you methods now for four weeks for homework, and I've told you to put them in Anki every single time So if you're getting ready for the hunt and you haven't done that you're at a disadvantage Already because you should have been getting that review and with those methods already So now is your your call to action to start now

08:00:00
if you haven't already You want to make sure? that you are putting those methods in the Anki, that you know the basics, and that you're doing the code wars in series to practice those specific methods. It doesn't make sense to memorize all of your string methods and then do code wars that are array problems, right? Like the reason why I keep telling you to like do specific code wars and specific methods is so that you're getting that practice. And by the time we get into our daily classes for Huntober, you'll already feel pretty good. You Mm-hmm Some people talking about like comparing yourself to others that's that's the hardest part right now

08:01:00
You have no idea what somebody's life is like and if they're balling out on Twitter That's that shouldn't be something you take the heart. Like it doesn't matter like I Hope you read the celebrations channel. Just go read the celebrations channel. So many people got jobs that didn't have baller stuff Like we had how you people get a job just because they can code a fucking button Like it makes no sense at this point in time to compare yourself to others. It literally doesn't matter. If you go about the job search process in the right way, it literally does not matter. And so you should, you should see other folks getting jobs and get happy. The other thing too, about this being a global program is none of you are really competing against each other. Even if we do have like some strong states of like New York or something, that's such a big area. Like, like there's, you lose nothing by other folks doing well. In fact, it makes it easier for us to say, look at all these folks that

08:02:00
got jobs from the same program. Like that's, that's the next level, right? The next level would be like, Oh, like if all these people are getting jobs and they went through the same thing, then you must be as equally good if you've also gone through it, right? And so you got to look at it that way. The people that are balling out are doing you a service that makes your experience more valuable, you know, like you turn in everything and you graduate, you get the benefit of that, of that, that juice. Uh, is there another Huntober for ketchup crew? Will they get the same? Letter from you or is it exclusive for hunt over for now right now. I am only doing verifications For folks that are going through hunt over So that that's it right now until

08:03:00
we figure out how to do it. Well at scale What the verification is like somebody says like hey did they go through the hundred test program and I go yes They did and I give you a letter that says hey this person went through the program So you can use that as you're interviewing that that's just for folks that are going through October right now Once we figure out how to do that at scale I figure out all the the kinks and things like that as other folks complete the work They'll be able to get that letter and that that verification as well Nobody's ever done this before so it's gonna take a little while for us to figure out how to do it well But we're gonna figure it out And that's the other reason too, right? Like that, what we just talked about is like the a hundred devs brand makes it better for you, like if you complete everything. So I have no interest in doing verification for folks that haven't lived up to that brand, right? That's one of the biggest things I noticed with RC is that we

08:04:00
have employers that come back time and time again, because they know the quality of engineers that we produce at my day job. I want the same thing for y'all. I want somebody to see a hundred devs on your resume and go. Oh, they must really know their shit Right, and I have no interest in letting people slide that didn't put in that work Because it does have a long-term impact Right. We had how many people go to Amazon? We have had how many people go to some pretty top-tier startups, right like over time The goal is that you turn around you bring more hundred devs folks with you The goal is that that brand means something when folks show up on the job, right? Like that, that's the goal. And we saw Blawl do that recently. Blawl just got another a hundred devs member hired at their company. Like, like, like that's the goal. Like that, that's the whole point, right? We started because we wanted to help folks that were affected by the pandemic. And that's what we're going to do.

08:05:00
I really enjoyed using tailwind and daisy UI, but how do I make it look more of my own? That's kind of the downside of using like bootstrap and tailwind is that I can kind of look at a saying go That's tailwind, right? Just because if you're using especially like the default like Components and stuff like that. It kind of starts to look similar there was actually I can't I can't find the study but somebody did like a Usability study where they actually showed using bootstrap increased your conversion It's because people were more comfortable with this thought like they it felt familiar Like because they'd already seen a bazillion sites that used that kind of like stuff So for a while like it actually helped like boost your conversion a little bit. I gotta see if I can find that yeah It's not a bad thing Most people are designed the exact same shit these days anyway Jack Tree, send a mod mail.

08:06:00
I had a super senior dev that helps me out. So people are having a hard time filling roles, hiring people, there's more open jobs than there are people to fill them. Is that true? Yeah, I mean, we looked at the reports, right? It was 53% year over year growth, 300,000 plus open positions like it's out there and we're seeing that come to fruition. We literally had what two weeks back to back of 15 jobs each week. Like literally like 30 jobs in two weeks. That's wild. Oh, I like that. Most of the companies all have the same can as the content that matters, eh?

08:07:00
You can always join the hunt whenever you want, but the Huntober stuff is for folks that everything turned in on Tuesday. JavaScript and code still don't make sense to me. As a result, I hesitate on doing them every day. any advice, you're not doing enough review. Stop doing new problems and do the problems that you've already done and review them until you don't have to guess how to do them again and then do similar problems going forward. So a lot of folks mess up on Codewars by going too fast in terms of they go from like eight to sevens very quickly. You should start off with level eight cues, fundamentals, and do the same types of questions. String, string, string, string, string strings, then a raise, a raise, a raise, a raise, a raise, a raise, a raise, right? Once you get through all the array problems, stop, go back and do all the array problems again and do them again and do them again until it clicks. You don't have to guess.

08:08:00
Should catch up crew folks be turning in homework for assignments from months ago? Yeah. How am I supposed to know if you did the work or not? Right? Like if in the end, You want me to say this person went through a hundred devs. Yeah, you need to turn in the homework I mean you don't need you don't need me right like Like you don't need me right like that's that's the thing, right? You don't need me to get a job You don't need me. You don't need my verification. You don't need our certificate. You don't need any of that crap If you want it, you know, they put in the work Most folks get jobs without that stuff. We didn't have that stuff until recently, right? And so you don't need it. If you want it, then I need to know that you did it. All right, let's get into it, folks. We do have the Slido in the newsletter they'll be paying attention to. We're gonna take our time. We're gonna have a little bit of fun.

08:09:00
And so don't feel like you can't ask questions as we go through it, it is our Sunday, it is our backend super review. And so happy to answer questions as we go along, even if they're not totally on the mark. So what I did here is I just grabbed a copy of the binary upload boom. So if you want to follow along, all I am doing is using the binary upload boom. So you can go ahead and download that set of code from GitHub, I'll actually put the link in chat here. Let's see, GitHub slash 100 devs, cool. So this is the code base I am starting with that I will put into chat.

08:10:00
And what I want to do with us first is I just made a copy of this. And probably the first thing I'm going to do is remove my, actually I'm not going to push anything. So probably one of the first things I want to do is just remove my Git folder. I could do something fancy, but just to save myself a little bit of headache down the line. Let's go ahead and let me just do an ls to make sure I'm in the right spot. Cool. ls-la. All right. I do have this git folder. So I'm just going to do an rm-rf.git. All right. ls-la. I just want to make sure that I don't have that git file anymore. So the reason why I did that is just in case I start pushing or doing anything weird, I don't want to mess up like my actual code

08:11:00
that I already have on GitHub for y'all. And I know there's easier, better ways to do that, but I'm just saving time on Sunday. What do you want? How much delayed are the YouTube videos. Uh, I think YouTube is up to class 52 or so. Um, all the, all the other ones are on Twitch for right now, but the next big tranche is queued for Tuesday. And so by the end of this upcoming week, YouTube should be all caught up. Yeah. Is it wise to watch weekly videos if I'm just starting yeah, I think everyone takes the catch-up crews as their own different pacing So some folks really like the two classes a week schedule and for some folks that's too slow for some folks That's too fast. And so the beauty of doing the catch-up cruise you can go at your own pace I'll just make sure that you're on discord so you can get help when you get stuck

08:12:00
Yep, and for folks that are just joining us today, this is like class, well, this is like part three of our backend review. And actually like, this would be like class 15 of backend, right? So if you're just joining us, there's gonna be a lot of stuff that we've already covered in detail, and I'm going to be skipping over that expecting that you've already kind of gone to those classes. So, um, last back in review, for example, uh, we covered what all these packages do. So I'm coming into it with the sense that you kind of already, uh, kind of know what those things are. Uh, it doesn't mean you can't ask questions, but that's kind of just, you know, where we're at with this back in review, uh, so that we can, um, be respectful of people's time. Cool. Cool. All righty, so now I know I'm not afraid

08:13:00
of messing anything up for everyone on the interwebs. I have this lovely starter. And I was gonna take a look at the package.json. We have everything going right. We have the start command. So I'm gonna do npm start. Server is running, you better catch it. But notice that I have not connected to my DB. And that's because I did not whitelist my IP address and so I typically run on a VPN and so every time that I kind of Stream one of the things I have to do is make sure that the IP address that I am using Matches the one that I have whitelisted in my server. All right, so So, I'm gonna go ahead and make sure that I go ahead and whitelist my IP address on MongoDB's side. Should we be coding along? That's up to you. I think

08:14:00
the first part is kind of us talking and making a bunch of decisions about what stays and what goes in our template, and then we'll be coding. I don't think you have to code along with this stuff, though. Am I gonna push this to GitHub? Yep, mm-hmm, of course. Yep, node 18 now has watch. You don't need Dogemon technically going forward. Cool. So I'm going to go to my MongoDB. I have my cluster that I'm using with my QuickPound database. The QuickPound was the original name for this project. Of course, we had to change that. So we're going to go to network access. and before I do that, let me just test over here. All right, Google. All

08:15:00
right, so I'm gonna make sure my VPN was running. All right, VPN's running, so I'm gonna go to network access and here are some of the older ones. I'm gonna add IP address and I'm gonna add current IP address and I'm gonna make this temporary for six hours. That way if somebody was able to get the same IP address or whatever reason it would stop working after six hours. I'm gonna confirm it and then it's gonna take a little bit. I'm gonna delete these other ones because we don't need them anymore. And it just takes a few seconds for it to click through. Should we update node then? I always stay on the LTS or the long-term stable versions.

08:16:00
The versions that'll have the most support, the versions that will have the largest window of updates. So all my stuff is always on the LTS version. When the LTS changes, I change. And that's kind of always a process for me. But if you want the latest and greatest, of course, upgrade and get all the goodies if you want. All right, so IP address should be good now. I've whitelisted the IP address. So that means as I'm making requests, I should be able to add stuff, remove stuff, delete stuff, et cetera. So I'm going to do npm start. Server is running. It looks like I connected to the database. And what I want to do is just make sure that it's working before we start tearing stuff apart, before we start kind of removing bits

08:17:00
and bobs, you always want to make sure that everything works right. it would suck for us to build on top of a template or build out a template that just didn't work from the beginning. And so we're gonna go ahead and test that now. Will this backend super view be uploaded to YouTube? Yes, eventually, but I'm gonna combine all of them together. So I'm gonna combine our six hour, our four hour and whatever along this takes into one big video. All right, let's go ahead and test it. What was our, find localhost 2121. All right, looks like we're there. Log in. I don't remember any of the passwords. I think we got testy

08:18:00
at testy.com. All right, cool, all right, that was it. All right, so it looks like it's all still working. Hey, well, we still have the individuals. And the cool thing is we added like the titles last time, which is there still. We have individual posts, likes still work. Comments are still working. And let's also trash one of these. So let's go to new post, new post works. I'm just gonna test adding a comment. Hey yo. Cool, comments work and does deleting work? Beautiful, looks like deleting

08:19:00
works too. Last thing to test, we'll just test uploading. Title, test, test, choose file. List up, great haul, there we go. Submit. All right, beautiful. Looks like everything's working, even on new posts, comments. Love it. And I can delete. All right, cool. So everything looks good. Everything's good. And I feel comfortable that since it's working, We can start to build our template from this and so I can't stress how important this process is And

08:20:00
I do it all the time before I ever Build on something old. I always make sure that the old works Does the leading also remove the image from cloudinary yes, so during the last back-end super review I showed you cloudinary I showed how how the ID is important because when we delete an image, we're actually not only just removing the post from our database, we're also removing that media from Cloudinary because if we don't, then we wind up having all these images on Cloudinary that we will never ever be able to use, which can then increase our bill over time. And as we build a template, I'm sure we'll see that again. Mm-hmm. All

08:21:00
right. Should there be a comments on the file link Leon put in chat? Yes, but they are on the comments branch. So part of your homework was to add comments. And so for folks that did that, I didn't want to have it as part of the main repo. So there are two branches on GitHub. There's main and there is a comments branch. So if you want the comments, you need to use that branch. But we're going to get rid of the comments off of this anyway, so it's not super necessary right now. Do we have an alternative for Hiroku yet? Not on mine personally. I'm still playing with all of them. I feel like as I go deeper with each, I find something that I don't like.

08:22:00
It's actually been a pain in the butt, but I'll probably make my recommendation this week because we kind of have to pretty soon. Travis Media did a great video on Hiroku alternatives, which was really helpful. The big ones keep coming down to me being railway, render, cyclic, fly, but I keep running into like a weird issue with each of them. So I think it's going to be the best of them. And I'm not ready to make that decision yet. So as soon as I'm done doing all my testing and I actually find something that's stable and won't actually affect your hunt when folks go to view your stuff, then I'll put that out there. Yeah,

08:23:00
they all kind of have trade-offs I keep seeing. And so I'll share what I think is my go-to, but if you start with any of the ones I just mentioned, you'll probably be fine. I just know the one that I say is probably the one folks will use. So I don't want to go into that lightly because, uh, this is probably the only time that, uh, it really matters because hiring partners and, and companies will be looking at your projects. And so I would hate for them to be down or something weird happen. Why do programmers tend to grow long hair, beard, or both? Is it a cultural thing? Yes, absolutely is. Programmers grew up in counterculture and long hair was considered being counterculture. And so a lot of folks grew long

08:24:00
hair. They grew beards and it kind of stuck New wave it's very different. There's funny there's like a What is it in in Silicon Valley? They they talked about How every group of programmers has like the same five people in it and like it that's stereotypically pretty true But it's times are changing times are changing things are no longer the same as they used to be And I think it's it's all just silly, right? Cool Alrighty so I feel like we're good. We're in a good spot everything works What I want to be able to do is take this, let me stop the server for a bit right here. What I'm gonna be able to do is take

08:25:00
this and make it so it's something we can use going forward. And so first, I guess while we're here, we'll change the name to like full stack template. And we'll call this description will be Starter template for future projects, cool. Main will be server.js. We're still using NodeMod because maybe not everyone has popped up. We'll leave all for empty because that'll be whoever you are. The license is MIT. Most of my stuff is always MIT or GPLv3. And then all the methods that we need. So we're not changing any of these. We're going to use all of them in the template. If you don't know what any of these do, definitely want to watch back into preview part two on Twitch FOD.

08:26:00
Cool. All right, so let's start with the server JS and see the things that we want to keep. So the idea here is we don't want anything that's specific to binary upload boom, we want a template that we can use to build going forward. And so all this stuff that I see right here, express, app, mongoose, passport, mongo, store, flashlogger, all those will stay. Connecting to our database will stay. But here's kind of where we get into the first things that we might want to remove. And so I think we should keep Main routes, but will be a little bit more picky about what goes into the main routes. If we look at our main routes, let's go to routes main JS. We have a lot of stuff here that is kind of unique to binary bubble of boom, but a lot of stuff that we probably want for. For every project.

08:27:00
Right for every project. And so if we look. We're gonna want sign up to always be there log out log in like all that stuff. That's on the off controller That's going to stay And so I think all the stuff that's on the off controller will probably stay We're probably not going to need feed or or anything like feed. I think is very specific to this project but profile will leave as an example of using the post controller and And I think the loading the home page is probably okay. So I'm gonna yoink feed, because I don't think I need that right now. So I'm gonna comment it out for right now, and then we'll get rid of all of our comments once we're done. Cool. So if we were to have all of our main routes, we're gonna need,

08:28:00
like being able to load the main page, or we're gonna need to be able to load a profile, We're gonna be able to log in, log out, sign up, sign up, sign in, sign up. The feed was using the post controller. So there's nothing here in our main that has to change. I don't think we actually have guest accounts enabled. So we will probably get rid of that eventually too. All right, so main looks like it'll stay. Main routes is fine. Then we have this post routes and comment routes. I think we could have a, let's look at post routes to see what's in here. Post controller, create post, upload. I kind of like having some examples for this. And so I think we'll keep the post controller so that we have an upload example of our Cloudinary. we'll probably just call

08:29:00
it something different, right? I want people to know how they can upload media. And so it makes sense that we keep this and maybe, yeah, I want this at least to stay so we have an example that we can use for uploading the media. But then the liking and deleting, I think maybe we can probably be simplified with that. And so the reason why we're doing this, right, is that one, it's giving us a better intimate kind of understanding of what's actually happening in our application. It's helping us rethink like what we want here going forward. And so that's kind of the point of us doing this together. It's just like, all right, why is this useful to have? What is it actually doing? And we're kind of seeing that again for the third time. All right, so I'm going to want to keep some of my post routes. I definitely know that I'm gonna wanna keep the create

08:30:00
posts. And for folks that'll be using this, so I guess I'll ask y'all, would it be helpful to keep a put and a delete so that you can see it? Like a get, a post, put, and delete. Does it make sense to keep an example of each of these in the template? Even if we like, we change the lingo a little bit? Yeah, okay. So it looks like we'll keep the post route then in the template. And we might kind of simplify it. Maybe these aren't actually fully fleshed out. Maybe they'll be commented, but having them seems like a good idea. Cool. So maybe we can even just comment each of these. Cool. All right, we'll come back in a second. So post route looks good. Comment routes, let's take a look at the comment routes. So routes, comments. I feel like if we have posts

08:31:00
and we keep the post routes, do we need the comment routes as well? I don't think so. I don't think there's anything that's in the post that's not here. So post comment, we have the ID, which is helpful and sure off comments control. Let's take a look at that comments controller. Yeah, I don't see anything special in this controller either. So I feel comfortable yeeting comments. Oh, man, I fucked up So I didn't eat anything and I took my ADHD meds and now I'm feel like I'm gonna throw up

08:32:00
All right I'm good for right now. But when we take our break, I'll probably throw something in my mouth. All right, so we got the We got rid of the comments route. So let's go ahead and clean that up. Let's get rid of the comments controller, delete. And the comments router as well, delete. All right, so that's gone. And we know that we have to go down here and get rid of the route. So this is what actually kicks off the comments route. We get rid of the comments route here because we no longer are going to be expecting any of those. All right.

08:33:00
Cool. So that is what would be listening for the comments. We got rid of the comments router and we got rid of the comments controller. I feel like that's a good spot to kind of remove some of the stuff that's specific to binary upload. Boom, boom, boom, boom, boom, boom, boom, boom, boom, boom. Rascal, why can't you share links? You should be able to a VIP. We'll take a look at that. I'll check afterwards. Thank you for sharing it again though. All right.

08:34:00
We got rid of the comments. Is there anything else here that we don't need? So we definitely wanna keep using our environment variables. We're still using Passport. We're still connecting to our database. We still have our view engine. We still are gonna be using our public folder. We still wanna be able to see what's inside of the DOM. We still wanna be able to log stuff with Morgan. We're using method override because we don't know if our client will expose the things that we need. We're still gonna use sessions with MongoDB, Passport, Flash. All right, cool. So I think everything here in the server.js days. Yeah. Uh, the medication is stratera. Uh, stratera is like something that like builds up. It's not directly like a, like an Adderall like stimulant. It's something

08:35:00
that has to be in your, like you take it every day and like builds up in your system over time. Um, Adderall makes me go to sleep. When I take Adderall, I just want to take a nap. It's weird. Apparently it's like not uncommon for folks that have like ADHD that, um, where it's not like necessarily like hyperactivity, but it's like the, um, like your ability, like not ability to focus on tasks. Once you take Adderall, it lets you focus on the things you want to focus on and my brain quiets enough. And I'm like, fuck, I want to take a nap now. Cool. All right. So we got rid of the comments. I feel like everything else should stay. Let's focus on let's just review main one quick second here. Main routes definitely staying profile definitely saying we got rid of the feed. All right. We'll keep all this.

08:36:00
Let's createPost, likePost, deletePost. And so, let's see if we can comment this a little bit better. So we'll say, for this, we'll say, enables user to createPost, Post uses with Cloudinary for image uploads, or we can say media uploads, because right now it's images, but it could be media uploads. Cool. The like posts, user

08:37:00
to like posts, and if we follow this through, let's go to the post controller. Go to like posts. We know that we're using the post model to find what we're going to update. Um, like posts in controller uses post model. Uh, I'm just trying to put like why we have each thing in here. So if somebody is coming back and like looking at this, uh, router, they understand, like, I know it says like posts, so that's like on the nose, but I just want to make sure that's clear to anyone that's using this in the future. like post and controller uses post model to update

08:38:00
likes by one. The thing I think it makes the routes kind of a little bit harder is that you do have to jump to the controller, find what you're looking for in the controller. So I think if we just have this in the routes would be a little bit easier for folks to be like, oh, that's what this is gonna lead me to. It's gonna lead me to letting the user like a post and in the controller, it'll use the post model to update likes by one. And I think that just makes it a little bit helpful, more helpful. And then kind of the same thing here. Enables user to delete posts in controller, uses post model to delete posts from MongoDB collection.

08:39:00
I'm completely lost right now. Should I just go back and review some of the other classes? I don't definitely understand back. Yeah, you definitely need to go back to other classes. You could definitely welcome to hang out and go through this, but this is the third, third take of our backend super review where we spent nine hours so far going over this and probably another 20 hours in class, so you're 30 hours behind if you're just joining us today for the first time. There's no way that this is going to make sense. What we're trying to do is take what we've already built, turn it into a template that we can use going forward, and then try building some stuff. How long are we going for today? I don't know. We'll see how long it takes us. All

08:40:00
right. All right, delete post from control, use post model to delete post from MongoDB collection. I think anything else is here. Is there anything else that you think would be helpful? I'm gonna remove ensure guests. We're not using it, so let's not confuse anybody that uses this template. Is there anything else that you think would be helpful to have in this router file? that was always tricky for you. Oh, you know what would be helpful to have here? The actual paths. Since linked from server.js, treat each path as Post slash ID. Actually, let's do it all in one line here.

08:41:00
Post slash create post. Post slash like post. I think that kind of tripped up a lot of people in the beginning. Let's just all have it here. Cool. How do I do wrapping? Yeah, you got how to view WordRap exactly.

08:42:00
Let's see. Cool. Could you have a route that has like a bunch of query parameters in the full URL? Technically you can, yes. Can you go over how you would change this project from React EGS? Not today, but if that's a class folks want, I'm happy to do it. Once we're officially done like the boot camp or a program I Still want to keep streaming. And so there's lots of little things that I would like to do. I seem to be a good one But I just wanted to be very clear that there are things you can do that'll

08:43:00
move the needle and there's some things that won't And so yeah Just that's what they want folks focusing on as they're in the hunt All right, so anything else that we should put on here that you think would be helpful? Oh, Rascal already did it, that's dope. Rascal, can you send me the link to the playlist or the VOD so I can share them with folks? Send me a DM on Discord. All right, so we'll keep this for now. Post routes

08:44:00
instantly from server.js, treat each path as boom. We have what each thing will eventually do. We got rid of the extra comments. Let's check off real quick, just cause we also have, before we go deep into the post routes, let's check main real quick. One last time. Did I do? Let's go ahead and check post routes. I'm sorry, I said main routes. We don't have any comments or anything linked here. We're still not using insured guests. Maybe we should keep insured guests in case people want to use it. Let's look at our middleware, our off middleware. We do have the ability to have the insured guests. Maybe we should keep it even though we're not using it. Might need to build out.

08:45:00
We haven't done guests and I don't think I really want it, honestly, so I'm going to eat this. And I'll take it out from main as well. The travesty homework goes into the ensure guests. We just haven't used it, and I don't think we need it. Cool. All right, so we, let's look at the main one last time here. Main routes. We'll get rid of feed, we don't need feed specifically. I'm just gonna get rid of the comment here.

08:46:00
Call this off routes for user login slash signup. Cool. Main routes we have, like if you just wanna load a main page and then profile will keep, cause I think most applications that have user logins probably have a profile. Yeah, I don't think we need anything else here. One bit that we do need to do before we get too deep is since we removed all of the comment routes, controllers, et cetera, we didn't remove the model. All right, let's remove that model, delete. What's one thing that we also have to do so we don't run into trouble?

08:47:00
Yeah, we need to remove it from the views, exactly. Our EJS right now would break. And this is kind of like what we're doing, so we can think through these things. If we were to go to the individual posts, the posts right now have comments in them. All right, so let's go here. We have like this add comment. We don't need that. Yep, yeet. And then we don't need to link to the comments. Yeet. Okay. Save. And I think that takes us to the big remove of the thing that, at least one of the big things we don't need anymore.

08:48:00
I'll remove the routes for comments. We removed the link to the router for it. That router no longer exists. The controller no longer exists. The model no longer exists. And we've added our EJS to no longer have it as well. Cool. Let's go ahead and save all of this, which we are. and let's start our server again and make sure everything doesn't break. Let's see, what did we do? Cannot find modules, comment, models comment. So we're trying to load a model that we don't have. Where did that come from? Ah, the post controller. We forgot that the post controller might, the post controller still might be needing to render the comments. So let's think through this for a second.

08:49:00
I know the answer, but let's think through this. Why are we getting this error? We removed the router, the controller, and the model, and we're getting this error. Cannot find modules comment from controllers post. Why would this be an error? It's looking for something that doesn't exist anymore. Correct. But why was it looking for it? It's required in Post.js exactly. But why did the post need the comments? Yeah. Yeah, remember each post had the comments on the post page. So if you're rendering the post, you also need the comments as well. So we can go to that post controller.

08:50:00
We can go to the post controller. And when we go to the post controller, you can see that we're requiring something that doesn't exist. So yeet. All right, so it doesn't exist, get rid of that. And we have to go to get post. Get post is trying to find all the comments, right? It's trying to find all the comments. yeet. And we're not gonna pass in comments to the EJS anymore. Yeet. Cool. So now we are no longer requiring the model doesn't exist. We're no longer trying to get data from that collection. I save it. Should be all good. Cool. All right,

08:51:00
let's try rerunning it. Servers restarted because no one was on it. Looks like we should still be working. Let's go to our profile. Let's go to Athea Networks and the comments aren't there anymore. So it looks like our app is still working. Let's log out, log back in, make sure all of our routes are still working. Testy at testy.com, testy, testy. I think I typed in the wrong... There we go, we're able to still log in, looks good. All right, so we cleaned that up. We're able to kind of yoink out the comments. We're able to better comment out our code so that folks that are using it know

08:52:00
what actually the heck is happening. When we come back from break, I want to continue this pattern of commenting, make sure we understand what each thing is doing. We'll venture into the post controller to make sure all that stuff is well understood. And then we'll go from there. Also in delete posts, let's take a look. Get posts, create posts, like posts, delete posts. No, I don't see, maybe you're talking about something else, but I don't see anything that's related to comments. Cool, all right, let's put five minutes on the clock. When we come back, we'll keep digging through this, make sure we're appropriate commenting, So folks can use this as a template going forward

08:53:00
And we'll keep pushing. Thank you for being here. Yeah, I was able to get some food in real quick Can we try adding a post I'm getting an error. All right, let's try it. Let's make sure that it's still working Mm-hmm Take two testing All right, looks like ours worked fine. See the title, see the hat, we're able to go to that individual post page. Yeah, no errors in our end. Did you delete the wrong model?

08:54:00
So at resilient coders, after our hustle week, which is where everyone has to get a client. So end of week six during resilient coders, resilient coders is the nonprofit I work at during the day, it's a coding bootcamp. Week six, everyone has to get a paid client. If you don't get a paid client, you're redirected from program, which means that you kind of don't continue on with programming the traditional way, you kind of go into your own learning plan. And so everyone has to get a paid client by the end of week six, and we sort you into one of four houses. And so I kind of ham it up, and I have everything set up to where we can sort folks into houses, and I put the hat on and we move it around. Yeah, so that's why I have so much Harry Potter related stuff on my desktop right now. All right, so yeah, so it looks like it's all working to me. Let's go ahead and

08:55:00
go ahead and take a look at server.js. I think the big thing here is that our main routes look good. We have our main routes. You can say this is like the home page, which we know. Profile, let's look at the home controller real quick. Off, I don't think we're gonna wind up touching. Actually, let's look at off controller real quick. Yeah, no, I'm not touching any of this. Is there something that we would need to touch at all? Like any of the authentication stuff, do we need to touch that? Nah, we'll just leave it there. Every app that we build will hopefully have some, like the authentication. And so if you really need it to, you could go ahead and like remove it. But I think most of your apps are going to have authentication.

08:56:00
So we'll just leave this alone. We're not going to touch that at all. The main controller, let's take a look at what that does. I'm sorry, a home controller. And the home controller is just rendering the main page. So I think this is totally fine to stay there. What I think this is a good helpful indicator of is like how you would load individual pages that were just kind of like your, like I don't want to use the word static, but just like your pages that are, like they're just simple, right? So your homepage, maybe like your about page, your contact us, stuff like that. That's not part of the actual application itself, but are kind of the generic pages that you need for a website. Cool. I think this is a really good example to have for that. Simple, just get request and it's all in the main routes. Beautiful. All right, last thing I wanna take a

08:57:00
look at is this post controller. we go to we have our post routes beautiful we have our post routes if we look at our post router we kind of have that nicely commented out and then you're gonna use the post controller which I think is probably our most serious bit of code here Posts, beautiful. We are linking Cloudinary, which we're still gonna need. If we look at our middleware for Cloudinary, all right, this looks fine. The only thing that this is doing is using Cloudinary. It's pulling in our keys from our env file, which is important to kind of keep the keys because the env file goes in our what?

08:58:00
Yeah, it goes in our gitignore, exactly. So we can keep all of our secrets in the env file. The env file goes in our gitignore. Don't have to worry about pushing anything to GitHub. Cool. We're using our post model. So let's take a look at the post model. PostModel, simple using Mongoose. I like this as an example because it's showing a lot of different things. It's showing just regular strings like title and eventually image. It's also still using Cloudinary. So if folks want to have things that are incorporating things from other places like Cloudinary, it's still there. It also has number as an example. It also shows us how to kind of make sure that if we want to use things that are coming from other models, we can. So in this case, we have a user that's really just a reference to our user model. And we also have the created at

08:59:00
which will use the date. So I think this is a really good thing. I don't think I'd want to remove anything from here. I love that this kind of has all the bits and bobs and it probably would be easy to extend from here. Um, on here, I want to just leave a comment, uh, for how the collection is named. Uh, MongoDB collection named here will give plural, uh, will give lowercase plural. I think folks get tripped up on a lot on that. They don't, they forget that this will give us posts in our MongoDB. We could maybe make it the, um, like where you force the name, like, cause you can add like a

09:00:00
third, right? You can add a third. I showed this on stream a third where you actually put the name and it doesn't like automagically create one, but I kind of like leaving it as the automagically create as long as we have commented as such. Um, because I think some people forget to like do the plural. So I actually liked the magic here, so I'll just save it with the comment. Are we going to optimize the data structures, controllers, and things we learn in the algorithms class? No, absolutely not. The only reason we have the data structures and algorithms classes so that we can get through technical interviews, but there's nothing here that we're going to really be applying

09:01:00
because we just don't have time to go that deep on stuff. But a lot of the stuff you won't ever even really use, honestly, day to day. Yeah, we're kind of using a lot of off the shelf stuff that's already kind of optimized for us. When we use this template to make an app for an interview, Do we need to make it multiple additional pages? Oh, it depends on what you're trying to prove. Yeah, it depends on what you're trying to do. Should we learn SQL or is MongoDB enough? MongoDB is enough to get a job. You do not need to learn sequel but it it doesn't hurt yeah

09:02:00
yep I agree a hundred percent with my wolf it's not required it can be nice to have but don't spread yourself too thin during the hunt and I say this as a sequel to, yeah, I think time management is the key right now. If you have time outside of all the stuff that you have to do for the hunt, if all of your a hundred hours project is done, if your networking is done, if your hit list is done, if all the things that have a real measurable impact on your ability to get a job are done, and you still have time each day, then yeah, go, go wild. You want to learn more react, go learn more react. You want to go deeper with SQL, like you want to learn SQL, go learn SQL, right? Like it's up to you what you do with that extra time. What most people find is they have no extra time during the hunt. The hunt is all encompassing. It is consuming. And so what you do is you wait until you need to know

09:03:00
something to spend the weekend doing it. So you wind up getting an interview with the company that only uses Postgres. Well, guess what your job that weekend is, is to learn Postgres. And if you've done anything with us at 100 devs, is you've learned how to learn very quickly. We're gonna do a little Postgres together, but that won't be until technically after program. All right, so I think that's the only tricky bit here. Is there anything else that we should have added here that would have been helpful for you to know when you were looking at this model?

09:04:00
Yeah. And also remember your, if you're seeing it in job posts, that's because that's local to you, right? Like everybody's going to be applying in a, in a specific area first or global remote, and you have to take that into consideration for your hunt, right? There's no way that any program could ever teach you everything that you need for the hunt in your specific area. So if you're noticing, Hey, Leon, every single company in, I don't know, Boulder, Colorado uses Java. Well, guess what? You should take a weekend to learn, right? or if you're noticing every single company in Austin uses Ruby still,

09:05:00
well, guess what? You should be taking a weekend to at least learn the basics, build something small with, right? And so that's an important bit of what you need to make some time to do, just so that you can get enough in for those particular interviews. When making new features, does it easier to start with creating routes first or controllers first? It's up to you. It's a personal preference. I personally like thinking about my model first, and then I follow the entire path from The server JS to the routes to the controller But that that's just kind of the way I think about I like think about the data first and then Pull all the glue together to make it work Entire see where everyone uses global. Oh, no

09:06:00
the first So weird the first engineering book. I actually ever like read read was a Fortran book and I wish I had stayed with Fortran because like there's only so many people that really know it well and there are so many like government like applications and things like that that still use it and my one friend that knows Fortran makes more than my friend that works at Feng. It's wild. There's also like the kobold meme right now that like if you want to make a lot of money go learn kobold, but kobold is really weird. It's very different than a lot of other things I've ever seen. I don't know how transferable your skills would be afterwards, but apparently there's money in it. But I don't think I would chase that, that down. I think that'd be a,

09:07:00
it's just, it's just your, it's too narrow, right? Too narrow. Yeah, exactly, brash list. I liked that as a cobalt dev, the idea that jobs are hugely in demand is way overstated unless you can learn 30 years of experience. Exactly. Cobalt's like a, like a, from, from the, like the folks I know that do it, like a dark art. It's like, it's like all this stuff that you got to know that you kind of really only learned by like smashing your head against the keyboard for 30 years. There's no stack overflow. There's no, there's no tutorials, there's no books. Uh, it's just a bunch of people that have been doing it for forever. And so like, that's just not the path anyone should ever go down. So much easier to get a, a, a, a decent well-paying job,

09:08:00
uh, without, uh, investing in the dark arts. Yeah, cool. Cool. Let's go ahead and take a look at the rest of the stuff that's here. Anything else that would have been helpful for us to know in this area? You didn't pay to learn it? That's dope. Cool. I think I feel comfortable with this. Oh, we also have the user model. Do we have to mess with anything in this user model? Nah.

09:09:00
User model, we're just going to use over and over again just so we want users. We don't have to worry about anything in here. We're just kind of using it. It's kind of just boilerplate for us here. Yeah. I feel comfortable with that too. All right. So we have our model, we're in our post controller. We have a couple things here. We have like this get profile, which enables us to load the profile and get any posts for the logged in user. So we see this rec.user ID. I think it's important to put a note here that since we're using the REST API, we have, how are we able to get the rec.user? Let me, let me pose the question to chat. How, how are we only getting posts tied to the logged in user? Like, how is that working?

09:10:00
Yeah, because we have a session, right? Since we have a session and we have a logged in user, every single request. Yeah, I'm sorry, but I don't know why it deleted it with rec user ID. What's offensive about with rec user ID? I don't even know what nightmode Nightbot could have seen. Oh, it thought, sorry, it thought that rec.user.id was a domain, right? So .id, like it thinks that that's a domain name. Interesting. There you go. Um,

09:11:00
like a URL, exactly. Like a URL. All right. So, we have a session, and since we have a session, each request sends a user object along. So, since session is, since we have a session, since we have a session, each request contains the logged in users info. Cool. I like that. I think that'll be helpful

09:12:00
for folks to understand that they were grabbing the logged in users info, grabbing just the posts of the logged in user. Cool. And I'm also going to say here, sending post data from MongoDB and user data to EJS template. What if you want data from users that are not the logged in user, then you could just use their ID here. So if you want information on a specific user, you would do ID

09:13:00
and then that user's ID, which we'll probably see. We could see that later on. Cool. GetProfile, I think that makes sense. I think this is the big thing that folks need to know if they're using the template. In the session, each request contains the logged in user's info, rec.user. We can even put it like a note that says like, console.log rec.user to see, everything. Oh, I like that being there. Anything else about the get profile that we should add? Oh, that's interesting. Dot ID is the TLD for Indonesia.

09:14:00
That's pretty cool. Why does post not need a rec in front of it? Where at? You mean here? Because this is the result of what came back from this request here. So we're using the post model to go to our MongoDB and find all of the posts that are logged in user, and then all that data gets stored in post. And so post right here is actually tied to this variable here. Like these are linked. That's the variable that we're using.

09:15:00
All right, get feed, do we need to get feed anymore? No, we got rid of our get feed. because we could just, if we went to find all the posts, we could just get rid of that. I don't think we actually need to get feed to show how you would do this. It is nice to have the sort, but you can find that from the docs.

09:16:00
I'm just going to get rid of this for now. All right, get posts, find by ID, so now we can find by a specific ID. this ID is coming from the routes. So here we go. I'm gonna copy this so we can see it. ID parameter comes from the post routes. comment this out.

09:17:00
Example URL. Let's grab that. All right. ID would be equal to this value here. All right, so all I'm saying here is that the ID parameter that we're seeing here, the params ID, comes from the post routes. I'm showing the actual route, and I'm just showing an example of the URL where it's the six, three, whatever, the ID would be equal to that. So

09:18:00
that's what we're doing here with this post is we're just yoinking that ID. We're just yoinking this ID from the URL. Beautiful. And once again, we're passing that user information. But we already just declared that. She described it up there. We don't need to say it again. All right. Next, we have the create post. And the create post is coming from that post router. And we're going to keep this because it has all the Cloudinary stuff that we need. So all this right here is just stuff you'd have to get from the docs about how Cloudinary works. And then we're creating a, using the post model, we're creating a post that has everything we need for Cloudinary. And we have the URL that's coming back from Cloudinary and we have the public ID. So, I'm just going to put a little note here that says images

09:19:00
are stored, I'll say media because we might do something other than images. Media is stored on Cloudinary. The above request response with URL to media and the media ID that you will need when deleting content. Cool. You

09:20:00
Oh Cool. Hey, are you still streaming these days? How you been? Hope you're doing well. Hopefully give Jay a follow if you aren't already, y'all. Cool. Indifferent, what's going on? 23 months, that's wild. Hope you're doing well. Cool. So Moultrie, you can add MP4, MP3 acceptable types by Cloudinary and upload vids and music. Yeah, right now our

09:21:00
Cloudinary is restricting, like we're restricting the media that we're uploading, but we could change that. The hiatus is over in two weeks, let's go. Be sure to check it out. Yep, so if we look, the reason why right now our media is restricted to just images is because of our multi-middleware. So let's go ahead and take a look at our Moulter middleware. And you can see that we're restricting it right now. We're saying if it's not a PNG, a JPEG or a PNG, that you shouldn't be able to upload it. So one of the examples I gave is like, I tried uploading an SVG and it wouldn't work. So if you

09:22:00
want it to be other types of media, you just remove this check. Yeah. It won't work for like capitalization or anything like that. It's pretty, it's pretty explicit here. It has to be as we all lowercase. Yeah. So if you remove this part from cloudinary I mean from multer the multer middleware, then you can get around that if you wanted to I Think it's good to have some checks to make sure folks aren't uploading reckless stuff that maybe cloudinary might not support Oh

09:23:00
Let's finish looking at this Ministering cloudinary the above request response of the URL to the media and the media ID that you will need when deleting content If we don't have this ID and we go to try to delete something, just having the URL is not enough because then anyone could delete it. So we need the ID and a bunch of other fun stuff. Cool. Everything else is kind of just simple, you know, like rec.body that's always coming from, well, we don't body parse anymore, but we have these two lines of code that enable us to look at what's coming along with those requests. Cool. Let's take a look at like posts. Like posts is kind of pretty straightforward. We're going to find one post. We're going to increment the likes by one. Delete post. I kind of already did this last

09:24:00
super review. Find a post by ID, delete it from Cloudinary, delete the post from the DB, that's straightforward. Cool. Anything else that you would like in the post controller that we don't have? Like anything that we should have here that would help folks that are new to using the template? way to upload default photos. Oh, like when somebody creates a user, you could have a default. I do have, I have an example on my GitHub of this.

09:25:00
Let me look at my GitHub real quick. I think I already have that template built out. GitHub, profile, demo user profile images. Yeah, this is like mad old, but I do know I've coded this once before for somebody. Let's look at the RiverJS. Yeah, so I have like a profile image on my user schema Uh, and then probably checking

09:26:00
is sold. Yeah, there you go. So when you create the new user, you're also uploading like a, I just hard-coded an image, right? So you're not like uploading anything. I just have a default image that I put into the, into the user model. So instead of having like, I wouldn't serve it up probably by Cloudinary. I could just on Cloudinary's UI, I upload a default file, right? And then whenever I built out a new user, like a new user, here's my user model. Whenever I built out my new

09:27:00
user model, I could just have like that default, I could have like profile and then just like the link to that default image, like hard-coded, and that would work. And then you could have part of your profile, you could have part of your profile, the ability to like exact same setup we have for posts, but instead of it being a post, it's just modifying that uploaded image. So that's something that you could do. I don't think we necessarily need that for our template, but it's not super hard extension of what we already have here. Could you put the default image in public? That would also work. I would probably put it on Cloudinary just so we have the CDN working for us. Gravitors are always cool. They aren't saved as images, but are usually a hash of your username. You know what? I've used Gravitors forever. I didn't know that's exactly what they were doing. That's pretty cool. I forgot about them.

09:28:00
All right, so I think our post controller is set. Our post model we feel good about. User model we're not touching. Let's walk through the entire process here. Somebody wants to go to the profile. Or let's say somebody wants to see a post. So we have our post route here. We're linking to the post router. We go to the post router. Everything is nice and nicely commented. We have our get, which takes us to the post controller. Post controller is now nicely commented for each thing. We have our get post, which we now have some doc, like some doc here that says, all right, the ID comes from that post route that we were just on. Here's

09:29:00
what it looked like. Here's how we're actually grabbing the ID. And so that's what's happening here with this ID. I feel better if like you're coming back to this, it's like in a year that you now know like where the parameters were coming from. We did some comments on the Cloudinary. All right, I feel pretty good about this. Is there anything that we haven't, we haven't looked at the views yet. So let's just take a quick look at our views here. Just closing some stuff here so we don't get overwhelmed. All right, we look at our views, we have our partials, which are good to remember. So we're not redoing our header and all that stuff. We're not redoing our footer and all that stuff. And then we don't need the feed anymore because just make sure there's nothing in here that's like really helpful. Now, if we had the same thing in our profile.

09:30:00
Post, let's double check our profile real quick. Make sure that's the same thing. Yeah, post title. Cool. Yeah, no difference. We don't need the feed. Well, and that's the last remnant of that. All right. Everything else we already have. Index is part of our home routes. Login, posts, login we need, sign up we need. To do's EJS. What's that doing in here still? Oh, we still have to do's in here, that's hilarious. I love this though, this line of code right here with the ternary. I think this is so elegant. Because

09:31:00
what we did is we wanted each of the to do's to have a completed class or a not completed class so that it had to strike through or not to strike through. So I thought that was pretty cool. But yeah, we definitely don't need to do's. I told you, I reuse my templates. I ain't doing anything, I ain't doing that. I ain't kind of coding it raw every single time. So I reuse my templates, there you go. You can see it live. All right, anything else that we think that hasn't been commented or that we think that is extra that we don't need? Is there a big difference between AWS 3 and cloudinary? Not really. I just find cloudinary a little bit easier to use for beginners. I believe, I don't know if this is true. I think cloudinary uses S3 underneath the hood. It would make sense if they did.

09:32:00
Do we need a proc file? We need it right now if we want to put it on Heroku, but RIP, we won't need that for very much longer. Should this template be on our GitHub as private or public? That's up to you. Is AWS Azure worth learning for job interviews? No. Unless you're applying to Amazon, which we've had so many, it's so ridiculous. We've had so many people from this and last cohort that have gone to Amazon. It's pretty wild. Uh, so if you do know that you're interviewing there, you should definitely know it or if it, or if, um,

09:33:00
the role requires you to know, like some roles like that's the big deal of what they're doing. So you probably want to be at least familiar with the basics if that's like a big ask on their description, the job description. And if I said Cloudinary is now on their own servers that's huge that's so good to know. I really appreciate that actually like knowing that there's competition out there is wonderful. I love that they moved off. Do we need MongoDB in our package.json or just mongoose? Probably just mongoose for right now. Cool.

09:34:00
All right, I think we're good. Let's just do a quick run through of everything and then I think we'll take our break. And when we come back from break, we're gonna try to build something with this. We'll just kind of like pick an idea and try building using our template for that idea. So let's go ahead, server.js, looking fine. Readme is fine, we'll leave all the package stuff for now. Views look fine. Routes we went through, we just have our main and our post, which are both now well commented. Our public will stay public, we just kind of have our default CSS and default favicons and things in there. Node modules, of course. We just have our post and user model window. We won't touch any of the user models cause we always want people to have like login, stuff like that. Middleware, we have our off JS, which we're not going to touch. It's just handling our authentication. We didn't get rid of the guest stuff cause we don't have

09:35:00
guest scouts. We don't need that. Cloudinary, we're not going to, I mean, this is just the stuff from Cloudinary Docs so we can upload the Cloudinary. Molter, if we wanted to, you could remove like these checks, but I like having the checks in there so that folks know that you can check for specific stuff. And then controllers off home and post. Cloudinary still uses S3, however S3 by default isn't an optimized CDN. Okay, that makes sense. Okay. We'll get there. I'd be surprised if they didn't have big plans to eventually fully Hopped off Oh

09:36:00
I'm not sure what the theoretical limit is for Moulter. I think that's a problem that if you run into, you find a solution for it, right? Like, like, um, Oh, like you want to check the size. I'm okay with that. If somebody wants to sit there and upload a 20 gigabyte file, um, they can. Um, cause we're not really, I'm not really sanitizing anything right now. Um, this is, this is mainly for like your, your, your projects for kind of your hundred hours project or for your quick projects for demoing to different employers. These aren't like projects that would be out in the wild probably for real users to be

09:37:00
using every day. If so, you'd probably wanna spend time better sanitizing stuff, thinking about security a little bit more, but for the stuff that we're doing right now to just get a job, this is good enough. Yeah, definitely a good thing to think about. Indifference said there is a very quick way to do it. File size, max size. Exactly, yeah. So all this stuff, the reason why I use Molter, the reason why I use a lot of this stuff, like we're not building any of this off like our own. We're using all the off-shelf tools. So when you want to make changes to Molter, maybe you're noticing some bad actors or some things you care about, all of this is pretty easy just from the docs to change. The docs have all of the stuff that you would need to make those changes should you want to. Cool. All right. Let's, let's go ahead and save everything saved. I'm going to push this to GitHub, and then we will, yeah,

09:38:00
I'm gonna push this to GitHub, and then we will build something when we come back. So should I bother with a recruiter that hasn't reached out to me for a position for a few days? Yeah, people get busy. People get busy. You never know. I keep it like a month. Every other week, I keep them on the list. Yeah. I would be difficult to add limits to what some users can do. I was thinking of disabling posts from guests to keep my demo apps clean from potential employers. Yeah, I mean, nobody's gonna find your link unless you share it with them, right? It'd be very odd if somebody found your like, your hosted version of your app if you didn't share it with anyone. You could also limit the IP address

09:39:00
just on MongoDB side just to be sure. Yeah. All right. What's a, what's a simple app that you would, you'd want to see like, what's an app? Give me some app ideas, something, something simple though. Uber Eats, Tinder for dog playdates. Spider catalog, what was that? Only Leons, Instacart, Recipe Postings, I like Recipe App, Recipe App can be pretty good. Pet

09:40:00
playdates. Merch store. Reviews app. Travel reviews. Could be interesting. The Goodreads competitor. Calorie intake calculator. I like, a couple people said recipe app. I like recipe app. I think recipe app can be pretty good. Pretty simple. Let's kind of get something on the board here for a recipe app. So let's go ahead and I'm just gonna open up web whiteboard. All right, so we could probably have like, if we're going to do a recipe app, let's see, no, I don't need any of this. All right, so what would be a main, like a main,

09:41:00
like we have like our profile. I think our profile would just be easy. Our profile could be kind of information about us, like our info, and then our individual recipes that we've uploaded. All right. I'm just gonna kind of like, if I can just quickly prototype what we might be dealing with here. So, boom. Boom. And we'll just do two more. All right, so like our individual recipes, and then we could probably have like a place to put, like to enter our recipe. So enter recipe, I can't spell recipe to save my life.

09:42:00
Interesting, how do I spell recipe? All right, there we go. Enter recipe. It would just be like a form. And so we can just imagine having like a form for our recipe app here. Cool. I like that. And maybe some like profile info. We want it to. Cool. and then if we were to think through this, I think there's like two things I probably wouldn't be able to see like, maybe individual recipe, like an individual post for a recipe and then maybe like the ability to like save your recipes, like save recipes that you'd like. I think that

09:43:00
could be good. So maybe we'll have like individual recipes. I keep clicking that. Let's go ahead and, we have like individual recipes pages, and then maybe we have like a page that's Um, just like your saved recipes. Now just have like the recipes that you saved going down the page. Cool. All right. So like an individual recipe page and maybe have like, uh, a photo. Let's say like photo,

09:44:00
that's right. I did type F when I started to spell photo. It's all that live folks. A photo, you already know though, you only live once, the motto, YOLO, every day, every day. And then maybe we have like the name, like the name of the recipe. And then what else does the recipe need? name, ingredients, and directions. Right. Long rambling story. Oh man. People get so mad over that. Uh, don't

09:45:00
ever like there, there was somebody that made a, it was kind of like having a site that doesn't have those stories is one thing. Like, yeah, like maybe you want to create an application that doesn't have those, those stories and that's okay. But there was somebody that made an app that like would find recipe sites and remove the stories. So you could just like go and find all these recipes that removed all the long winded stories from it. There is like one group of folks you don't fuck with. And that's that's that's mommy bloggers don't ever fuck with mommy bloggers. And that person just just that just riled up the wrong people And just had their life ruined because they wanted to make a recipe website like just don't They got clapped up so quick And they didn't know what was coming

09:46:00
All right Um, so the, the thing, the thing is that like recipes aren't, um, they're not copyrightable, but the stories are, and there's also like an SEO angle to it as well. Also some people just want to share like that grandma's the one that inspired the recipe. I'm not going to go to those sites to get my recipes, but I'm not going to knock your hustle. Yeah, Color Me, that's who I'm talking about. That was, it was rough. TikTok has quick recipes now? We're all, it's over. It's over.

09:47:00
All right, so we have a profile where we can enter our recipes. Uh, we have an individual recipe page that'll have a photo, name, ingredients, directions, and then we'll have like a, like a saved, like our favorite recipes. Cool. I like this. It's a quick app idea of favorites, individual recipes, and a profile. So there are certain apps that, um, like if you think, if you like extrapolate what tick tock could become, I think that's like the long, the long form is like in China they have, they have WeChat, which you can do everything inside of WeChat. And I see Tik Tok slowly trying to become that in the U.S. Yeah, which I think is pretty interesting. Tik

09:48:00
Tok's about to be the new Google. They kind of already are. There was some article I was reading that there's like certain demographics of individuals typically that skew younger that straight up don't Google. they type what they're looking for into Tik Tok. Like that's it. Like they don't, they don't use Google anymore. They use Tik Tok to find it, which I thought was interesting. I tried it for a little while. I tried like, I tried like getting what I wanted through Tik Tok. It's not there for me yet, but I could see it. Like if you're looking for, I was looking at, I was looking for, I was at REI And this person had these like beautiful, like, like gold rims on their Subaru Forester that were clearly like off-roading rims. And I was like, what are those? Like, and I couldn't like, I didn't see like any like markings

09:49:00
and the person wasn't, I like hung around for way too long to see if they came outside. But like Googling that wouldn't have given me anything, but like TikTok wound up giving me slightly better results for what I was looking for because I could see the cars quicker like in the feed. I don't know. There's something there. Yeah. Anyway, let's see. We have our sorry for waxing on there. We have a portfolio. We have our individual recipes and we have of our favorites. Let's go ahead and build out kind of our collections here. So we have our users collection. So we don't need to build out the users collection. We're just gonna use what we have for our users. I don't need anything else for my users collection. So we'll just say that that's like the default user collection. Cool. But let's go ahead

09:50:00
and get a recipe collection probably, will probably be the next big thing. You might need to update users to have a favorites of some sort. Not sure how we'll do that, let's see, recipe. And on the recipe, let's go ahead and give ourselves nice little box here. All right. And our recipe collection would have inside of it, individual documents and each of those documents are going to have some important bits of information. We're going to go ahead and have, let me put this to an actual size. We're going to have IDs,

09:51:00
which are automatically created. it. And the IDs, we're going to have the image for the photo. We're probably going to need the Cloudinary ID, ID for the photo. Right, so that we can like delete images once we have them. We're gonna need a name of the recipe. We're going to need ingredients. And we're gonna need directions, cool. and what else do we need for our recipe? We're missing like one or two other things here, I think. Is this brownies 2.0? Yeah, we started off by building our brownie recipe

09:52:00
in HTML and now we're building a full stack recipe website. The user, like the user that posted it, right? Like the user who made the recipe. Cool, I like that. I think that's a good place to start. And then, of course, we would have a bunch of these. This is what each recipe would wind up looking like. Nice. Oh, did you see how that jumped to the right spot? That's wild. Once you know code, there are some things that you're just like, how did they do that? Like how did it know to jump there in a whiteboard? That's pretty cool. And then how could we do favorites? Like what's the way that we can, so this would give us the users by default. We have the recipe. How could we do favoriting?

09:53:00
Yeah, heart, but what are we doing for the favorites? We could store an array of recipe IDs in the user model. Oh, we could do that. Like a common ID from bub, like where we could like have like a favorites, a favorites collection.

09:54:00
Or we could just have a favorite it by, can we just keep it on the recipe? No, does it make sense to have it on the recipe or the user? Let's see, I'm seeing some folks saying user. Okay, so if we have it on the user, we could have kind of all of our default, right? We could also have like favorited

09:55:00
by, but then when we go to like our favorites, let's see, if we go to favorites and we see who the logged in user is, right? Let's think about this. So let's say like we went to local host, 2121 slash favorites. We get the logged in user's ID. Right, we get the logged in user's ID. With that ID, we could go two ways, right? Once we have the logged in user's ID, we could find that user and then

09:56:00
that user could have like an array of things that they have favorited which then we would go and find those individual recipes from the recipe array from the recipe collection or we have that logged in user and we could look through all the recipes where the favorited by included that user so you just like look through like the array of favorited users or we could have a collection of favorites, right? We have a collection of favorites where it's just a recipe ID and the person who favorited it. So that when we load this, we could go through the collection of favorites, grab the recipe ID, grab the recipe and put it

09:57:00
there. What do y'all What do you think might be the place to start here? Favorite collection, user ID, I think they're all worthwhile attempts is what you all want to do. Recipe user table with just IDs. Favorite collection. Oh, yeah, let's do a poll.

09:58:00
Manage poll. New poll. How should we add favorites? On user model. On recipe model. All right. There we go. So should we start a poll? Should we do it by adding something to the user? By adding an array to recipe? Or by creating a favorites collection? We're in a company meeting. Yeah, we are.

09:59:00
All right. I'm going to do whatever you say. So let's see how it goes. Got about 20 seconds left. All right, folks want to see it a favorites model with a new favorites collection. All right, let's try it. I, I think maybe the user model would have been easiest, but let's have some fun. Democracy.

10:00:00
Exactly. All right. So we'll have a favorites collection. Let's go and grab some text here Favorites and then Favorites how do we do this? Let's see Each favorite would have an ID that's randomly created. And then on

10:01:00
the ID, we would have like the user that did it. and we would have the recipe that it's tied to. Okay, and so when we load this favorites, what we'll do is we'll grab the logged in user's ID And we'll grab each recipe, we'll grab each recipe, I don't even do that, we grab each recipe that exists inside of the favorites. So we'd find where all of the IDs,

10:02:00
all the IDs that match, but specifically want the recipe from each. All right, we can make that work. Cool. Yep. all right let's let's try it let's build it out all right let's all right let's see where we go. All right. ID, user, recipe.

10:03:00
So with each favorite, so they'll click like a, let's see. We'll click like a heart or something and that heart will create a favorites document with the user and the current recipe. Cool, all right. I think we can start. I think we can start. So where do we start? Let's save the favorites till the end because that seems to be the more difficult piece here. I think this sounds to be the more difficult piece. So we'll do the profile and the individual recipes first. Feel good that we can start with our template, no problem. I'm gonna close this

10:04:00
one. And I'm just gonna make a copy real quick. I could just clone down, I guess, as well. Copy. I'm going to call this Recipes, a recipe app. I'm going to call this Recipe App, I'm going to open it real quick, I'm on the other screen. All right, here we go. So here's my copy of the template. I just renamed it recipe app. I should just clone down, I don't know why I did this. Let's go ahead and do, get rid of my git repo for right now. Ls-la, make sure it's there. Yep.

10:05:00
M-rf.git. Cool, all right. Okay, so we have our version of the template up and running. Let's make sure that it works. NPM start, since I made the copy, I don't have to worry about setting up my ENV. This should work. I probably need a new MongoDB in my ENV, which I think should be okay. Let's make sure it works real quick with everything that I have running, and then I'll get a new MongoDB connection string. So we're starting fresh. All right, we're connected. Looks good. I can probably just leave it the way it is. Nah, I'll start fresh. All right, let's make sure that we're running localhost 2121. Let's go ahead and log in. All right, everything's still working. All right, we're good. Let's log out

10:06:00
and let's go to MongoDB and let's go ahead and do new project. Recipe app. Yep. Create project. Let's give it a second. Build a database, heck yeah. Free. We'll do AWS. I'll do Oregon, so it's closer to me. Free. Let's do demo,

10:07:00
demo, create user, local environment, fill my VPN, add my current, finish and close. Close, cool. All right, it's gonna take a few seconds to deploy. And once it's done deploying, I should be able to grab the connect, connect your application. And here's my new string. Close. My secrets don't matter if I show them to you because you can't really do anything with them. So, I'm just going to go ahead and do this.

10:08:00
And I'm going to go ahead and do demo. Cool. And then I'm going to go Cloudinary real quick. Let me log in, let me log in, cool, and I'm going to bring up my fake face for a second And I'm going to... I should have done this. I don't know why I did it this way.

10:09:00
One second. Already still things that I don't want to show. Oh

10:10:00
Sorry, folks. One second. it. Just setting up some things on my end, be right back. You All right, almost done

10:11:00
All righty, there we go, coming back. I just wanted to go ahead and reset my cloudinary keys. Yeah. Yeah. I just wanted to separate, I wanted to redo my cloudinary keys just so that, um, since I shared them, they weren't still live. Cool. So everything should be, uh, disabled on cloudinary side, uh, and I should have all new keys so so that folks can't use my old ones. Should be good. All right. Let's take a look at our little demo here. All right. Sorry,

10:12:00
whiteboard. First thing we're gonna do is profile an individual photo. So let's go ahead and worry about photos first. So I'm going to change our post model to our photo model. Let's go ahead and change that from post to photo. Actually, let's make sure this all works with the new stuff first. So I have a new collection, like I have a new MongoDB and I have a new Cloudinary. So before we get into the weeds here, let's make sure everything still works. You notice that this is my theme. I always test before I sign up. Do test at test.com. Test at test.com. Test, test, test.

10:13:00
Cool. Let's make a post, testing, I'll test, testing, use a file, and do great haul, commit, all right. All right, cool. Everything's still here, everything still looks good, even with the new MongoDB, new Cloudinary, and that's it. All right. Cloudinary, all you do is you just log in, you set up your account and it gives you your secret and your like key. You need your key and your secret and you just plug those into the env file. I unfortunately can't share that part or else somebody will do

10:14:00
weird things while we're live. Cool. All right. So everything's still working. Let's go ahead and change our post to our, sorry, our post to our photos. I'm gonna start with the model. I think the model is the easiest to start with. I'm going to change this to photo schema. We're going to need a title. We're just going to call this name. We do need an image. We do need the Cloudinary ID. We need ingredients. And we don't need likes. You can keep likes. It doesn't hurt to have, not have legs. Uh, we need the user who made it and we also need

10:15:00
directions right now. I'm just keeping it simple on myself. I'm leaving it as a string. Could we get fancier? Yes. But for right now, you have name, image, ingredients, directions. Let's make a look at our photo here. Is there anything else that we're missing? Boom, boom, boom. Name, ingredients, directions, the user. Nope, we have everything. We kept the likes. Let's save this and we're gonna call this photo. Save it. We're gonna rename this to photo as well. Photo, great. And then you can automatically update imports. No, let's not do anything automatic. I want to walk through it together. So if we go back to our server JS, let's go ahead and do, we know that this, we're gonna rename all this

10:16:00
from post to photo. So it's gonna be our photo routes. Photo, photo, you already know though. Come down here, photo. Nice, so we'll go to our routes now. This should be renamed photo. Photos, cool. and we'll make our server.js. Photos. Cool. So photos, photos routes. We're gonna change this to our photos controller. We'll change this to photos. Cool. And then each of these

10:17:00
will be photos as well. So, boom, boom, boom, boom. Photos, that's good, photos, photos. Controllers, we'll call this photos. Cool, photos. No. All right, so we went from our server.js. We're requiring the photos route. Our photos is now photos. We have a photo model. Cool, let's go to our routes photos. We're calling the photos controller. That looks good, everything is renamed to photos. And then we go to our controller. And it's no longer called post.

10:18:00
It's called photo. Cool. Photo. And then anywhere we have posts, we're gonna have to rename this to photos. So photos. Photo, we could do like find and replace, but I'm kind of just, I think this is a chance to show you each place that we had used the model. And it's gonna be photos, the name of the model, not photos. Cool, photo, photo, photo, photo, cool photo. And then down here, last one, photo, and photo remove.

10:19:00
Destroy photo. Alrighty. Why am I saying photo? Why did I change it to all the photo? Why did I get stuck in my head? All right, let's change this. It was just, it's just to get the repetition in just to get the repetition in meant to Do it. Really, cause I can't spell recipe. No. All right, recipe.

10:20:00
Let's do it again. Server.js. You got got. I did. Recipe routes. Recipes come down here. Recipe routes, we're going to call this recipe. That's recipe, recipe routes, recipe routes. We call this recipe, recipe routes, recipe routes, recipe, recipe, recipe routes. Let's call our routes here. Let's rename this recipe, and then down here,

10:21:00
we'll call this recipe, recipes, cool, I have change the model too. I'll go back to it. Boom. Boom. Once again, we could just do control find or replace all, but I think it's better to see all the places where this stuff gets touched. Recipes controller. We're linking the recipes controller. What happened here with the middleware? Oh, I had a REPL somewhere else, too. Boom, boom. So what happened there is I had accidentally already clicked somewhere else, and so I have to just fix this up. Recipes, beautiful.

10:22:00
All right, so we have a recipes controller everywhere. We have calling the right controller, recipes, recipes, recipes, the model, we're gonna change this to recipe. Recipe schema. call this recipe pool for JS 2. All right. So, we require recipes. We have the correct path recipes. Our route has the recipes controller. We're using the recipes controller. We gotta change our controller to recipes. Let's rename. Recipe

10:23:00
controller. Our routes. Call it recipe. Boom. Recipes controller uses recipe. We have the controller named recipe. Recipe controller. And then what we're going to do is just no longer stop photo. Why did I say photo? That's so weird. Recipe, models, recipe, cool. Then each one of these will be recipe. Boom. All right. And then of course we're going to have to come in here and like fix like these internal variables, like called posts and stuff, but that's actually not a problem at the moment. Recipe. Liking the recipe.

10:24:00
Eventually like we'll change our routes and stuff, but we're not there yet. Recipe. This photo dot Cloudinary ID, recipe dot Cloudinary ID, and this will wind up being, let's see, recipe as well. Cool. All right, so we have all the recipes switched out. Did we update the schema? We're gonna step through it. I just did a quick pass

10:25:00
and then we're gonna keep going through it. This is exactly what I do. If I'm building out my 10, my 10 like premium app, this is exactly what I'm doing the entire way through. All right, start server.js. We have our recipe routes. Boom, routes, recipe. We have, let's make sure we're calling it down here. Anything that has slash recipe in it, we use the recipe routes. Recipe routes is calling the recipe router. Recipe router looks good. It has the recipe controller. We renamed our controller to recipe, so that looks good. Recipe's controller looks good. Recipe controller looks good. We're gonna have to change like these get post, create post, all that stuff, but we don't need to change the names right now. Recipe controller, recipe controller. Recipe controller for like post, it looks good. Recipe controller for delete post, that looks good. Our controller uses

10:26:00
the recipe model. We're awaiting recipe now because we're using the recipe model, no longer the post or whatever. I called it photo for some reason. Recipe, recipe, cool recipe, and recipe. Looks good. Models, let's check the model. Recipe schema. And we're gonna call this recipe schema. Cool. Yeah, we're going to have to change the names of the actual methods in the controller, but there's no, we could still call it, there's nothing that's

10:27:00
broken about calling it post there for some reason. I'm just making sure that all the routes and all the models are correctly named. Cool. Let's look in here. Green instruction likes user. Looks good. All right, let's see what errors we're getting. All right, controllers post routes server JS is looking for a post controller. I'm going to stop real quick and just let NodeMon chill. And let's start again. Let's see what happens. All right, here we go. Cannot find module controllers posts. So we're looking in the main routes. Let's go and take a look at the main routes.

10:28:00
The main routes is looking for that post controller, because that's what it's going to use for profile. But this is recipe controller now. Recipes controller. And it's going to be recipe. Cool, this would be recipes controller. Cool, that should solve that problem there. Let's see what else we got going on. All right, so it looks like that fixed all the, It looks like we fixed all of the bugs that are happening. Let's see if our app works now still. Well, we did change the model. So what wouldn't work here? As we update the model here, we're gonna need like ingredients

10:29:00
and directions for this to work. So where would we, where would we first add the ingredients and the directions that's going to come from, right? This is going to need new looks. Hey, with the raid coming through, hope y'all are doing well. Thanks for coming through. We are deep in our backend super review. This has been three Sundays in the making, 10 plus hours now, so we built out a template that we can use and now we are continuing to use this template to build out a new application. Chat decided to build a recipe app, so we're kind of just going through and making some quick changes to see how quickly we can make this recipe app using the template. Hope you all are doing well. Thanks for swinging through. Hope your stream went well. What are

10:30:00
y'all up to? What are y'all working on? Hope you had some fun. All right, we're deep in it. We're about to take a break. That's awesome, Sudo. Hope you're doing well. Pairing for the release of the trailer tomorrow. Hey, that's awesome. Congrats. You like sharing on Twitter and stuff, I'll retweet it for sure. That's dope. Congratulations. Big deal. Release of the trailer. All right, let's go. That's pretty cool. I'm sure y'all know, but I'm gonna share it again.

10:31:00
I'll just grab the URL here, my shout out command never works for some reason, if they're alive and I'm not live, I'm probably lurking in that stream. I always have it on the background while I'm working and I'm doing stuff like this and I'm just kind of plugging it along. I like to not be by myself and so I always have their stream up because it's chill They're inspiring because they're also working hard on stuff. And so definitely give them a follow if you're not already All right, so we do need to add this direction and Ingredients and that's gonna come from where we're where we need to include ingredients and directions Like where is that gonna come from? Like the users we have are making posts before, but where are we going to include ingredients and directions? If we're just going to do it like real quick. Yeah, the form and that form is

10:32:00
on our profile view. So let's go to our profile view real quick. Here we have a post and we have a label for a title, caption. And so we'll change this from caption to, well, this should be name, right? We'll change this to name and input type text, title ID, name, the name property is what matters here. So we're going to call that name and this won't be caption, this will be ingredients. and the name on this won't be caption. There'll be ingredients. And then we need one more of these before we get to the image. And so I'm just going to copy this here and I'm going to change this to directions.

10:33:00
And this will be directions, directions, and we'll change this to directions. Cool. Now, if there is now ingredients, and we should change this from caption to like ingredients, and this should be directions. Remember the name property is what matters. The name property is what matters when we're grabbing something from the form, right? So if we don't grab it directly from the, if we don't change the name property, we can actually grab that value out. Yeah. Yeah, I definitely wouldn't be typing along. This is more like trying to figure out how we're doing it. All right. Cause I'll share all my code on, on GitHub too. If you want to try typing along, that's okay. But I'll share everything on GitHub after. All right. So

10:34:00
we have ingredients, we have directions. Is there anything else that we were missing? Instruction and the name, we changed the name as well. So name, ingredients, directions. When we submit this form, we're making, oh, change the label too. Good call. Label for name, and that matches the ID. Boom. For Ingredients, and that matches the ID. And then for directions, and that matches the ID. All right, so now our form has it. When we submit, we're taking what type, when we submit

10:35:00
this form, what type of requests are we making? making a POST request. And if we look at this form, we need to change the action. So I'm going to change this action to recipe. And this is going to be create recipe. So this is going to be a request to the recipe route. So if we follow the whole thing server, it'll be a request on the recipe route. We're gonna go to our recipe router. Recipe router is gonna have a post and we're gonna call this create recipe. Cool. And so we'll use the recipe controller and we'll call the method not create post

10:36:00
anymore, but create recipe. All right, so it went from, it was used to be called post, We're going to call it recipe now. So we're in the right, we're in the right router. We are connecting to the right action because we said the action is going to be recipe, create recipe. If we look at the route, create recipe, we're going to use the recipes controller and we're going to do create recipes. So let's go to our recipe controller. Get profile, get posts, create posts. I'm going to call this create recipe. We'll create recipe. Beautiful. Cloudinary should still work. We're going to change this because it should be named now to match our model. Name, and we're going to grab it from the form. We changed title to name in the form. We have image, we have cloudinary. Caption is no longer caption. We're going to call this ingredients.

10:37:00
And from the rec.body, it was ingredients. Cool. Then we also need this again for directions. Cool, directions. Cool. All right, that looks like that should be working. And we have a problem here. Let's see what the error is. We messed up something in, we just did, let's see. Let's go back,

10:38:00
ingredients, boom, directions, directions, boom, looks good. create recipe using the recipe model. Oh, we didn't save this yet. Save that. Create recipe. Recipe's controller. Create recipe. And we still have a post somewhere. Right? So, post method. Boom. Recipe's controller. Create recipe. Recipe controller. Great recipe, recipe create looks good, looks good. And that fixed it. Yep, it was just that the route was wrong. Cool. So right now, if we were to run this, we probably should be able to make a recipe, but

10:39:00
what would be the main error? What would we run into? Like we should be able to create a recipe. They'll probably get saved to our MongoDB, but what would we run into very quickly? What would we run into? There's one last thing that we haven't done. Yeah, we'll never see it, Coconut Director. Cause we have to fix that profile view. So let's take a look at the profile view because we already have it open. Instead of it being, where do we view the post that was usually here? So instead of it being like posts that we were putting in here, it's gonna be recipes now. So we'll call this like recipe pool. And this will be recipes pool. And this would be recipes.name.

10:40:00
Cool, the image. And then for the directions, let's just put a paragraph here and then directions, we'll just do a paragraph. Eventually we'll probably do, thank you for the extra S. Eventually we'll probably do like some sort of list or something, but for right now let's just do a paragraph. And we're just gonna yoink this. And it won't be name, it'll be ingredients. And it won't be name, it'll be directions. Cool, now we should be able to show everything in the DOM. We'll have the name, we'll have the ingredients, we'll have the directions, but we still haven't gotten, and we still haven't gotten the get

10:41:00
requests. So let's take a break because people are getting ads. I will take our break. When we come back from our break, we'll kind of finish up this last little piece here. Hey, Leon, do I make myself look like a complete, I don't know what that word means, by saying I'm a Mern stack developer at meetups. As recruiter replied, I've never heard of it before. I thought it was down with the lingo. I mean, I don't know if I'd call myself a Mern stack. I just say I'm a like I'm a full-stack developer. I'm a software engineer and they asked me what I focus on I use the MIRN stack which is Explain what that is. But no, I mean if you're talking to recruiters remember recruiters don't always code Or like most of them don't most of them have no idea what different things are except for the things that they recruit for Is if you're talking to recruiters, they might not have any idea what MIRN is but I would say most developers probably would at this point but Yeah, there's no reason, there's no reason to expect everyone stays on top of all this different stuff.

10:42:00
Cool. All right. So we were just finishing up this last bit here so that we could actually see our recipes. We're changing the path here so that when we eventually build individual recipe pages, it's already there. We're pulling the name in for the recipe. We're keeping the images there. We have the ingredients. We have the directions. And if there's one other thing that we said we were going to change, recipe recipes, recipe name, recipe image, recipe ingredients, recipe directions, ah, recipes.length, there we go. Because eventually we're going to pass in recipes into this EJS template.

10:43:00
and so we need to loop through how many recipes that we have. Cool, so now we should be able to loop through the total number of recipes. And everything looks good here. All right, so let's save this. For this to work, we're going to need the get request in our recipe controller to work. And so let's take a look at our get request here. The get profile, because that's where we're at. We'll call this recipes no longer post recipes. We're going to find all the recipes tied to that user and we won't call it post, we'll call it recipes. And we're going to grab the recipes from the request here. Cool. And we still want the logged in user info. So that can all stay. This all looks good to me. Yeah, I think we're ready to try running this. I'm just going to get rid of

10:44:00
the stuff that's in... Let me just check my database here, the MongoDB. All right, so we do have posts, which we'll just ignore. So that doesn't matter, won't mess anything up because the new one should be recipes going forward. All right, let's go ahead and... Let's go ahead and see how this goes. What about multiple people that have the same recipe? In this case, each recipe would be tied to a specific user. So they could have the same recipe, but it would just have duplicates in the database, but each duplicate would be tied to an individual user. There's also nothing stopping right now from each user uploading the same recipe a bazillion times, but those are all things that you could solve later on. and I don't think we need to worry about edge cases like that right now.

10:45:00
All right, I feel good about that, looks good. All right, let's test it and see what errors we get. All right, I already have one running, sorry. Let's close that, let's close that. All right, npm start. All right, server looks like it's running. Let's go catch it. Go to localhost 2121. Let's go to binary upload, boom. Let's log in. Already logged in. Let's try making a post. Name will be

10:46:00
Hat, ingredients, uh, cotton and magic, directions, uh, say the magic words. All right. And we're, well, we'll name it sorting hat. Choose file. All right, open, and let's see if we get any errors. All right, so we didn't get any errors. You can see that we have the sorting hat that pops up. We have the ingredients and we have the directions. So I'm gonna count that as our first try, right, first try. So it is showing our recipes now on our profile. And it has the name of

10:47:00
the recipe, the photo of the recipe, the ingredients and the directions. It's also have an anchor tag right now. That's why it's doing like the blue underline. But we can fix that later. So I don't think it's something we have to stress about right now. The problem though is if we click on it. Oh, actually it's pretty solid. Took us to the recipe page, right? Like we have recipe and then the actual idea of the recipe The likes are still there Um, i'm actually was i was expecting something at the break. Let's take a look at the individual get Get post. I guess there's nothing really that's odd there for the get post meaning that um We call it post ejs right and all that stuff, but that's still all works So there's nothing too broken about that. That's actually pretty cool. So let's focus on that. Let's get the individual posts working. Make sure we have the ingredients and the recipe, the ingredients and

10:48:00
the directions on there. And let's start with the route. So we have our get for the individual posts. We're gonna use the recipe controller. We're gonna change this from get post to get recipe. Cool, get recipe. Let's go to our recipe controller, get recipe. Cool. We're gonna call this recipe. And we're gonna pass it in as recipe and recipe. And we're gonna call this EJS file recipe EJS. We have to come over here and change this, rename it to Recipe EJS. So basically we're just trying to build that individual recipe page now. We have the portfolio working, the portfolio, yeah, the profile working. We're

10:49:00
gonna be able to load individual pages or individual recipes. So we change our get, which grabs the ID. We call the recipes controller. We're gonna change this to get recipe. We're gonna grab the individual recipe based on its ID, pass that to a recipe EJS. Let's take a look at our recipe EJS. We have to change this from post to recipe. Boom, recipe.image. We don't have to worry about like a for loop or anything here because it's just one recipe. And then we'll change the, we have the liking here. Um, eventually if you want to have likes on the recipe, we would have to change this anyway. So we can just go ahead and change that for now. Like recipe. We haven't modified the, um. We haven't modified the like

10:50:00
on the controller though. So something to keep in mind that it won't work initially. Number of likes would be recipe.likes, cool. And then if recipe.user equals user ID. So we're seeing if the person looking at the recipe, if it's their recipe, then they'll have this delete button that shows up. But if it's not their recipe, then it won't show up. P delete recipe and recipe.id. I'm just changing this all to recipe, looks good. And then down here, we have the post caption, but we'll call this recipe ingredients. And then we'll have another one. We'll just call for the

10:51:00
directions. cool. Let's save all this and let's see where we're at. Let's see if we get any errors or or anything like that. Let's try reloading this page. All right. So we have the image, we have the ingredients, and we have the directions all there. The likes and the deleting won't work until we update the controller. But for now, it looks good. You have the individual post pages. is, uh, we have our port full, so I can say our profile,

10:52:00
that's working profile has the ingredients, it has the directions. I would say for right now, this kind of satisfies the basics of what we're looking for. Uh, let's clean up the likes and let's clean up the deleting just because that's an easy change, right? A couple of easy changes and we should be good. So if we go to our routes, likes, so we'll say like recipe. It's using the recipe controller and we'll call this like recipe. Cool, and the same thing with deleting, we'll call this delete recipe and recipes controller, delete recipe. Cool, so that router is all set up. Let's go to our controller. Like recipe, we'll change this to a recipe. We're already have it set up, changing the likes. And then we're just going to change the redirect back to recipe because that's where we're at already.

10:53:00
And then delete recipe as well. Cool. Recipe find by ID. That looks good. Recipe cloudinary, recipe remove. and it's back to the profile. We'll just change this deleted recipe. Cool. So I think that's everything. Let's try this out. Let's refresh. Let's click on it. Likes worked. It's our posts. We're the logged in user. So we should be able to delete it. All right, so I think as of right now using the template in under an hour we were able to switch this from a site that was

10:54:00
about making social media posts to a site that was about submitting recipes, right? And that's pretty quick. Like an hour, it gets all the basics. We could spend a lot of time with like the formatting. Now it's just the formatting, right? Like we can come into the profile EJS and say like how we want this to look or to feel. We could go into the recipe EJS and say, all right, well, I actually want to figure out how this looks and fields, we could figure out maybe that instead of it being just an input where they put the recipe in directions, maybe there's something more fancy there that enables it to make it look more like a recipe. Maybe somehow on your recipe EJS, you're taking that paragraph and using some maybe client side JavaScript to like format it somehow. But that's all stuff that you could figure out

10:55:00
like over your period of time. Like if this is the project you're trying to build, like it's pretty easy to go through and like, well not easy, but it'll just take some time, but that's not the meat and potatoes, right? So now we have kind of the core switched over. We went from our social media app to a recipe app. All of the big pieces are fixed. Now you can start adding stuff that you want to add and so you want it to add Favorites and we wanted to do it with a favorites collection Which is probably not the easiest thing in the world, but let's think through it All right, so we probably want to add a favorites button. So we should do that first. Let's go ahead and do it Let's let's add the favorites button Uh, and that would probably be on the individual recipes themselves. We don't have a feed for recipes, which is where I guess you would see all

10:56:00
the recipes. Um, but let's just pretend that you have like, I don't know, individual recipe pages that you got to somehow without going to your profile. Uh, and so on these individual recipe pages, you already have like a like button. So we could just kind of yoink this. And change this into a favorites. So we could say like favorite recipe and we can make it, well the legs are already a heart. What's another font awesome thing that we could do? That's not a heart. Well, maybe we change the, the, oh

10:57:00
star. Yeah. Is star one? I'm sure star is one, but let's just check. Yeah, of course. F-A-S-T-A-R, cool. All right, so let's come back here. F-A-S-T-A-R, cool, and that should work. Since it's a recipe route, we go to recipe routes. Instead of it being a like, it will be a favorite. And we'll go to recipe controller and we'll say favorite recipe

10:58:00
I guess it shouldn't be a put, it should technically be a post, which is ridiculous. All right. Let's make this a post actually. Nevermind. Let me delete this real quick. eat. This will be a post. We're doing it for funsies. Okay. Post. Favorite recipe. We don't We don't need any of the upload stuff though. Cool. And so let's go back to our profile EJS. Or sorry, our recipe EJS. And

10:59:00
we don't need to have the method override. Cool. Recipe, favorite recipe, let's take a look at the recipe controller real quick. So the create recipe is grabbing stuff from the rec.body. So we don't need anything like in the ID necessarily when we're submitting this stuff, right? We don't need it in the URL or anything like that. We can just take it from the body. Let's go ahead and take a look.

11:00:00
All right, so here would be our form, we're submitting a post, what do we want to do with that though. As we're doing this in a really funky way, I'm just thinking through a little bit here. All right. All right, so we have a post. We're gonna send that through. You're not going to pull anything from the form, though, because we don't have anything in it. What did we need? What did we say we wanted to send? The ID, which will be automatically created, a user and a recipe ID.

11:01:00
Maybe we treat it the same as the method override, but we just keep it as a post. Um, yeah, I think that makes sense. Either rest because that we can get the logged in user just based on who's logged in. And we want to be able to grab the, um, we're gonna be able to grab the action. So maybe we can just do it off the action. I mean, we don't need to do anything fancy. I'm just gonna plug in with the action. Yeah, with the action, we'll do that. All right, so favorite. We're gonna have that favorite. Recipe ID is

11:02:00
already there. It's still a post. That looks fine. This should still work. We're gonna paste in the ID. We're gonna need to grab that. Yeah. Okay. Let's take a look at our, look at our routes here. We're going to have a post, but we're also going to have on the post, the, um, the ID as well. Like the recipe ID, this should still work. Should be able to still be able to favorite it. We should still be able to have the ID, right? Time for a revote. No, no. We have the ID, we have the post, we have the ID. All right, we should do this. To our controller. So instead of a create recipe, we're gonna favorite recipe.

11:03:00
Let's just copy this whole thing. Boom. Um, favorite recipe, favorite recipe. We don't need any of the cloudinary stuff. Um, boom, we're going to do favorite dot create. Oh, did we even create our model yet? No, we haven't created our model yet, have we? Favorite judges. So we're gonna have, we're gonna use a favorite model and then just real quick while we're here, the favorite will have the ID. We don't need that, that it's auto magic. We know we're going to need a, what did we say one more time? User

11:04:00
and a recipe. So user will be rec.user.id. So just like the logged in user, yep, rec user ID, that looks fine, rec user ID. and then we're going to need the recipe, which we should be able to get off the parameters. We should be able to say, connect.params.id. All right, so let me walk you through my thought process here. We're going to have a post. That's going to call create, well, it's going to call favorite recipe.

11:05:00
Well, and what we're going to want to do is grab the ID. Cause if we look at our, our actual action is recipe, favorite recipe, and then the ideas here. we're gonna be able to yoink that ID. If we look at our routes, favorite recipe, ID, so we should be able to grab this. Inside of our controller, we're grabbing the logged in user and we're grabbing the ID from the parameter. We don't need any of this other stuff here. And then we wanna redirect back to recipe and we want to do the whatever the recipe ID that we're in. So it'll be, let's just go ahead and do a template literal here. And

11:06:00
we'll do rec.params.id. So the idea here is that I'm getting this ID out of the URL, and this is from the logged in user. And that's gonna be the two things that we said we wanted in this favorites collection. All right. I think this should work now we just need our model. So if we look at our model, you have a recipe model. I think we should just copy this. Cool. and we'll go ahead and create a new file. And we'll call this favorite.js. And this, we'll

11:07:00
call this favorite schema. We know we're gonna have a name. So we're just gonna have user and, Oh, I keep forgetting, user and recipe. So user, we already have down here. And get rid of everything else. We're just gonna call this recipe. Cool. Well, I'm going to check on my little one real quick. Be right back. One second. Yeah, I hear a little one crying a little bit. So I'm going to, let's put three minutes on the clock. I'll be right back. Alrighty, alrighty. Let's quickly get through this last bit here and then we'll

11:08:00
call it. So we'll probably go, what have we been going for? We started at two, so we'll go until like six. That's like four hours. Let's see if we can get this done within the hour. Alrighty. So we have recipe, we have user, and we can just leave created at, that doesn't, ah, we don't need it. Eh, we'll leave it, it doesn't matter. All right, so favorite schema, favorite, and we'll call this favorite. Alrighty. Favorite, favorite schema, favorite schema. Let's look in our recipe controller. We're

11:09:00
gonna need favorite now as well. Cool. All right, so we should have everything now. Let's see. Favorite, favorite. We should be able to store the favorite in the great recipe, favorite recipe, should be creating a favorite there. So let's just save this and see if it works. All right, let's add a post. Pat, ingredients, magic, directions, say the words.

11:10:00
Oh yeah, we got to change the reference as well, the call. No, user's fine. Oh yeah, we want to use this based off of a recipe, right? So we'll say, boom. Boom and we'll change this to ref Recipe Good call. Thank you All right. Look at this controller one last time favorite recipe recipe Cool, user looks good. Let's go ahead and try to see if this works.

11:11:00
Did I restart server? Restart, restarted. Beautiful, let's refresh. All right, let's do a name here. Pat, ingredients of magic. Directions say the magic words. Beautiful. Let's choose the hat photo again. Submit. We have a lovely hat. We can go to the hat page. We have the star. All right. So we did something there. All right, let's look real quick in the, we knew we wouldn't, did we redirect well? Let's see. Params ID. Should have taken us back the recipe route, but let's see what happened in the MongoDB.

11:12:00
Did anything happen there? Let's refresh. Oh, it's in the views. Like I put something weird in the views It's gonna take a look I'm sorry to be in the recipe reviews. Let's see Oh, I didn't close the quotes. Good eyes. Good eyes.

11:13:00
I love it. I didn't close the quotes beautiful. And that's why we had all this extra spacing here. That's hilarious. Yes, I love that. All right, let's go back and refresh our page and try again. All right, so we got redirected back to the right spot, but did it do anything for us? Post was triggered, post has been added. So that means that if we look at our controller, this says, this actually ran, right? The favorite recipe ran, post has been added, but we need to change this to favorite has been added. Well, favorite has been added. If we look at our MongoDB, look at our MongoDB and we refresh,

11:14:00
we should have a favorites collection, we do. and our favorites collection has the user that made the post, the recipe, the object that like the idea of the recipe and when it was created, cool. All right, so now we have the big three that we said we wanted to start off with. We have all of our recipes working. We have favorites working. The last thing we need to do is have like a favorites route. Let's take a look. We can just have like a normal get. Recipe. We can just do recipe and we'll just say, slash favorites. And we'll just say, slash

11:15:00
favorites. We'll make sure they're still logged in because we're gonna need that. We really wanna show their favorites, so we're gonna make sure they're stayed logged in. And we'll say, get favorites. Cool. Get favorites. Uh, favorites, get favorites, and maybe this should be on the main routes. Actually I think this should be on the main routes, yeah. Let's take this back. This is not like a recipe, it could be a recipe route. Yeah, I'm going to say it's a main route, you could, you could, you could put it wherever you want, but I'm going to say main just to also just show something else somewhere else. Let's go to our main routes and let's do,

11:16:00
cause I don't want it to be like slash recipe recipe slash favorites is gonna be slash favorites. Recipes controller, yep. Recipes controller, get favorites. We, however, don't have a get favorites inside of our recipes controller. Let's go ahead and do, we have like our get recipe. We have our get profile. Let's probably more close to get profile than it is anything else. Let's copy that. We could also add favorites on your profile. Yep. That could work. Like just have like a favorite section. We could also make a favorites controller

11:17:00
down the line too. But we're trying to do this a little bit faster. Get favorites. Get favorites. And, all right. Now the weird stuff starts. We need a favorites EJS. Cool. All right, so let's just check our routes real quick. We can go to slash favorites. We'll make sure we're logged in. We're going to run the get favorites method. Get favorites. We're going to eventually run our favorites EJS. So let's, let's copy, maybe copy the profile EJS and do a new file.

11:18:00
Favorites.ejs, let's paste the profile in here. Let's just get rid of all the stuff that we don't need. Username, email, we can keep that. We don't want any way to like add posts, we don't need that. Cool. He's gonna be able to see the recipes. This is probably the only piece that we actually need. Don't need return to feed. We'll just leave it for now. We can get rid of it later. All right, so this is the only thing that we're gonna actually need, like where we put the recipes. So I'm cool with that for now. All right, if we go back to our recipe controller, get favorites, now this is the hard part.

11:19:00
The hard part is we have the logged in user and we have this favorites collection. Um, so let's go, what could we do? You can get favorites, right? We go to the favorites, right? and find all the favorites where user matches the logged in user. And for right now, I just want to console log favorites real quick. Yeah, we could do that. We could use populate, right? Let's do this in a quick step real quick, just so folks, let's just do it. So we

11:20:00
could do find, and then we'll populate recipe. Let me see if this will work. Boom, boom, boom, boom, boom, boom, boom. I should forget, is it just recipe like that? Let's see. Let's go ahead and use mongoose. Populate. Oh, I always forget the syntax, bump, bump, bump, bump. No. Oh, it's just a string, that's always weird. All right, string, recipe. And let's go ahead and console.log favorites real quick just so we can see

11:21:00
it. Cool. And we favorite that fine, good call. We'll worry about this in a second down here for the EJS. I just want to see if loading the page does anything in our console log. Once it works, I'll explain how it's working. All right, let's refresh real quick. The favorites. You shouldn't see anything yet. All right. Let's see if we got anything in our console. All right, beautiful. So we have an array here and that array has one object in it, right? This

11:22:00
array, right, has one object in it. Remember, we only favored it one thing, right? So populate enables us to grab the information. Oh, why did I close that? It enables us to grab the information coming from the recipes array. So it's kind of like doing what would be very, very fancy in like SQL or something like that is very easy when you're using Mongoose. So we were able to find all of our users. Oh, sorry, we were able to find all the favorites where it matched the logged in user. And then we were able just to grab the recipe values. So instead of having to look another query to the recipes collection, we can just populate all that data from recipes just by saying populate recipe. Yep.

11:23:00
Instead of doing like two queries, we can just use populate and it grabs all the data for us. And so we saw that it was correct. It had the one thing that we favorited in it, so we know that it's working. And we can just go ahead and do favorites.ejs. We'll pass in, what did we call it? One quick thing. We did call them recipes, because I guess they are still recipes technically. So let's go back to our controller. We'll still call this recipes, just to not have to do anything weird. Cool, so it'll be recipes. We'll pass in recipes, we'll pass in the logged in user. If we look at this favorites EJS, we're still using the recipes. All right,

11:24:00
this should work. Let's go back to our profile. We have our hat. Let's add one that we haven't done. Great hall, stone, magic, directions, say the words, cool. We'll upload Great Hall and submit. All right, so now we have two different posts. We have Hat, we have Great Hall. We know that we favorited Hat already. If we go ahead and do Favorites. Am I passing everything correctly? Let's see. Oh, it's not, is it still running? Let's see. What else did I get? Did

11:25:00
I not save, maybe? Let's see. That's our controller. Recipes. Let's see, boom, boom. All right, let's restart, refresh this page. All right, let's walk through it. Favorites, we have our main routes. Oh, do I not have my route yet? I know it's a main route. So main routes, let's see, if we go to server.js, main route, since it's slash favorites, it would be triggered by main routes. Main routes calls favorites. We use

11:26:00
the recipe controller, which looks good. Recipe controller would be get favorites, looks good. Favorite we find. We find the recipe. And we pass that through recipes, recipes. And let's see, I might be, I might need a different name here. Yeah, I think cause it's using the populate. Let me just console log it real quick. Cool. And then let's look at the favorites real quick. Recipes, recipes,

11:27:00
recipes, recipes, that looks good. Let's see. Yep. Let's just console log real quick so we can see it and everybody can see what I'm thinking here. All right. It should be console log, so let's just go and refresh this page. All right, and let's take a look at our console log. All right, so if we look, look at how this console log is set up. All right, it's a little bit different than what we would normally be seeing. We have the recipe, which is one level deeper, right? So see like how, So, see how it has like the ID and the user first, and then the thing that we're actually looking for is one level deeper with the recipe. And so we get out to use that. So it'd be dot recipe.

11:28:00
So, we go back to our controller. It's not actually recipes that we wanna use. We wanna do recipes dot recipe. And bring that back up just so folks can see it. I'll leave it here. All right. Let's save. We did. We already have a bunch of them running. Cool. All right. We're running already. Let's refresh and recipes. Let's see. Oh, we don't have to do it that way. Actually. Yeah. My bad. Let's go back real quick. I don't know why I did it that

11:29:00
way. Let's still send recipes like normal. That makes the most sense. And then in the EJS, we we will do .recipe. That way we don't have to, because that wouldn't work long-term. Let's go ahead and do here. We're gonna do our favorites, EJS, and here it would be .recipe, there we go. Cause it's one level deeper. We showed that in the console log. Boom. Boom. I still feel like I'm spelling recipe wrong. All right, I still feel like I'm spelling recipe wrong.

11:30:00
And let's look at our controller real quick. sending recipes, people have ads. Let's refresh, all right, it's working. So let's go ahead, we'll take five minutes on the clock. When we come back, we got it working. Third try, I'll walk through everything one more time. That way we all know that it works and then we'll end it there. Let's take a peek. I want to show you this console log, because this is kind of the, I had a brain fart, but this is what we're looking at here. So at the populate, we have the recipe information, but it's one level deeper in this recipe. So we still want to be able to loop through this array. So we're just going to pass the array like we always normally do. It's just that when we pop off each object, we're going to have to do the dot recipe to get the

11:31:00
information that we care about, right? So we're going to do the dot recipe to get the information that we care about. So that's why in our favorites ejs We're doing The recipes I just like we normally do when we're moving through the array that we sent to the ejs But we know that the things we care about are one level deeper with the dot recipe. That's why we're adding dot recipe everywhere Cool All right. I feel pretty good about this in what, less than two hours, we were able to take our template and build out the core functionality of what we wanted. Right? We said we wanted a recipe website. So we had to modify our posts to include ingredients and directions. We now have ingredients and directions showing up. We have individual ingredients pages that show the ingredients and the directions. We kept some of the stuff that like quality of life stuff, of like the likes and the deleting of recipes.

11:32:00
We also have like this favoriting functionality too where you can favorite your recipes. And if you go to favorites, which is the new thing that we added, we have just the things that you favorited. So notice great hall is not here. It's just the hat that's showing up. So I love that. I think for your a hundred hours project, this is exactly what I would do. This is how I would start, right? And once you get more and more comfortable now, the next 70, so 97 hours are in CSS. Exactly. Once you get more and more comfortable with the template, you can do more and more things. Um, you can start to spit these out pretty quickly. And so the thing that I will notice is that if I was applying and I was thinking about my 10 premium apps, this is what I would do. I would take a weekend. I would say, all right, I want to apply it to, I want to apply to, I

11:33:00
don't know, what's a big recipe website? Like all like food network or something like that, or what's the, what's the big one that I always wind up using? Any of the big food recipe websites, right? Boom. You now have something in your portfolio that's legitimately building a recipe website. Epicurious, exactly, right? All Eats, right? Any of those companies that you're applying to, you make this look a little bit prettier. You put some some some some basic data in here, so it looks decent and there you go Now when you apply to all recipes or epicurious you have something in your portfolio something on your github. That's like exactly What they would need you to build and so I would even use that and like the communications the things that I would send to The different folks on the team I would be linking this app along with it And of course you make it look a little bit spiffier use a better template in terms of like the design or you use Tailwind or something like that. If you want to, to clean it up even faster, it's using Bootstrap, but that's it. And then you could take a weekend and say, all right, what are the

11:34:00
10 companies that I really wanna apply to? And over that weekend, build out at least five of them, right, of like these apps using the template that you customize to the things that you needed to do. And that's gonna help you stand out during the interview process. And so that's, that's the, the idea here is that you now have this template. I walked through how I would modify the template to do exactly like what you asked me to do. I didn't have an idea what we were going to do going in, but you said recipe websites, that's what we built. And you can start to modify it. So this is something maybe as you go back and you read through or watch through the super review, you'll be like, all right, Leon changed this, then this, then this. And I hope just by me showing you the changes that I made, that you see that it's not like a really wild thing. You kind of rename a lot of stuff. You see what errors you get. Oh, I forgot to rename this part of the application. You go back, you change that. And then you have maybe a little bit of, all right, how do I pull the data I want? We learned about populate today. You might go

11:35:00
read the docs to better understand what that's doing. But it's really not that difficult to build out a bunch of apps now. That make sense? So this was, let's see, going for a little over four hours. So we did what? Six hours originally, then four and four. So 10 plus hours of back-end review that I hope gets you feeling a little bit more comfortable to jump in and start making some of these modifications on your own. Alrighty, folks, how are we feeling? Cool. Ready to go, great. All right, so this week, don't forget folks, this week we have a lot of stuff planned. We have, of course, our sessions tomorrow with Stephanie. We're gonna come back and I'm gonna show you the actual templates that you can use to send to folks. I riddled them off during class. There's

11:36:00
so many templates we're gonna talk through, real scenarios, when you would send them, wonderful things like that. And then we are going to move on to, um, we're going to move on to. Our standup every day this week as well. Friday, we have another tea spill. Uh, Tuesday we have more big O notation, data structures, algorithms. Thursday, we're building a hit list live. Woo.