I really enjoy front end development. I’m a creative person by nature, so having the opportunity to create and shape something into a functioning site or application is a challenge I regularly enjoy.
However, I was always curious about the back end.
I would create and code these forms on the front end and code in different types of requests without fully understanding why I do it. It seemed like back end developers and engineers were wizards and a part of me wanted to understand this wizardry!
Back End Wizardry
The full stack project that was to build a clone of Yelp. Not entirely identical but functioned like Yelp for the most part.
This clone is Yelp Camp, a review site for campgrounds. Get it? Yelp for camping?
Routes are basically what they sound like; it’s the page or URL that a user is requesting.
When you go into the browser and you type in a URL, you are making an HTTP GET Request. This request is answered by a server (a computer that contains all the sites and files you are requesting) and sends back a response.
By creating routes, you get to make the decision of what to provide users when they request different pages, non-existent pages or anything else on your server.
You are essentially the gatekeeper of the website.
The next step was to learn and understand RESTful Routes. Representational State Transfer, or REST, is an architectural philosophy that encourages developers to use HTTP as it was meant to be used. It’s similar to CRUD (Create, Read, Update, Destroy) in concept, however, it expands into seven distinct routes:
- Index – Get Request
- New – Get Request
- Create – Post Request
- Show – Get Request
- Edit – Get Request
- Update – Put Request
- Destroy – Delete Request
Each one of these routes are created for different purposes, depending on the functionality of the webpage. For example, you would want a separate page for updating information (a PUT request) in a database and not submitting information using a GET request. This would result creating a new entry in the database with the same information. Kinda self-defeating.
Now that I learned how to create routes, what will the users see when they reach those routes?
EJS & Templates
By far, this must have been my favorite part about learning back end. I’ve always wondered how back end developers created templates that were reusable and how they manage to populate dynamic data in them.
Once an EJS template was created, you could make a call for the template to load onto different pages without having to re-type all the code again. Isn’t that cool?!
For Yelp Camp, I used MongoDB. I had zero database experience prior to starting this project, so I didn’t know what I was missing out on or if MongoDB was better or worse than other databases. MongoDB is a NoSQL database that is popular among MEAN/MERN stack developers. While rising in popularity, MySQL is still far more favored in building full stack applications. I’m still a little fuzzy why one is more desirable over the other, but I definitely see some benefits of both.
MEAN Stack – MongodDB/MySQL, Express, Angular.js and Node.js
MERN Stack – MongoDB/MySQL, Express, React.js and Node.js
MongoDB is based on the JSON concept. Someone basically noticed that JSON objects are really cool in formatting and storing different types of data all in one place. I guess the same “someone” decided that it would work great for storing data on a database, thus MongoDB was born.
To create the database, you simply head over to the MongoDB website to install MongoDB through your terminal. Once up and running, you can connect the database to your application via Mongoose.
I also had to create a login system for this application. While it is completely possible to build a login and authentication system, I used Passport.js for this project. Passport is a middleware used to create a hash, secure passwords and authenticate logins for users. Passport.js is also compatible with popular login platforms such as Facebook and Google.
Check out Passport.js
The Rabbit Hole
When I first saw how heavily involved the terminal was going to be, I initially freaked out. I was ready to reverse my gears back to “Front End World” and never come back. After having completed this full stack application, I have to say that I very much enjoyed the process!
Despite enjoying creative options on the front end, I did very much basked in the back end world where I didn’t have to make decisions about the colors on a page, the form’s layout, etc.
Isimply figure out which page I’m sending a user to, provide some error handling and make sure the server was up when it was supposed to be. At least in a nutshell.
This was a tough learning experience for me, but it was also a very rewarding learning experience because I got out of my front-end comfort zone and learn about something new.
The back end rabbit hole can get pretty deep. On the surface, a lot of what I built was very fundamental and doesn’t even encompass the algorithms that many engineers write to access databases or process the data before passing it to the front end. The list of back end technologies also span endlessly, with different scripting languages to choose from, different databases and finally different implementation of the technology.
While I would love to get more deeper into back end, I wouldn’t mind settling somewhere in the middle and doing full stack development in the near future. I could never walk away from my love of front end, but I could still see myself enjoying the tasks of setting up RESTful routes, writing algorithms to process data and creating templates.
Back end, you complete me.