This week’s issue brings you:

READ TIME: 4 MINUTES

How Session Management Powers Secure Interactions

Imagine having to reintroduce yourself every time you speak to someone.

Tiresome, isn't it?

Our applications experience the same dilemma. They need a way to recognize the users interacting with them.

This is where session management steps in.

Session Management is the process of securely handling multiple requests to a web-based application from a single user or entity.

Essentially, it’s the process of recognizing users across multiple requests on web applications, ensuring that interactions can flow without constant reintroductions.

Why is it Important?

There are two primary reasons that session management is a fundamental component of web applications; maintaining user state, and security.

HTTP is a stateless protocol, meaning each request from a client to a server is treated as a new, standalone request with no memory of previous interactions.

Session management provides a way to retain user-specific data across multiple requests.

As for security, proper session management ensures that the user is who they say they are throughout the session's lifespan, providing protection against unauthorized access, CSRF attacks, session hijacking, and more.

The Mechanics Behind the Scenes

There are several techniques for implementing session management, however, some are more secure than others.

Today, we'll be covering the three most prominent techniques throughout the industry, all of which are considered to be highly secure approaches.

Cookies

Cookies are small pieces of data sent from a server and stored on a user's web browser while the user is browsing. They are the most common session management tool.

Upon a successful login, the server sends a unique session ID in a cookie. With each subsequent request, the browser sends this cookie, reminding the server that they've met before.

Token-based Management

With the rise of single page applications (SPAs), mobile apps, and distributed systems where maintaining state on the server can be challenging and inefficient, modern applications have embraced tokens.

Post-login, the server dispatches a signed token, often in the form of a JSON Web Token (JWT), to the client.

The client then stores the token, often in a cookie.

The token then accompanies each request, usually in the HTTP headers, acting as proof of the user's identity.

Server-side Management

On the other side of the coin, we have server-side session management.

It’s a more traditional approach where the session state is maintained on the server. Whether in databases, in-memory storages, or file systems, session data resides securely server-side.

The client, in this scenario, only holds a unique identifier, rather than the session state being stored on the client.

Server-side management has been the standard approach for many years and is still highly prevalent, particularly in legacy systems and certain types of applications.

However, with the architectural trends of the past decade, token-based management has become the most common approach in modern applications and systems.

Session management, though often operating in the background, stands as a cornerstone in ensuring the fluidity and security of our applications and systems. Proper session management not only plays a role in creating smooth user experiences. In an era marked by cyber threats, it’s a major pillar of keeping our applications and systems secure.

API Gateway vs Load Balancer — What's the Difference? (Recap)

API gateways focus on request management and microservice communication, while Load balancers focus on traffic distribution and server load management.

API gateways operate at the application layer (L7), while Load balancers can operate at both transport (L4) or application (L7) layers.

API gateways offer features like routing, rate limiting, authentication, service discovery, parameter validation, circuit breakers, and more, while Load balancers handle traffic distribution.

API gateways are ideal for microservice architectures needing centralized API management, while Load balancers are essential for applications requiring high availability, distributing traffic across multiple servers.

Check out the full post here for an extended explanation.

What is Connection Pooling, and How Does it Work?)

Handling API requests often involves querying the database. Creating a new connection for each API call introduces unnecessary overhead.

Connection pooling mitigates this by reusing existing connections and reducing the overhead of establishing and closing connections.

This leads to faster response times and reduced resource consumption, making connection pooling a key technique for optimizing resource management and enhancing application performance.

So how does it work?

Connection pooling maintains a cache of reusable database connections, avoiding the need to create a new one each time.

When a connection is needed, an available connection from the pool is used, and when the task is completed, the connection is returned to the pool for future use.

See the full post here for a more detailed explanation, including key components and best practices.

SQL, NoSQL, or Something Else — How Do You Decide Which Database? (Recap)

The performance of your application can suffer if you choose the incorrect database type, and going back on a bad choice can be time-consuming and expensive.

There are several types of databases, each designed and optimized for specific use cases; relational, document, graph, columnar, time-based, key-value, and time-series, to name a few.

Considerations that should be made to choose the optimal database for your use case:

Check out the full post here for an overview of each database type.

That wraps up this week’s issue of Level Up Coding’s newsletter!

Join us again next week where we’ll explore and visually distill more important engineering concepts.