This webinar gave you the basic structure and understanding of backend ecosystems. It was only a taster of the knowledge we will dive into in TechJargon’s one- to three-day training, so if you are interested in going more in-depth, you can sign up here.
Here is a quick recap of everything we covered in the webinar!
If you attended our Frontend webinar, you might be inclined to define the backend as ‘everything the user doesn’t directly interact with’.
That is only part of the story.
Backend is a set of technologies with one goal: to deliver a client what he or she asked for. Backend processes incoming requests from the frontend, prepares the requested information, and sends it to the client.
The word ‘backend’ therefore describes a process of communication and data exchange through a series of requests and deliveries.
Backend is a much more rigorous place to work than frontend because it is all about managing data. This data needs to be protected. For example, when you signed up for this webinar, your data was stored in the backend in a secure way. Because of the alarming consequences of a data breach, there is much less room for backend engineers to slip up as compared to frontend engineers.
Backend consists of three main elements: the server, the app, and the database.
is a computer that prepares requests that arrive from the frontend. There can be many computers for one single app.
is a piece of software that processes requests and formulates responses. It runs on the server and serves as the link between the request and the database, where it makes calculations and/or retrieves information from the database.
stores and manipulates the data.
The server side of the backend is composed of the server, the database, and the file system. Some people call these three components the backend, but there is more to it than just that.
The most important thing to understand is the relationship between the server and the other components in the backend system.
Here is how Backend would operate in the real world: You come to a restaurant for lunch. You are a client to the server. The server is someone who will process your request and then deliver you your order fresh from the kitchen (or in this case, database).
The server takes your order and places it at the kitchen by forwarding your request to either the database or the file system. That forwarding is another request of its own. The database or file system then delivers the server the information it requested. In this way, the client-server relationship is the same between the server and the database as it is between the frontend and the server.
The kitchen cooks your order: this is the processing time it takes to retrieve the information you requested.
The server then brings your completed order from the kitchen. When he or she sets it down in front of you, this is the equivalent of seeing what you requested on the frontend of the application.
There are two main types of backend setups: monolithic and microservices architecture. Understanding the differences between them will help you better understand a candidate or company.
In monolithic architecture, there is one server, connected to multiple modules in a database that each handle different requests. These modules together form one aggregate database. This plus the main server equals one overarching server.
Monolithic architecture works like a gate when it comes to security. When a client makes a request on a website, a security protocol must verify his or her identity. In many companies, the security part of the backend is the main server. If the security check does not go through, the client cannot access anything else in the app because the server refuses to retrieve information from the database. These companies can isolate a problem, like a phishing attack, by killing that server – all important information is safely locked up in the database beyond it.
A monolithic setup becomes impractical when there is a high volume of requests. For example, last week on Black Friday, many online shops saw a huge spike in requests.
Only increasing the number of servers doesn’t help because there is still only one database from which to retrieve information.
The solution? Moving towards a microservices-oriented architecture with more servers and databases.
A microservice architecture splits up the work of handling requests among different independent servers. A different server (including a database) takes care of each of an application’s functions. There is an entire server just for authorization, one for searches, and one for reviews, for example. This setup streamlines where the requests are sent to be processed. We don’t need precisely one database per server, as some servers can share databases. All servers talk to each other via APIs, though they function independently.
This is helpful if you want to test a function for an application. If one function is not getting any traction from your audience, you can simply shut down its server without disturbing any of your other servers.
There is usually a different programming language for each server and app function. For example, the authorization server is probably using C# or .Net, while the orders server is probably using Python. The search server likely uses Elasticsearch.
Now you know what a hiring manager means when they ask for someone who knows Elastic: they need someone to work on the search component of the website.
CI stands for continuous integration. CD stands for continuous deployment. Both approaches together form DevOps: a method for quickly producing and improving programs.
DevOps allows you to think on your feet: to modify things as needed. It relies on having a good backend architecture. After all, if every choice you make will impact many other servers, it will be difficult to work on your feet. This is the main problem with monolithic architecture, and explains why many companies are opting for a microservices approach.
We hope you found this webinar and recap helpful! If you want to expand your knowledge of backend, TechJargon’s training dives deep into its other components like Oracle and ESQ, and how they relate to the main application.
For more content, follow Tech Jargon on LinkedIn!
Check out the visual notes of this webinar:
You may have recruited Java developers before, This array of positions already gives you an idea of why it goes beyond the mere programming language.
Read MoreDec 02, 2020
5 min read
These strategies were mined from Davy's own experience hiring developers, combing through their past experiences with smart questions and technology.
Read MoreDec 02, 2020
5 min read
Don't miss weekly nuggets covering technologies used by IT people explained with down-to-earth words
© Copyright 2022 Techlingo
