docs: Improve Client-Session docs

client-session/README.md

@@ -1,51 +1,33 @@
 ---
-title: Client Session Pattern
-category: Architectural
+title: Client Session
+category: Behavioral
 language: en
 tags:
-- Decoupling
+  - Session management
+  - Web development
 ---
 
-## Name
+## Also known as
 
-[Client Session pattern](https://dzone.com/articles/practical-php-patterns/practical-php-patterns-client)
+* User session
 
 ## Intent
 
-- Create stateless servers that removes the problem of clustering, as users can switch between servers seamlessly.
-- Makes data more resilient in case of server fail-over.
-- Works well with smaller data sizes.
+The Client Session design pattern aims to maintain a user's state and data across multiple requests within a web application, ensuring a continuous and personalized user experience.
 
 ## Explanation
 
 Real-World Example
 
-> You're looking to create a data management app allowing users to send requests to the server to 
-> modify and make changes to data stored on their devices. These requests are small in size and the 
-> data is individual to each user, negating the need for a large scale database implementation. 
-> Using the client session pattern, you are able to handle multiple concurrent requests, load 
-> balancing clients across different servers with ease due to servers remaining stateless. You also 
-> remove the need to store session IDs on the server side due to clients providing all the 
-> information that a server needs to perform their process.
+> You're looking to create a data management app allowing users to send requests to the server to modify and make changes to data stored on their devices. These requests are small and the data is individual to each user, negating the need for a large scale database implementation. Using the client session pattern, you are able to handle multiple concurrent requests, load balancing clients across different servers with ease due to servers remaining stateless. You also remove the need to store session IDs on the server side due to clients providing all the information that a server needs to perform their process.
 
 In Plain words
 
-> Instead of storing information about the current client and the information being accessed on the 
-> server, it is maintained client side only. Client has to send session data with each request to 
-> the server and has to send an updated state back to the client, which is stored on the clients 
-> machine. The server doesn't have to store the client information.
-> ([ref](https://dzone.com/articles/practical-php-patterns/practical-php-patterns-client))
+> Instead of storing information about the current client and the information being accessed on the server, it is maintained client side only. Client has to send session data with each request to the server and has to send an updated state back to the client, which is stored on the clients machine. The server doesn't have to store the client information. ([ref](https://dzone.com/articles/practical-php-patterns/practical-php-patterns-client))
 
 **Programmatic Example**
 
-Here is the sample code to describe the client-session pattern. In the below code we are first 
-creating an instance of the Server. This server instance will then be used to get Session objects 
-for two clients. As you can see from the code below the Session object can be used to store any 
-relevant information that are required by the server to process the client request. These session 
-objects will then be passed on with every Request to the server. The Request will have the Session 
-object that stores the relevant client details along with the required data for processing the 
-request. The session information in every request helps the server identify the client and process 
-the request accordingly. 
+Here is the sample code to describe the client-session pattern. In the below code we are first creating an instance of the Server. This server instance will then be used to get Session objects for two clients. As you can see from the code below the Session object can be used to store any relevant information that are required by the server to process the client request. These session objects will then be passed on with every Request to the server. The Request will have the Session object that stores the relevant client details along with the required data for processing the request. The session information in every request helps the server identify the client and process the request accordingly.
 
 ```java
 public class App {
@@ -96,19 +78,39 @@ public class Request {
 
 Use the client state pattern when:
 
-- Processing smaller amounts of data to prevent larger requests and response sizes.
-- Remove the need for servers to save client states. Doing so also removes the need to store session IDs.
-- Clustering is an issue and needs to be avoided. Stateless servers allow clients to be easily distributed across servers.
-- Creates resilience from data losses due to server fails.
+* Web applications requiring user authentication and authorization.
+* Applications needing to track user activities and preferences over multiple requests or visits.
+* Systems where server resources need to be optimized by offloading state management to the client side.
+
+## Known Uses
+
+* E-commerce websites to track shopping cart contents across sessions.
+* Online platforms that offer personalized content based on user preferences and history.
+* Web applications requiring user login to access personalized or secured content.
 
 ## Consequences
 
-- The server is stateless. Any compute API will not store any data.
-- Struggles to deal with large amounts of data. Creates longer send and receive times due to larger amounts of session data to manage.
-- Security. All data is stored on the client's machine. This means that any vulnerabilities on the clients side can expose all data being sent and received by the server.
+Benefits:
 
+* Improved server performance by reducing the need to store user state on the server.
+* Enhanced user experience through personalized content and seamless navigation across different parts of the application.
+* Flexibility in managing sessions through various client-side storage mechanisms (e.g., cookies, Web Storage API).
+
+Trade-offs:
+
+* Potential security risks if sensitive information is stored in client sessions without proper encryption and validation.
+* Dependence on client-side capabilities and settings, such as cookie policies, which can vary across browsers and user configurations.
+* Increased complexity in session management logic, especially in handling session expiration, renewal, and synchronization across multiple devices or tabs.
+
+## Related Patterns
+
+* Server Session: Often used in conjunction with the Client Session pattern to provide a balance between client-side efficiency and server-side control.
+* [Singleton](https://java-design-patterns.com/patterns/singleton/): Ensuring a single instance of a user's session throughout the application.
+* [State](https://java-design-patterns.com/patterns/state/): Managing state transitions in a session, such as authenticated, guest, or expired states.
 
 ## Credits
 
-- [Dzone - Practical PHP patterns](https://dzone.com/articles/practical-php-patterns/practical-php-patterns-client)
-- [Client Session State Design Pattern - Ram N Java](https://www.youtube.com/watch?v=ycOSj9g41pc)
+* [DZone - Practical PHP patterns](https://dzone.com/articles/practical-php-patterns/practical-php-patterns-client)
+* [Client Session State Design Pattern - Ram N Java](https://www.youtube.com/watch?v=ycOSj9g41pc)
+* [Professional Java for Web Applications](https://amzn.to/4aazY59)
+* [Securing Web Applications with Spring Security](https://amzn.to/3PCCEA1)