If you have ever visited a sit-down restaurant, then you can understand the difference between front-end and back-end in web development.
When you are just getting started with learning web development, you encounter a series of concepts that completely overwhelm you.
Databases? Servers? Client-side? Server-side? AJAX?
Fortunately, you only need to understand HTML and CSS to build your first website, and you can do it locally on your computer. But if you want to understand how your site can eventually go live on the web, you need to understand the concept of front-end vs. back-end.
Here’s the general idea: just like there is a waitstaff and kitchen staff in a restaurant, front-end and back-end divides the functionality of your site. It allows each side to do what they are good at.
In the case of kitchen staff, that means cranking out high-quality food efficiently. The waitstaff are experts at working with customers and creating a customer experience.
In web development, the front-end is also sometimes called the client-side, while the back-end is also called the server-side.
Here are the roles that the different technologies play in the front-end v. back-end of a web app. In order to understand this tutorial, you will just need to understand the basics of HTML and CSS.
Let’s look at the front-end first. Front-end code creates a user interface, a structured way for web visitors to interact with your code. In our example, that is a table within your restaurant- a place where a controlled interaction happens between customers and the restaurant staff. So, think of the table at the restaurant as the website, like http://mysite.com.
First, users (or customers) need something that they can browse. In a restaurant setting, this is the menu, obviously! It is a static piece of content that should make it easy for customers to understand their options.
From a front-end developer’s perspective, this is similar to HTML and CSS. These two languages allow you to build static content.
But there’s one thing that is obviously missing. You can’t shout at the menu and expect something to happen! You need a way to communicate that order to the kitchen staff.
I summarized both parts through the process of choosing a meal. When users arrive at your site, they have a goal in mind. Your code must help them accomplish that goal.
Have you ever been inside a restaurant kitchen? It is a high-stress environment, to say the least. It has a TOTALLY different environment than the one that the customers see. You could even say that the waitstaff and menus provide a friendly, perfectly-formatted version of what goes on in the kitchen, without revealing any of the processes.
This is similar to the back-end of your web application, or the code that runs on the server-side. Just like the kitchen, the server is in a different location than the user interface. It uses different languages to communicate.
Since a server is really a computer in a remote location, it has a lot more computing power than the browser on any given computer. Much like the kitchen staff, the focus is on efficiency and productivity.
Think about the complexity of a restaurant kitchen. It must have all the ingredients in the right place at the right time. All the staff must know their job at any given point. And they must produce the same meals with the same quality over and over again. Similarly, a server must organize the data from your web app in order to send the right response at the right time.
The server must send a response whenever it receives a request. In the case of the restaurant, this response could be:
Popular back-end languages and frameworks include Ruby, Ruby on Rails, node.js, PHP and more.
The other reason is that we allow each side to focus on the challenges that they are uniquely qualified to handle. Can you imagine if the chef had to take the place of the waiters? It would be a customer experience distaster! So, we are fortunate that we have one side specialized in user interface, and another specialized in server-side challenges.
Imagine that you own a business that does not sell anything online. Let’s say that you own a local flower shop.
In that case, you have no need for a back-end since there are no complex calculations. You only need a front-end, and perhaps a contact form that can direct any inquiries to your email inbox.
In other words, some sites are just meant for browsing and taking some sort of action that the website does not need to handle. You don’t need to write a back-end for every type of site. You can use Github Pages to put your custom front-end live on the web if you don’t need a back-end.
Do you think this post may be interesting for anyone else? Help someone gain knowledge by sharing it!