Programs and applications can be comparable to something like a tree or a plant. You have the plant's upper body, leaves, and flowers which anyone can see. But they also have roots underneath which are unseen by anybody. This unseen section is backend development. Backend development makes user and database connections possible.
Backend development is where the magic happens. Usually makes up to three different pieces that operate under the users' eyes. An application, a database, and a server. This is where user interactions and data from users are processed and stored.
There are generally two parts to a web application. The frontend or client-side and the backend or server-side. The frontend consists of the web pages you see and interact with. Those pages are designed by front-end developers. When a user enters a URL, clicks a link, or submits a form their browser connects to a web server. A web server is a computer running software that delivers resources. When a web server receives a request for a resource it needs to respond with that resource. Making web servers respond with the right resources is a job for backend developers. Before a web page or other resource is delivered to a browser. A web application was written by backend developers and fills that page with data. The data pulled from a database which is a separate program that stores and retrieves data. Backend developers must understand whatever programming language the web application is written in. As well as the database where the data is stored. So frontend dev designs webpages. A backend dev serves up those web pages customized with the user data.
But how do backend developers tie in together the applications, databases, and servers? To do this backend developers use coding languages. Such as .Net, Java, PHP, Python, and Ruby, and tools like MySQL, Oracle, and SQL Server.
So you want to be a backend developer. Backend developers are responsible for storing user data, payment processing, and APIs.
You must have some understanding of coding languages for web development. Troubleshoot and improve on current applications, and solve problems. As a backend developer system, consistency and user experience is a priority. Backend developers work together with frontend devs when creating a web app. While the frontend dev focuses on the look and feel of the website. Backend devs focus on the data the site presents.
What skills do you need to be a successful backend developer? Not to worry as we will now discuss the necessary skills to be a backend developer.
Knowledge of at least one server-side coding language is important for backend development. Being well-versed in a coding language may make you sought out by employers. Some common coding languages include Java, .Net, SQL, PHP, and Ruby. Each of them has its unique purposes and functions that are under these categories:
Although it is not necessary to be an expert in all these languages, specializing in one is the way to go.
Backend developers manage a hosting environment, hence requiring database administration. Backend developers are also responsible for creating storage solutions. A few database programs include:
Caching is a bonus as it can improve performance, thus, enhancing user experience. A few caching mechanisms are:
2. Varnish cache
Servers are computers used to maintain websites. Which makes them a core component in backend development. Backend developers need to have a clear understanding of web-server technologies. The backend is running on web servers or cloud-based servers, even a combination of both. Knowledge of any of these can help in server management:
6. New Relic
7. IIS Servers
8. Microsoft IIS
Backend developers must be knowledgeable about application programming interfaces or API. API's allow the connection, interaction, and the exchange of data for other services.
The chances of you working in a team are very likely and that is where communication plays a big part. Being able to communicate with your team members can save time and improve the project. Listening can also help you through constructive criticism. Documentation can also be a means of communication for other developers.
Problem-solving and critical thinking can be like second nature to backend developers. Being able to find solutions to various problems. Such as making revisions without sacrificing functionality, preventing crashes, or debugging code. Skills such as these can help you become a more efficient backend developer.
Is learning a skill? Yes, yes it is. Being a developer is not an easy thing, you can be fine today and buried with errors tomorrow. As a backend developer. You need to be able to learn and adapt to be able to handle the amount of information handed before you. Having the willingness to learn makes you better equipped with what you already know.
A backend developer must adapt as they deal with data. And know of an efficient way of retrieving data from a variety of sources. This roadmap will cover the things backend developers are expected to deal with.
The internet is like a spider web of computer networks that provides a ton of information. Using communication protocols. The internet operates by sending an HTTP request to a server. Asking for a copy of a website then sending it to the client through TCP/IP. If the server approves the request. The server then proceeds to send a go message to the client's request. Then follows with sending chunks of the website's files called data packets. Finally, the client's internet browser assembles the data packets to display the website.
HyperText Markup Language (HTML) is a simple coding language that applies to forms of text. Whether they are a bulleted list or in table form. HTML can also structure a document into sections such as headers and columns.
Cascading Style Sheets (CSS) is the code you use when styling your webpage.
A backend developer doesn't need to learn every language there is. Being proficient in one is enough but learning a new language will give you more advantages in the long run.
Here are some languages and frameworks you can discover and explore:
A programming language with a focus on simplicity and productivity.
A programming language that allows you to put features on websites.
Was originally developed by Microsoft as an alternative to Java. C# frameworks include ASP.NET MVC and ASP.NET core.
A highly flexible programming language that's easy to learn and use. Popular Python web frameworks include Django and Flask.
A scripting language especially for web development and can be embedded into HTML and used.
A server-side web application framework written in Ruby. It provides default structures for a database, web pages, and web services.
Brings rapid development and clean, pragmatic design.
Not everyone is perfect, not even backend developers. You are bound to have dirty code made and released or lost your progress in a power outage. Version control systems are here for you. Git is one of the most used hosting platforms for version control available. It also lets you and others work on projects together. The version control software can help you manage different versions of your code. You may need computers to run your finished web app. Nowadays most apps are hosted on cloud hosting platforms. That can send copies of your app to as many or as few servers as they need. popular cloud hosting platforms include amazon web services Heroku and google cloud platforms.
Now, we already know backend developers deal with data. This is why learning around databases is essential. We have three types of databases:
Data is stored in several tables connected by a common field. A table is a data set that is divided into rows and columns and is referred to as a relation. Each row in a table is referred to as a record or tuple, and it contains data or information. Columns, also known as fields or attributes, have a single class of data, such as ID numbers or names. The degree of the relation is defined as the number of columns or attributes. The cardinality of a relation is the number of rows or tuples in a table. Many popular relational databases include; MySQL, Microsoft SQL Server, and Oracle.
One of the most important principles in a database is the ability to define each row or tuple uniquely. The table's records are individually identified using a primary key. When designing or creating a database, we look for attributes in a table that uniquely define a row. There could be more than one attribute used to determine rows uniquely called candidate keys. One may be chosen as the primary key, while the others are referred to as alternative keys. A composite key is a combination of attributes that can be used to identify a row uniquely.
A foreign key connects several tables in a database. A foreign key is an area that refers to another table's primary key.
While relational databases scale vertically, NoSQL databases scale horizontally. Tables are not used in NoSQL to organize data. They're saved as Key-values stores, with each object having only two values: a unique key and a value. NoSQL databases scale better than relational databases due to their simple architecture. If a single database server is insufficient to hold all of your data or manage all of your requests, the workload can be divided between two or more servers. Each server would then only be in charge of a portion of your database. These are called partitions, and the key determines which partition items will be stored. NoSQL databases use a hash function to translate each item's primary key into a number that falls within a specific range. After that, the hash value and range are used to decide where an object should be stored. If your database is small enough and you don't receive a lot of requests.
All can be hosted on a single server. If the server becomes overloaded, a secondary server may be added. All things with a hash of 0 to 50 will be handled by server A. Server B, on the other hand, can save anything with a hash between 50 and 100. In a sense, you're doubling your database's storage and query execution power. This range is called a keyspace. It's a straightforward method for storing new objects and locating existing ones. All you have to do is keep track of which server is in charge of which keyspace segment. In addition to scalability, NoSQL is schemaless. That is, database objects do not have to have the same structure. If the application and data structure are constantly changing, not having a schema can be a huge benefit. Which makes it more flexible than your traditional SQL-based tabular database. MongoDB is a popular NoSQL database regarded among backend developers.
A graph database uses graph structures with properties and nodes to store data. A graph database is to treat the relationships between data as important as the data itself. The data is to hold without constricting it to a predefined model. Nodes, which are records connected with a form of relationship that can have direction and a property associated with it, are one of the characteristics of a graph database. Querying graph databases isn't like querying a database in SQL. Vendors of graph databases also have their own query languages, such as Gremlin, SPARQL, and Cypher. One disadvantage of a graph database is that certain relations are meaningless. Another problem is that it's not unusual for a graph database query to be lost. Probably because the question is difficult to comprehend. This leads to false interpretations and slow-running queries. Graph databases are part of a broader set of data processing resources. Neo4j is one of the best graph databases available out there.
Caching saves data for web applications in local storage and later on referring to this data. Backend developers take advantage of caching. This helps enhance the user experience by reducing latency in rendering the application. To improve performance for websites, we usually use some kind of caching. Which can either be on the server-side in the form of application-level caching like using Redis or Memcached. Or it can be on the client-side. When the request asks for a resource, it will first be checked in the cache. If it is not there, the request will be sent to the server, and the response will get cached. So if you request the same resource again, there will no longer be calls to the server since the request was cached.
The cache is stored in three locations: browser cache, proxy cache, and reverse proxy. The browser you use might cache the response from any previous visits you had from websites. It depends on the caching headers, and the cache in the browser is private to the specific user using the website. For proxy cache, caching is done at the proxy level, which is installed by your internet service provider or the organization you are working at. And for reverse proxy, which makes it that cached data is stored by a proxy closest to your server. We have two types of content where stale content is the cached content but expired. And fresh content - which is cached and is still usable. HTTP headers play a vital role in caching content. Whenever the server sends the response to the client, it sends the HTTP headers with the response. Which the client can use to cache the content delivered.
Cache-control was introduced in HTTP 1.1 and is the preferred way of caching. The client also uses validator headers to make sure the cached content is still usable. HTTP 1.1 is a multi-value header, so it can have multiple values or directives to determine caching behavior.
Some possible values for cache-control headers are:
1. private directive - the cache is set to private, meaning the content is exclusive to the user, and the cache is stored in the browser or client.
2. public directive - the cache is available to multiple users and can be cached publicly to any of the proxies.
3. no-store - the cached content cannot be stored anywhere. Making the client call for the server every time it needs the resource.
4. no-cache value - the content can be cached, but the server's validation is required using ETag or entity tag header for it to be usable.
5. max-age - tells the client that the content can be cached for a limited amount of time.
6. s-max age - '-s' stands for shared. It is the same as max-age but gives caching duration for other shared places or proxies.
7. must-revalidate - will not allow you to use stale or expired content and must revalidate from the server.
8. proxy-revalidate - is the same as must-revalidate, but this applies to proxies or the shared cache.
When serving content, the server normally sends an e-tag header in the response, which is just a unique identifier associated with the resource. The client then uses the ETag to make a request to the server, checking if the content has been changed. There are two types of ETags; the strong and weak. The strong ETag means that the two resources are identical. And a weak ETag implies that the two resources are not similar, although they could be considered equal somehow.
The last-modified header indicates the date and time when the latest change was done to the content. If the content turns stale, it will make a conditional request with the last modified date using the if-modified-since header. Which the server will use to either return 304-Not modified or a new response. If both ETag and last-modified headers are present in the response, the client will send both the validation request parameters.
What caching strategy would be best? Well, it all depends on your application. Usually, it falls into two categories; light and aggressive caching.
Light caching - cache-control: private, no-cache
HTML files must make the client cache it but must validate with the server before use. This way, the client always gets the latest HTML whenever it is available on the server. But if the HTML files have not been updated, it can avoid downloading and use the one cached in the browser. For dynamic content, it depends on your needs. If you have RSS for your blog, you might cache it publicly for a few hours. If you have a product listing like JSON for an E-Commerce website, you might need a different set of caching headers.
Aggressive caching - cache-control: public, max-age=31556926
API's are application programming interfaces. Our resource is to be accessed not by web browsers but by mobile phone apps or other programs.
The web framework then coordinates the rest of the process of handling the request. Code written by the backend dev uses ORM or Object Relational Mapping. To connect to a database and retrieve data that will be in the finished webpage. Programming languages and web frameworks represent data as objects. And the ORM library handles converting database records to objects. Most databases use a language called SQL to retrieve data. The ORM library writes most of the SQL queries to retrieve the needed data. sometimes the query is so complex the ORM library can't handle it. Backend developers need to know SQL. So they can write their queries on this situation once the data has been retrieved. The back-end developer needs to insert it in the pages that were by the front-end devs. Web pages are written using HTML or HyperText Markup Language. And a backend developer needs to know enough HTML to be able to update the page if you're maintaining an API. If the server might send a response that is for use by a program other than the browser. Usual API replies are JSON and XML. A backend developer needs to be able to convert data to JSON or XML for the server to respond with.
Once the code has been written to carry out all these steps for a request. The backend developer's work is done. The web framework will deliver the completed response to the web server. And the web server will respond to the user's browser. If the backend developer wrote their code carefully and cleanly avoiding slower operations. Then this whole request and response process usually takes less than a second.
There is no such thing as plug-n-play security. It all depends on the development method and the layers of a web application environment. The backend storage, web server, and the web application itself. This is why web security should not be an afterthought for backend developers. Many of them focus more on application logic than security. Backend developers should write code with security in mind always. SSL and TLS are one way of web security. Secure Sockets Layer refers to a protocol for encrypting and securing communications. Usually taking place on the Internet. An updated version of this protocol is Transport Layer Security or TLS. But sometimes referred to as SSL.
SSL/TLS works by securing communication through a handshake. Which uses something called asymmetric encryption where two different keys are used. During the handshake, two session keys generate. They encrypt and decrypt all communications after the handshake.
Among other things, securing cookies is also important. As they hold login, user preferences, recording, etc. data. Restricting access to cookies ensures they are not opened by any unwanted scripts. The Secure and HttpOnly attributes help do this.
As you are deploying new configurations on systems. Scaling up or scaling down. Or because of some unknown reason. Observability helps backend developers understand what's broken. And what needs work to improve efficiency. There are three major tiers of observability; logging, metrics, and monitoring.
All kinds of data can come flowing in from the operating system, cloud, and application. And people are looking through all those data; developers, operations team, and security team.
But a developer can't possibly use all of the information flowing in. They have to have filters. In the case of developers, they have filters just for data and information about debugging. The filter can be set up like a dashboard or some form of accessing all of the data that the devs can take a look at just the information they need. Which is a core part of an observability solution. you to understand what is going on. This is what observability is.
The data also needs to be externalized or exposed so the developers can access and give new insights. Operations teams might need to know more about the degradation of its system, or if something is failing, or maybe your database is full, and you need to know more information on how to fix it. The ops team needs to be getting data from different systems and filter out to a dashboard or some interface. They will be looking into the operating system and CPU usage. They could have a dashboard created with security teams to identify a threat ID, or maybe a customer ID. Perhaps they want to investigate a potential threat identified. Security teams need to know what is happening the second something actually happens. This is where monitoring comes in, having automated alerts that can go out and tell all of these different groups about specific things that they might look into. These groups need to know immediately when a problem happens. So a good observability solution should have the ability to externalize the data.
So when your dev team may be relaxing or resting, they can set up a chatbot to alert them. The operations team may use something like a pager to start working right away in the event of an alert. And finally, some custom dashboards or third-party tools the security team can use to know exactly when something goes down. Having multiple clouds, on-premise systems, and data coming directly from users. Requiring you to understand what is going on. This is what observability is.