All right.
It's time for the final project of the module and we're going to be building a blog API.
Notice how we're building the API for the blog in this case, and we're not actually building the front
end.
What I mean by the blog API, well, we're going to cover all of the Http requests apart from put.
These two are both update methods and we can choose which one we want to do.
But in this case, what we want to do is only to have get post, patch and delete.
And what this is going to enable us to do is to allow our front end, which I've already built a very
simple example for you to connect to our back end, our server, and it's going to be able to display
all of the blog posts in order.
It's going to display their titles, their date of creation, their author and their content, which
for now is pretty short.
In addition, we will have all of the Crud methods such as Create, so we'll be able to create a new
post and you'll see that show up at the bottom.
We'll be able to update posts so it will display the existing title, content and author.
Or if we take a look at one of the larger blog posts, you can see that more clearly.
And we should be able to change this by making a patch request.
So only changing one part or a couple of parts of the entire post and we're only providing the updates.
So that is our patch requests.
And you can see I've now secretly taken over this blog post.
It's not by me.
And finally we can also delete.
So let me just delete this test post.
You can see it's now gone.
If you go ahead and download the starting project, the blog project from this current lesson, extract
it and open it up inside vs code.
You'll see that there are the usual things that you're familiar with, so you'll need to run npm I in
this current folder directory in order to install all your node modules before you get started.
And then if you take a look inside the Index.js, which is where you're going to be writing your code,
completing these five challenges in order to make the get post patch and delete requests to work.
And you'll see that what's happening is that we'll have two servers running simultaneously, one from
Server.js, which is going to act as the back end that makes the API requests.
So if you imagine somebody using your API and building a back end and the other one which is the Index.js,
which is going to be our back end for our actual API.
So this is the one that actually responds to the API requests from external servers.
So this is quite important.
We can't run two pieces of code on the same port.
That doesn't really work in order to get up and running and to test it out.
What I recommend is to go ahead and firstly CD into the project folder and then make sure that you've
run NPM I to install everything in there and then use Nodemon to run the Server.js.
And once you've got that up and running you should be able to visit localhost 3000 and it will tell
you error fetching posts.
That is because there is currently nothing running on the port where the server.js is looking for the
API.
So port 4000 localhost 4000 and this is what we're going to try and do with our index.js.
So you can go ahead and create a new terminal and again do all the required preamble.
So CD over and then Nodemon index dot JS Unfortunately, even though our API is now running on localhost
4000, this is still not going to work because we don't have any of the routes defined just yet.
What you can do instead is you can do a control C to stop this and use nodemon to run solution dot JS,
which is also going to go on to Port 4000.
And now if you refresh your localhost 3000, the server for the website is now actually reaching to
the API.
So localhost 3000 is hitting up localhost 4000 and it's now all working because all of the routes have
been defined in that solution.
Dot JS So you can compare and contrast, but while you're working on your own code, when you need to
test it, you'll need to stop this because you can't run two pieces of code on the same port and this
is what will happen if you try to do that.
So let me try and run Nodemon Index.js alongside.
Solution.
We get this error.
You can see apps crashed and if you scroll up, you can see the code is in use.
And this is because you will see the error that says address already in use.
So you should realize that this is because we have this solution JS running on localhost 4000.
So if we want to run our index.js then we have to first stop this one by using control C and then we
can try to stop this one and then try it again.
So now that that port is now freed up, then we can use it.
So essentially at any time point you should really only have two terminals open.
One should be running localhost 3000, which is going to be running the website that is hitting up our
API and the other one localhost 4000, which is the server where the API requests are handled.
And if you want to test your index.js, that's what's going to run on localhost 4000.
If you want to see what the solution would do in order to serve up the API to the front end, then you
run the nodemon solution.
Dot JS The goal is for you to be able to complete this independently based off what you have seen in
this module.
So we have to gets a post, a patch and a delete and it should be relatively straightforward, but you
might need to review some of the lessons in the previous parts of this module.
I'm going to let you pause the video and I'm going to let you get on with it.
You'll know once everything works because you'll be able to run Nodemon Index.js and it will allow you
to create a new post.
It will add the post to the bottom of our blog list.
It will allow you to edit new posts.
You can update them as you wish and you'll see them update in here.
You can delete posts as you click on the delete button and that's all the functionality there is in
this blog post.
So pause the video and see if you can figure out all of the challenges for this project.
All right.
Hopefully this was relatively straightforward given that you have completed the previous parts of this
module and we've gone through most of these routes in creating an API, get post, patch and delete.
If we take a look through the solution code, you'll see that it is relatively straightforward to get
all posts.
All we're doing is returning the posts as a Json using res.json and posts.
Is this array that we've already created here as a in-memory data store where we've got the ID, the
title, the content, the author and the date, and in later modules, when we cover databases, we'll
take this out of the current memory and we will store it on a database.
But for now, this is great for learning how to build our API without getting bogged down in all the
rest of the database stuff.
We've got our get, which is get all posts, which is relatively easy.
We've got the get a specific post by ID, so we have an ID path parameter and then we try to find it
inside the post array.
And then if we do find it, then we go ahead and return that post as a Json.
But if we don't, then we turn 404 and the message post not found.
When the user posts a new post, we can see that the server.js will try to hit up our API at the API
URL forward slash posts.
So that means that in our index.js we have to also make sure that that route exists at that endpoint.
And when it does, we try to get hold of all the things that are sent over, including the body title,
body content, body author.
And remember, we're able to do this because we're using the middleware body parser, especially this
part where we get Ahold of the URL encoded form data.
And as always, you can explore the different parts of the form so you can see that in the views folder.
You'll see that in the modified EJS, we've got two forms, one which is an edit form for the patch
request and one is a new post form for the post requests and you can see what are the names of each
of these fields.
So content author title.
And that is of course what we need to target when we are getting hold of body dot something.
So this part has to match whatever is in that modified form and then the date we're simply using new
date to use the JavaScript date model to create the current date and time.
And we saw all of that as a post object which we push onto the array.
And the ID we simply synthesize a by adding one to the last ID, which is this variable we're tracking
here, and we increase it each time we create a new post.
The patch request is similar in terms of the fact that we get hold of the data from the modified EJS
with the same name for each of the fields and we try to grab that data in our route and we use it to
update the post.
So first we find the post with the ID that we are looking for.
So that's passed in as a path parameter.
And then if that post doesn't exist, then we simply straight up return a 404 post not found.
But if it does exist, then we look to see, well, did we get a new title?
Did we get a new content or did we get a new author?
And if so, we go ahead and replace those relevant parts.
And then we send back the updated post as a Json.
And then finally, as a part of the delete request, we get hold of the ID that is deleted.
So if we take a look at the Index.js next to the delete button, it's an anchor tag that links to slash
API, slash post slash delete, slash the id of the current post because this is a for each loop using
our EJS and for each of the posts in that array, we assign the post ID already to that URL.
So that's going to hit up the server.js where if you take a look at the delete, it's going to go to
this endpoint and then it's going to send a request to our back end, our API and under slash forward
post forward slash request params ID, which is what it gets sent in the path parameter right here from
the server running on localhost 3000.
The one making the API requests.
Then we're able to make that delete request in our back end right here.
And essentially we're just finding the index, making sure the index actually exists and then splicing
the post to remove that particular post with that index.
And now we're getting closer to getting the two servers to communicate to each other, the Server.js,
which is the website making the API requests and the solution dot JS, which in your case is Index.js,
which is the back end of our API that we're building that's handling those API requests.
You can imagine this as somebody who wants to use your blog API writing this website and hitting up
your API in order to handle all of the complicated parts of creating and saving blog posts.
And this gets really close to real life.
And as you'll see later on when we start merging our front end and back end, you'll see this all coming
together.
But this will take a little bit of time to wrap your head around.
So don't worry if you didn't get it the first time.
If you got stuck at any point, be sure to review the solution code, but also review all of the different
parts of the code base.
There's nothing in here that you haven't seen before.
You've seen JS files, You've seen how the back end of a website should work.
You've seen how we can make these Axios requests, you've seen how we can create our own APIs.
It just takes a little bit of time for everything to come together in your own mind, and that's okay.
Don't beat yourself up about it.
It takes us all time to read code.
And in fact, I would say it takes longer to read code, a lot longer than to write code because you're
having to understand somebody else's logic.
You're having to understand how a lot of different pieces play together.
But just try practicing this a few more times.
If you didn't get it the first time, try it again with the explanation and looking at different parts
of the code base.
So hopefully you were able to build out the blog API and you have a functioning blog up and running
and you might even create some cool APIs of your own.
If you do, be sure to either hit me up on Twitter or head into the Q and A and Post to all of the other
students and show us what you've built.
Maybe we'll be able to use it and we'll be able to build cool projects based on your work.
So I hope you enjoyed this module.
I'll see you on the next one.