Front End & Back End
In simple terms, the "frontend" and the "backend": what they are and how they interact
You’ve probably heard the buzzwords “frontend” and “backend” in programming, but what’s behind them? I suggest you look into it.
Let’s start with the definitions.
A front end is anything that a browser can read, display and/or run. That is, it is HTML, CSS and JavaScript.
HTML (Hyper Text Markup Language) tells the browser what the content of the page is, e.g. “title”, “paragraph”, “list”, “list item”.
CSS (Cascading Style Sheets) tells the browser how to render elements, e.g. ’20 pixel indent after first paragraph’ or ‘all text in body element should be dark grey and in Verdana font’.
JavaScript tells the browser how to respond to certain interactions using a lightweight programming language. Most websites don’t really use much JavaScript, but if you click on something and the content of the page changes without the white screen flickering, then JavaScript was used somewhere.
A BackEnd is anything that runs on a server, i.e. “not in a browser” or “on a computer connected to a network (usually the internet) that responds to messages from other computers”.
For BackEnd you can use all the tools available on the server (which is basically just a computer configured to respond to messages). This means that you can use any universal programming language: Ruby, PHP, Python, Java, JavaScript/Node, bash. It also means that you can use database management systems such as MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.
Relationship structure between BackEnd and FrontEnd
Today, there are several main architectures that define the interaction between the rear and the front.
Server applications
In this case, HTTP requests are sent directly to the application server and the server responds with an HTML page.
Between the request and the response, the server typically searches the database for the information requested and embeds it in a template (ERB, Blade, EJS, Handlebars).
When the page is loaded into the browser, the HTML determines what will be displayed, the CSS determines what it will look like, and the JS determines any special interactions.
Communicating using AJAX
Another type of architecture uses AJAX (asynchronous JavaScript and XML) to communicate. This means that the JavaScript loaded in the browser sends an HTTP request (XHR, XML HTTP request) from the page and (historically) receives an XML response. You can now also use JSON format for responses.
This means that your server must have an endpoint that responds to requests using JSON or XML code. Two example protocols are used for this: REST and SOAP.
Client (single page) applications
AJAX allows data to be loaded without refreshing the page. It is mainly used in frameworks such as Angular and Ember. Once created, such applications are sent to the browser and all further rendering is done on the client side (browser).
This front-end communicates with the back-end over HTTP using JSON or XML responses.
Universal/isomorphic applications
Some libraries and frameworks, such as React and Ember, allow applications to run on both the server and the client. In this case, the application uses both AJAX and server-rendered HTML to communicate front-end to back-end.
Outside frontend and backend
Savrups frontend
The web applications you are about to build will require less and less connection to the web.
Progressive web apps are loaded only once and run (almost) all the time. You can save the database in your browser. In some cases, your applications only need a backend system when they are loaded and then only for data synchronisation/protection. This level of persistence means that most of the application logic resides directly on the client.
Lightweight backend
The backend, on the other hand, gets lighter and lighter. Technologies such as document repositories and graph databases result in fewer backend calls for data re-collection. The client’s job is to figure out what data it needs (graph databases) or retrieve all the different data it needs (REST APIs).
It is now possible to create backend services that do not run all the time, but only when they are needed, thanks to serverless architectures such as AWS Lambda.
Blurred boundaries
Computing tasks can now be moved from front to back. Depending on the type of application, you can perform calculations either on the client or on the server.
Each option has its pros and cons. Server – the environment is more stable, has fewer unknowns, but requires a constant connection to the network. Some users use the latest browsers and prefer to use client applications that do most of the work and boast a nice interface, but then you will alienate users who do not use the latest browsers and high-speed internet connections.
In any case, it is good to have a choice. The key is to choose the one that is best suited to the task at hand. We hope you have a better understanding of the state of web development today.
