Backend fundamentals

The backend side of a system is one or more applications running on machines that are commonly referred to as servers. The purpose of these applications is to serve requests coming from other applications—clients—and execute the necessary steps to accomplish the given request (validate the input, verify the requester's permissions, query and update rows in the database, run algorithms and workflows, and, at the end, return a response that the client side can then use to determine how to proceed.     

The backend side of a project is like the soil in a flower field—if the soil is healthy, it enables a flourishing field with lovely flowers. However, if the soil is dry and not taken care of, the flowers will die and the field will cease to exist.

In our case, the field is the backend server and the flowers are our users—the backend needs to be reliable, secure, fast, and scalable in order to support many happy users and to create a successful product.

The world of backend development is extensive — there are a vast amount of programming languages and technologies that you can choose from. Each of them looks at this world from a slightly different angle, enabling different targets. For example, C# is a very powerful language that comes with plenty of handy tools, JavaScript allows you to write the backend and the frontend using the same programming language, and Python is suitable for systems based on math and complex algorithms.

Fortunately, whatever the technology of choice is, its interface to external systems will follow the same protocols as other backend systems — HTTP and JSON, which allow the creation of RESTful APIs. This enables strict separation of concerns between the backend and the frontend — each of them can be created using a different set of technologies but they will still be able to communicate flawlessly.

Hypertext Transfer Protocol 

Hypertext Transfer Protocol (HTTP) is the foundation of communication on the WWW. It defines the format of messages and the way they are transmitted between the client and the server.

HTTP has two sides to communication — the client and the server. On web applications, the client is the user's web browser and the server is the backend server. Communication happens when the client creates a message called an HTTP request, sends it to the server, and the server, in turn, responds with an HTTP response, as shown in the following diagram:

Each HTTP request consists of a few pieces of information:

• URI: The web address or IP address that identifies the server. For example, http://example.com or http://192.168.0.1.
• Method: The action that should be taken upon the requested resource. For example, GET indicates data retrieval and POST indicates data creation.
• Body: Contains the data to be sent to the server, if any. The most popular data format for HTTP requests is JSON but, generally, data can be formatted in any format that the server understands.
• Headers: An optional set of metadata key-value pairs that add information to a request.

The server retrieves this request, executes related logical steps (commonly known as business logic), and forms an HTTP response to be sent back to the client. This response includes a few details:

• Status code: A three-digit integer that describes the result of the request. For example, 200 means OK, 500 means there was an error in the server, and 404 means the requested resource was not found.
• Body: The data sent back from the server, if any. As with the request body, JSON is the common data format, but any other format is valid as well.
• Headers: An optional set of metadata key-value pairs that add information about the response.

HTTP is a stateless protocol

The HTTP protocol is a stateless one. This means that every HTTP request the server receives is independent and does not relate to requests that came prior to it. For example, imagine the following scenario: a request is made for the first ten user records, then another request is made for the next ten records.

On a stateful protocol, the server remembers each client position inside the result-set, and therefore the requests will be similar to:

• Give me the first ten user records
• Give me the next ten records

On a stateless protocol, the requests will be a bit different. The server doesn't hold the state of its client, and therefore the client's position in the result-set needs to be sent as part of the requests:

• Give me user records on index 1 to 10
• Give me user records on index 11 to 20

The slight difference between these examples represents the different approaches. On stateful protocols, you assume that the server knows everything about the previous requests, while on a stateless protocol you assume the opposite—the server doesn't know anything about the previous requests, which is why you send all the necessary information with each and every request.

On the one hand, this makes web service development more challenging, since creating fast, stateless service is not an easy task. On the other hand, this enables services to scale out quickly and support millions of users rather easily.

HTTP/2

HTTP was created by Sir Tim Berners-Lee, the founder of the World Wide Web, back in 1989. The first version, HTTP 1.0, was introduced in 1996, followed by HTTP 1.1, which was introduced in 1997. HTTP 1.1 is still the most common version of HTTP out there.

In May 2015, HTTP/2 was released, which provided several improvements and enhancements to the old HTTP 1.1 protocol, such as server-to-client push messages and binary data support, to name just a couple. Ever since, it has been adopted by many websites and is slowly becoming the standard version of choice for websites.

Representational State Transfer

Representational state transfer (REST) is an architectural style for resource-oriented services. It is used by most web applications today to standardize communication between the client and the server. If HTTP was the spoken language, REST would be a set of rules for that language.

REST-based web services, also known as RESTful APIs, have a few constraints they need to follow:

• Consistent interface: Every entity is a resource that will have a unique endpoint— a unique base URL. All operations on a resource will be available via that URL.
• URL and HTTP methods: When a resource URL is combined with an HTTP method, it describes an operation performed on the resource. For example, GET means retrieving data, POST means creating data, and DELETE means deleting data.
• Statelessness: Just like the HTTP protocol, RESTful services are stateless. This means that each request is independent and information regarding previous requests is never used.
• Cacheable: For each response, the server defines whether it is cacheable or not. Once a response is set as cacheable, the client caches it and uses the data from the cache instead of requesting it from the server again and again.

For example, in an application that manages students, we could have the following services:

URL	HTTP Method	Description
/students	GET	Retrieve all students
/students	POST	Create a new student
/students/123	GET	Retrieve student with ID 123
/students/123	PUT	Update student with ID 123
/students/123	DELETE	Delete student with ID 123

REST has become the de facto style of communication between the backend and the frontend. This is especially because it is a simple concept, yet very powerful — it makes the backend understandable to other developers and simple to modify and scale, and supports multiple types of clients, including web and mobile.

ASP.NET Core

ASP.NET Core is a free, open-source web framework developed by Microsoft. It provides features that enable building the backend for modern web applications, as well as web APIs. The programming language that is used for the development of ASP.NET Core is C# or any other .NET-based programming language.

ASP.NET Core is a redesign of the popular ASP.NET Model View Controller (MVC) and ASP.NET Web API frameworks. The result is a leaner and more modular framework that can run on the full .NET Framework on Windows and .NET Core on other platforms.

Both parts of the framework, MVC and Web API, help in creating modern web applications. MVC is for building traditional web applications in which rendering is done on the server-side, but also supports integration with modern JS libraries and client-side rendering. ASP.NET offers many web development features out of the box, such as security, data validation, deployment, and more. ASP.NET Web API is for creating RESTful web services that serve modern frontend applications, mobile apps, and any other endpoints.

ASP.NET Core is a popular choice but is definitely not alone in the world of backend development. It is similar to other frameworks such as Laravel (PHP), Spring (Java), Ruby on Rails (Ruby), Django (Python), and others. Each has its own advantages and disadvantages. I chose ASP.NET Core for this book as it is one of the top frameworks out there, runs on the powerful C# language, and has wonderful IDE support.