FRONT AND BACKEND: A BRIEF ANALOGICAL EXPLANATION ON A FULL STACK VIEWPOINT

Are you now taking your first steps in this world of technology and are you curious about the particularities of the backend? Do you know how to distinguish from frontend? Stay on this side and read the article he prepared for you! 😉

       

Think of the frontend as a set of components that are viewable and possible to interact with.

Let's imagine a person, this person has appearance, feelings and consciousness. The appearance is the visual part (interface). This is the one that is responsible for everything that can directly be seen from the outside, in this case by who is using the system (end user).

In this process we are not talking about interaction or manipulation of information, but only and exclusively of what is in fact presented on the screen, whether they are pictures, text, buttons, forms, etc. These last two from the development point of view are interactive components, which just like our feelings and consciousness, are really what connect us to the outer world, generating behaviors, which are called inputs and outputs (events).

Events, as the name suggests, are occurrences chained together by actions taken by both the end user and the system.

   

Let's assume a situation where you, as a user, need to send an email. The body of said email is the form. By writing in the body of the email we are generating inputs and the text that appears as it is being written are the outputs. It sounds complex, but it follows the same principle as those old typewriters your grandparents used to use to send letters.

   

But of course, this jumble of things needs to work somehow and this is where tools come in handy. Bear in mind that we are going to talk about more cutting-edge tools that are inclined toward web application development.

   

Usually, for an algorithm to work, the source code needs to go through a compiler, which translates that code into a language (bytecode) that the machine understands and then executes. In Javascript the compiler part does not exist, since the browser itself has a built-in interpreter that does that.

Yes, Javascript is the holy grail when we talk about web development, since it is the role model in the feelings and consciousness part.

   

CSS and HTML.

HTML

Hypertext Markup Language is the star of our application, let's say it is the skeleton, and without it nothing exists. Responsible for the functionalities and the layout of the application as a whole: design, accessibility, structure, etc.

CSS

Cascading style sheets is a style language used in the presentation of HTML or XML documents. CSS describes how elements will be displayed on the end user's screen.

   

If HTML and CSS are the appearances, the Javascript being the feelings and consciousness, does it mean that it inherits the behaviors? Yes, the events are the total responsibility of this component, because without it our application does not behave, get it?

Allows you to access elements of the HTML page separately. We call this the Document Object Model (DOM). An interface that allows you to manipulate the content, structure, and style of an HTML document.

After all these explanations, I could be a spoilsport and tell you that some frameworks and libraries make your job easier, but I won't 😉.

   

The answer is yes, but it is also no. In other words, it depends.

Later on, I will tell you about magic boxes that store data, for now, I will talk about LocalStorage, SessionStorage, and Cookies (which you can't eat, but your browser surely can).

These three main concepts are what we call browser storage. Basically, it consists of a Javascript interface that allows data to be stored directly into the end user's browser and like an unlocked chest, it can be retrieved whenever you want.

Since this data is stored in your browser, by logic only that browser can see it. For example, by storing data locally in Google Chrome, that data will only be available in Google Chrome, when opening Mozilla Firefox we will not have the same data stored.

Local Storage

As the name suggests, this is your browser's local storage, the data is stored without an expiration date. You can close tabs, close the browser...if it's not deleted, it will be there, in the depths of your chest.

Session Storage

Although in general, it has the same purpose as session storage, unlike session storage, it gets deleted as soon as you close tabs, close the browser... you got the idea.

Cookies

This one has a different purpose, although it stores data on one side, it allows communication with external agents, namely servers. Cookies are sent with requests to the server that responds with information relevant to the application. This is important when sending personalized content to the end user.

   

Yes, after all, machines have did not taken over **yet** and fortunately, we can still be served by them. This is where we start talking about backend applications - or the magic boxes that spit out on-demand information and store millennial data that doesn't accumulate cobwebs.

   

In this sense, those servers are responsible for information manipulation. Which follows an acronym you will invariably hear a lot about: CRUD - Create, Read, Update and Delete, accordingly.

Imagine a community library, where you can borrow books or even give away books you no longer want. We will call it a database.

The database is a library that can be as big as you want, where you can have a finite (or almost infinite) collection of data, that data can be read whenever you think is necessary and irrelevant data can be deleted or updated by new data, just like in a library - new books can be added to the library collection (create), and can also be requested by you (read), old books can be replaced by new editions (update) and when they reach their lifespan they can also be removed from the collection (delete).

Now imagine that the library that I just told you about is an online community library. How can you manipulate this mishmash of data?

     

API? Yes sir. An Application Programming Interface allows communication to happen between two or more computers. This is when you can request books (request) and receive them (response) through a little thing called an endpoint.

According to Newton's third law, every action has a reaction, and as in real life, an API is not much different.

   

If you request the server you expect it to give you a response, and that's what happens.

The end user, through the frontend, asks for some sort of information, for example, to request new books a request is sent through an API, which fetches the data library and delivers a response, which may or may not contain the requested book.

   

Relax, it's simple... When it finds it, it sends a set of data that we call a payload, when it doesn't find it usually sends a pretty message (sometimes, rarely) and a code warning the error type.

Payload

When data is transmitted from a source to a destination we call it a payload. It is the data organized in such a way that it can be received by the frontend application and manipulated later on.

Request

In this context, it is the request made by the end user to the API, which may or may not contain a payload. When it contains a payload it is expected that some data might change in the database. Since there is an exception to every rule, the delete operation changes data but does not contain a request payload.

Response

This is the response provided by the API. It is expected to contain a payload with information about the data that was requested, as well as a code telling the status of the response. Don't worry, there is a list of those codes and you can find them here.

     

Did you get here not understanding a thing? Well...frontend is the pretty part that everyone can see, with rainbows, happy people, and chocolate fountains. On the other hand the backend…the backend is the catacombs that only the development team has access to (fortunately, and I am not kidding when I say catacombs).

   

As you just saw there are numerous differences between those two. The frontend is the first contact that the end-user has with the application, which allows the company that created it to present some product or service, through eye-catching and appealing designs that generate some kind of value to those who see it. We also have an article addressing that topic that you can read here.  The backend, on the other hand, carries the application's business rules, as well as the database that supports it, enabling communication between the data source and the end user.

Remember, one cannot exist without the other, they both complement each other in their shape or form and are crucial especially in web application development.

   

Note: Full stack development goes far beyond what was presented in this article, and so do other software development techniques. This article presents a small portion of a gigantic universe that full stack development is. So do not get stuck on technical terms or concepts, use the tools that are at your disposal to ease your productivity as a programmer, and remember, knowing how to research is a virtue, use it in your favor.