Session state is a concept in the software applications to share a user-specific data across multiple actions or requests during a single user session. User session can contain:

- User authentication information

- User preferences

- Form data, navigation history, shopping cart contents or any other application state, that user do not want to lose

- Temporary data

- Security tokens

## **Client Session State**

It is a practice to store session to the browser cookies or localStorage.

- ✅ Reducer server load. Do not need to share the data between the requests. Reduces memory footprint.

- ✅ Scalability. When server is stateless you can scale it horizontally.

- ✅ Simplified Session management. Frontend developer controls session timeouts and session data.

- ❌ Security risk. Sensitive data may be expose to the XSS attacks. Sensitive daa must be encrypted.

- ❌ Data integrity. User can modify session data. All data and server requests must be validated.

- ❌ Cross device usage. Session data is available only per one device. You can sync session data across devices, but it comes with a cost.

- ❌ Privacy issues. Regulations such as GDPR require explicit consent from user. It adds additional complexity and impacts the user experience.

## **Server Session State**

It is a practice to store session on the server side.

- ✅ Security. Sensitive data is kept on the server, which is harder for an attacker to manipulate data.

- ✅ Data Integrity. Server can validate and manage data without relying on untrusted client.

- ✅ When session is kept in memory, it is fast to resolve and update the session. Also you do not need to serialize and deserialize the session data, if you are keeping it in memory.

- ❌ Scalability. If you want to scale the server in case of high load, this can cost more, than to scale a stateless server. More complex scalability patterns must be applied depending on where session data is kept.

- ❌ If session is kept in memory, that Availability becomes very important. If server is down, user will lose his session.

## **Database Session State**

- ✅ Persistance. The user session data will survive server crashes and restarts.

- ✅ Scalability. It allows data to be stored and accessed in centralized manner. This is beneficial for a scaled instances of the same application.

- ✅ Security. Databases can provide out of the box features for encryption, access control and audit trails.

- ✅ Data Integrity. Data is managed centralized.

- ❌ Performance overhead . Retrieving data from the database costs more, that from the in memory object.

- ❌ Increased complexity. Maintain session data in the database, requires additional database configuration, connection management and abstractions resolving this data.

- ❌ Dependency. Database becomes a critical dependency for an application to operate. Database is made a SPOF (Single Point of Failure). Database performance becomes critical for an system availability.

Session State

Model View Controller is a well known pattern, which was described in the late 1970s. Since then, it is widespread architectural pattern, which influenced many frameworks and applications. For example in Java's well known framework [Spring](https://spring.io/guides/gs/serving-web-content) has element which is called **`@Controller`**, which represents a group of endpoints to handle input. Laravel is a PHP framework which is based on the MVC architecture.

MVC implies separation of concerns, where each element is responsible for a specific role.

**Model** - Model is responsible for managing data, business logic, business rules. Commonly used pattern, Domain Model, perfectly fits into MVC. Model is represented in the user interface(UI). UI in MVC is View.

**View** - View is responsible only for a rendering of a model. It can be a single template or by UI framework (library) rendered HTML. In MVC UI layer must not contain business logic, routing, orchestration, database querying. Only rendering the model representation. All these concerns are handled by a Controller element.

**Controller** - Controller accepts input, queries domain model object from a Model, calls services(notifications, logging, mutates data, queries other data sources). Prepares model for the UI, gets the View element. Combines View with the Model and returns HTML to the user.

Separation of an application code to different elements, has multiple benefits:

- each element can be tested in isolation, without a big effort. You can test your Model and View as a pure function. Model can be a complex component, with thousands of business rules and interrelated domain entities logic. Defining and testing those can become challenging. If you will add another layer of complexity, testing it in the presentation layer, you will lose the ability to test or to maintain tests.

- The concerns are fundamentally different. In enterprise applications, separate roles of employees are developing separate layers. For example business analysts will define the domain and business rules. UI developer will develop UI components/views to render a model. Backend developer will manage input to the controller.

- Having separate View from Model layers provides a possibility to implement different representations for different user groups. For example front office with customers, and back office with the employees working on a product, will have different representation of the Model and different application capabilities.

Since the 1970 pendulum swings from the server rendered application to the client rendered application (SPA, single page application), back and forth. MVC is not always applicable, though it even not always can be applied. This architectural pattern must be used to maintain application complexity. If the application is very small and there is no plans to grow this application, the MVC is a complexity itself, that needs to be managed. The majority of the internet is simple representational pages, created with Wordpress on PHP with a help of UI style utils/components like bootstrap and wordpress PHP plugins. On the other side enterprise application with a terabytes of data and millions of users with myriads of roles/privileges/use cases which you (as a developer/architect) need to handle.

MVC is about the separation of concerns, this means that you need to work hard to enforce it. Enforcing the separation can become challenging. On one hand you have requirements for complex interface, where developer wants to include the domain logic in the representation. On another hand you have a requirement to isolate business/domain logic from the representation. Which is possible, but it can become difficult, if incorrect abstraction is used. This separation can fail if:

- there is not architectural governance in the development process.

- developer will chose the environment, which is know for him. If he needs to switch tools/programming languages/repositories, most likely he will avoid it and mix the concerns.

- tools provided for developers are flexible enough to mix concerns. React with JSX, as an example, is the most powerful templating language for HTML (comparing to mustache, pug or others).

- time constraints are dictating the technical decision.

- current architecture does not support (or the complexity is too high to implement in other environment/tool/place) the required feature to be implemented in the Controller or Model.