Greetings, fellow engineers! We're back with another issue of Level Up Coding’s newsletter!

In today’s issue:

• How Session Management Powers Secure Interactions

• What is Domain-Driven Design? How Does it Work? (Recap)

• SemVer Explained in Very Simple Terms (Recap)

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

Read time: 6 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.

What is Domain-Driven Design? How Does it Work? (Recap)

Domain-driven design is a software development approach that excels at providing an alignment between domain experts and developers, bridging the software's functionalities directly with the business's needs.

There are many components and concepts to DDD, below are some of the main concepts:

• Bounded contexts: This is a logical boundary in which the terms are consistent. The ubiquitous language bridges technical and business communication within this context. It allows everyone to speak the same language, which is one of the most powerful benefits of DDD.

• Entities and value objects: Entities are objects that have a distinct identity that runs through time & different states while value objects describe a characteristic but lack a conceptual identity.

• Aggregates: They provide a mechanism to manage & enforce data integrity within a set of related domain objects.

Check out the full post here for an expanded explanation including the advantages, disadvantages, and use cases, as well as an animated visual of DDD

SemVer Explained in Very Simple Terms (Recap)

Semantic versioning is a standardized way to communicate software upgrades.

It categorizes changes into three buckets:

🔴 Major: Contains breaking changes that require users to upgrade their code or integration.

🟢 Minor: Changes are backward-compatible. Typically extends functionality or improves performance.

🟣 Patch: Contains bug fixes that don’t change existing functionality.

Pro tip: A simplified framework for thinking about SemVer is “Breaking.Feature.Fix”.

SemVer provides an easy and clear way to communicate changes in software, which helps manage dependencies, plan releases, and troubleshoot problems.

For a simple visual of SemVer, see here

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:

• How structured is your data?

• How often will the schema change?

• What type of queries do you need to run?

• How large is your dataset and do you expect it to grow?

• How large is each record?

• What is the nature of the operations you need to run? Is it read-heavy or write-heavy?

• Which databases do your team have experience with?

For a diagram that visually depicts different types of databases, as well as an easy-to-understand explanation of each, check it out here

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

Join us again next week where we’ll explore the n-layered architecture, local area networks, the publish/subscribe messaging pattern, and SQL injections.