Overview of Procfile, Readme, and Server JS Files
Great job in going through all the material that we've made it through so far.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

I know you're probably very anxious in getting into React, and we will be doing that shortly. I think this should be the last video that we should have to do in order to understand the way that a React application is structured.

In the next section, we'll start building out the application, which is, I know what you're waiting for. Believe me, that's what I'm waiting for too. But now with this proper foundation, you should be able to have a much better understanding for the entire ecosystem around React.

So we have three files to go through in this guide and all three of them are pretty short, so we'll be able to run through them pretty quickly. If you click on the Procfile, you can see it only as a single line of code.

large

So what a procfile does is it is a tool that we're going to use for when we deploy to the web. It is going to declare the type of server that we want to run. We want to run, as you can see right here, a node server, and it is actually even calling a server.js file, and that is going to be the third one that we go through. So that's simply something for deployment, you're not going to have to change anything on there.

Now, the README.md file is a special type of file in any kind of application, a read me, especially when the ends in .md, that is short for markdown. So if you've never used markdown before, it is a type of markup language, and it allows you to write code like this.

Then that is going to get automatically formatted, and it's going to be something that is much easier to see. So I'll give you a link if you want to learn more about how to write mark down, and you'll be able to go and see all the syntax options at just at a high level.

large

If you see a single pound sign like this, that represents a H1 heading, so a top level heading, so that is going to be text that's really big. You can change this, and none of this code actually matters from an application perspective, this deals more with documentation. So when someone goes and they see your project's code base, this is going to be one of the first things they see.

In the next guide, when we deploy this to GitHub, you'll see that this gets rendered and formatted nicely. So you can get rid of all of this kind of starter texture here, and you can just give it the name of your project.

So you could say, in my case, Jordan Hudgens React Portfolio Application. Then when you see this little greater than symbol here, what that represents is that it is going to indent that code. For this, we can just get rid of it, we're not going to need that. When you see a little asterisks here, that means that that is content that will be italicized, but you can get rid of all of that.

If you want to add any other content, feel free to. There's nothing here that we're really going to need for right now. Later on, what the ideal scenario is, and we can do this in one of the later sections, is to write a full set of instructions for anyone that wants to use your application.

So that would mean a step-by-step set of instructions for pulling it down into their local machine, being able to install all the dependencies and then how they can run the server, those kinds of things. So for right now, we don't need to do that, but that's usually what you'd place in your Read Me.

The very last file here where we are done is this server.js file. Now, you're not going to have to make any changes to this file. I built this one specifically so that it would work for a React application, this is going to be what is needed when we deploy it to production.

So it pulls in the Express server, if you remember when we looked at our package.json and our node modules, Express was the server, it was that NPM package that we used. So here, it's bringing that server in, it's declaring the port that this is going to run on on the live server, then it starts an instance of Express, then from there I added a few configuration options.

large

So I said, "I wanted this application, you can see that I created a variable here that I'm storing Express in." I said, "Okay, I want this app to use Express static," and then I'm passing it this kind of long name where it says dirname, which is short for a directory name and then dist.

So whenever you build, remember when we talked about the command running npm run build. That's what's going to happen on production, and it's actually going to take all of our code, and it's going to put it inside of a dist directory, and that is what the server's going to look at it.

The server isn't going to look directly at the code we're going to write. It's going to look at the code that's been compiled, and the reason for that is because the compilation process, that's where Babble comes in, it's going to convert the code so that it works nicely inside of any browser.

Then it also performs a process called minification and what that means is it goes through our code. It strips out all of the empty space, any code that's not being used, anything like that, so that the application can be as fast and as performant as possible.

So it's going to look in a different directory, but this all happens automatically, I'm just wanting to walk you through what the process looks like. Then right here, this is a little bit of a tricky one. This is something I had to add that is needed for custom applications from a routing perspective.

Let me show you this really quick, so if I switch over to google chrome. We're going to have some different links, we're going to have something that says like blogs or something like that. Those are all going to be separate URL end points.

Now, on our local machine, these are all just going to work after we define them. However, in production, they wouldn't, and the reason for that is because remember that we have a single HTML file. We only have that index HTML file, and all of our code is just being dynamically created and generated by the React application.

Well, what this does is it checks to see if someone goes to some other end point. So if they go to /blogs or /portfolio or /login, whatever that is, and it goes and it tries to find that route, because by default React, Vue, and these JavaScript applications, they would not do that.

So you don't have to worry about this, it is all taken care of for you. But I did want you to just have an idea on why code is there. As a developer, it's a really important habit to get into is to really think through the code. Don't just see some code there and take it for granted just because it works, I want you to really have an understanding for what it's doing.

Then on line nine, here we are now listening to a port, so we're declaring the server, we're giving it some configuration options, and then we're saying, "Okay, start the server and let's listen at whatever port the server is running at."

We have now gone through every single file that was generated in the React application, and hopefully, you now have a lot better idea for what it takes to build out and what it takes to have that foundational set of configuration items and those kinds of things in React.

In the very next guide, we are going to take our project, and we're going to configure it with Git, and we're going to push it up to Github. So I'll see you there.