What is routing in Backend

Here, we ask ourselves simple questions. What is our intent ? Where do we want to go ? What do we want to do ?

In the simplest way, we map routes from the frontend to the backend. We can also say that we map the URL to the function that we want to execute on the backend.

Route is basically where you want to go in the server. It checks the mehtod, then route and forms a routing logic - this logic doesn't cache

For example, our intention is to fetch and the route is /users, the server will take our intent and the route and map it to the handler / set of instructions and return you the data of users.

Our /api/books is a static route, it is always the same and doesn't change. It is used to fetch all the books.

GET request to /api/books will return all the books.

We also have routes like /api/user/123 where 123 is the ID and is called the path parameter

/api/users/:id is :id is any kind of string and is called the dynamic path parameter

Query Parameters

Query parameters are used to filter or sort data. They are added to the end of the URL after a question mark ? and are in the form of key-value pairs. For example, /api/books?author=John will return all books written by John.

Let us take a better example,

/api/search?query=something, For this query the server will use the route /api/search to map to the handler

it is usually used in search boxes to send search queries to the backend if we want to sort it or something like that.

Nested routes

api/users/123/posts/456 is an example of the nested route. It is used for semantic meaning. and results in different semantic meanings

Route versioning is a common practice in making api endpoints where apis are versioned.

/api/v1/products/

Catch all routes

A catch all route is a fallback for requests that do not match any specific path. It is often used for 404 handling or for serving a default response when the requested route does not exist.

For example, we send requests to a route which the servers doesn't serve to api/v3/products

For a catch all route, send a /* where the * stands for any path.

Serialization and Deserialization

Serialization is the process of converting structured data into a format that can travel over the network and be understood by another system later. JSON is one of the most common formats because it is lightweight, text based, and language independent.

Let us assume that our frontend is in javascript and backend is in rust.

OSI Models

Applicatiion Layer
.
.
.
.
Physical Layer

Q) we have 2 machines in different locations connected over the internet, come up with a way to convert the data and make it language agnostic to let both systems communicate with each other

"Language agnostic" means that the data can be understood by both systems regardless of the programming language they are written in.

Therefore, we come up with a common standard here so that stuff is language agnostic... Here HTTP, WebSockets, gRPC, etc. are used.

Relational, Non relational

Serialization standards

JSON, XML, and YAML are all text based formats. Binary formats such as Protocol Buffers are often preferred when speed, size, and stricter schemas matter more than human readability

JSON is the most popular serialization format, it is human readable and widely supported across programming languages. It is also lightweight and easy to parse, making it a good choice for web applications.

Binary format is a protocol buffer, it is more compact and faster to serialize and deserialize than JSON, but it is not human readable.

The entire flow where the data is converted into a standard format and sent to the backend is called serialization and the process of converting it back to the original format is called deserialization.

Authentication and Authorization

At one point in time, or right now, you must have been a School/College student and you must have had a student ID card. The simple way to understand Authentication and Authorization is to think of it as a student ID card. The ID is used to verify your identity, which is authentication, and it also grants you access to certain resources - such as the library or something else, which is authorization.

In simple terms,

• Authentication - Who are you?
• Authorization - What can you do?

Authentication

Sessions -

HTTP emerged as the backbone and it was stateless by design. Useful for readable data and static websites.

Statelessness became a bottleneck when the web became dynamic, therefore, the web needed to be stateful where sessions came into play

A session provided a way for establishing temporary server side context for a user.

When a user was created, a session_id was created in a persistent storage in a database or in memory / redis then this, session_id was sent to the client as a cookie. All subsequent requests contained said cookie and enabled some kind of memory for the sake of the client. These sessions were shortlived and had an expiry date, Example 15 mins

• Initially this was File based, and obviously had scalability issues
• Later, sessions were stored in DBs, making them more scalable and capable of handling more users
• Now they are Distrubuted, redis and memcache in memory stores are used to store sessions, making them even more scalable and faster.

JWTs

Sessions solved state, but they introduced operational overhead at scale. That is where JWTs became popular.

JWT (JSON Web Token) is a stateless way to transfer claims between parties. It is a signed token that usually contains:

• Header (algorithm and token type)
• Payload (claims like userId, role, expiry)
• Signature (verifies integrity)

Because the token is self-contained, the server can validate it without looking up session state for every request.

Why teams use JWTs

1. Statelessness: no per-user session lookup on each request.
2. Scalability: easier horizontal scaling across many backend instances.
3. Portability: works well across APIs, mobile apps, and microservices.

JWT challenges

1. Token theft: if stolen, a bearer token can be reused.
2. Revocation difficulty: invalidating tokens before expiry needs extra infrastructure.
3. Payload misuse: developers sometimes put sensitive data in JWT payloads.

So in practice, many systems use a hybrid approach:

• Short-lived access token (JWT)
• Long-lived refresh token
• Server-side blocklist/allowlist when emergency revocation is needed

If you are building production auth for the first time, using a managed auth provider is often the safest choice.

Cookies

Cookies are key-value data stored by the browser and sent to the server with matching requests. For auth, the safest common pattern is:

1. User logs in.
2. Server sets an HttpOnly, Secure, SameSite cookie.
3. Browser automatically sends that cookie on later requests.

HttpOnly protects against direct JavaScript access, reducing XSS token theft risk.

Types of authentication

1. Stateful (session-based)
2. Stateless (token-based)
3. API Key
4. OAuth 2.0 (+ OpenID Connect for identity)

Stateful (Session-Based) flow

client -> credentials -> server -> session store -> session cookie -> subsequent authenticated requests

The server validates credentials, creates a session ID, stores session data (for example in Redis), and returns the session ID via cookie.

Pros:

1. Easy revocation and central control.
2. Mature model for web apps and admin panels.

Cons:

1. Needs shared session storage across instances.
2. Adds infrastructure complexity at scale.

Stateless (JWT-Based) flow

client -> credentials -> server -> signed token -> Authorization: Bearer <token>

The server validates credentials and signs a token. The client sends the token with each request.

Pros:

1. Great for distributed systems.
2. Less server-side lookup on each request.

Cons:

1. Harder token revocation.
2. Requires careful expiry and rotation strategy.

API Key-Based Auth

API keys are usually used for service-to-service or third-party integrations. The client includes a key in headers or query params, and the server validates it.

Good fit when:

1. You need simple machine-to-machine authentication.
2. You want scoped access to specific API capabilities.

Limitations:

1. API keys usually identify applications, not users.
2. They need rotation, rate limits, and secret management.

OAuth 2.0

OAuth solves the delegation problem: one app needs limited access to another app's resources without sharing the user's password.

Example:

Train app wants calendar access -> user grants consent -> train app receives token with scoped permissions

OAuth 2.0 introduced bearer tokens and clearer authorization flows.

Common grant types:

• Authorization Code (+ PKCE): recommended for web and mobile clients.
• Client Credentials: backend-to-backend communication.
• Device Code: limited-input devices.
• Refresh Token flow: renew access without re-login.

Important: OAuth is primarily for authorization, not user identity by itself.

OpenID Connect (OIDC)

OIDC is an identity layer built on top of OAuth 2.0. It adds an ID token (usually a JWT) so the client can verify who the user is.

Simplified OIDC flow:

1. Client redirects user to identity provider (for example, Google).
2. User signs in and grants consent.
3. Client receives authorization code.
4. Client exchanges code for access token + ID token.
5. Client validates ID token and starts user session.

When to use which authentication model

• Stateful sessions: traditional web apps, dashboards, SaaS admin tools.
• Stateless JWT: distributed APIs, mobile-heavy systems, microservices.
• OAuth 2.0: third-party delegated access to protected resources.
• OIDC: social login / SSO where user identity is required.
• API Keys: internal services, automation, and partner integrations.

There is no single best strategy for every system. Choose based on scale, revocation needs, client types, and security requirements.