Welcome back! In the previous lesson, we explored the importance of a robust system prompt and how it guides the behavior of our chatbot. Now, we will delve into the next step of our journey: building the Chat Manager. This lesson will focus on the model layer of the MVC (Model-View-Controller) architecture, which is crucial for organizing and managing data in a structured way. The ChatManager class will be the core component of our model layer, responsible for managing chat data effectively. By the end of this lesson, you will understand how to create, manage, and retrieve chat data using the ChatManager class.

Before we dive into building the ChatManager, let's take a moment to understand two fundamental Symfony concepts: RequestStack and Dependency Injection.

RequestStack is a Symfony component that manages a stack of Request objects. In web applications, each HTTP request creates a Request object containing information about the current request, such as URL parameters, form data, cookies, and session data. The RequestStack keeps track of these requests, especially in complex scenarios where you might have nested requests (like when using sub-requests for fragments or ESI).

The primary reason we use RequestStack instead of directly accessing the session is to follow Symfony's best practices for dependency injection. By injecting RequestStack into our classes, we make them:

1. Testable: We can easily mock the RequestStack in unit tests
2. Flexible: The class doesn't depend on global state
3. Maintainable: Dependencies are explicit and clear

Dependency Injection (DI) is a design pattern where objects receive their dependencies from external sources rather than creating them internally. Instead of a class instantiating its own dependencies with new, those dependencies are "injected" into the class, typically through the constructor.

For example, instead of doing this:

We inject the dependency:

Symfony's Service Container automatically handles this injection for us. When we register our ChatManager as a service, Symfony sees that it needs a RequestStack and automatically provides it.

The ChatManager class is designed to handle the storage and management of chat data. In Symfony, we use the session component to store chat data across different requests. Sessions persist data on the server side between page loads, making them ideal for storing user-specific data like chat histories.

We'll start by setting up the class and then gradually add methods to handle chat creation, message addition, and conversation retrieval.

Let's begin by defining the ChatManager class and its constructor. The constructor accepts a RequestStack instance through dependency injection and initializes an empty array in the session to store all chat data.

In this setup, we store the RequestStack as a private property. Then, we retrieve the session object by calling $this->requestStack->getSession(). The session object provides methods like has() to check if a key exists and set() to store data. We initialize a chats array if it doesn't already exist. This structure allows us to efficiently manage multiple chats for different users, where the first key is the user_id, and the second key is the chat_id.

Next, we'll add the createChat method. This method is responsible for creating a new chat entry for a user. It takes three parameters: userId, chatId, and systemPrompt.

The createChat method retrieves the current chats from the session using $session->get('chats', []), where the second parameter [] is a default value returned if the key doesn't exist. It checks if the userId exists in the chats array, and creates a new entry if needed. Then, it initializes the chat with the provided systemPrompt and an empty array for messages, and saves the updated chats back to the session using $session->set().

Notice how we retrieve the session from RequestStack each time we need it. This ensures we're always working with the current session state.

To access a specific chat, we need the getChat method. This method retrieves a chat based on the userId and chatId.

The getChat method retrieves the chats array from the session and uses the null coalescing operator (??) to safely access the nested array, returning the chat data if it exists. The return type ?array indicates that this method can return either an array or null, which is useful when a chat doesn't exist.

Now, let's add the addMessage method. This method allows us to append messages to a chat. It requires the userId, chatId, role, and content of the message.

The addMessage method first retrieves the chat using getChat. If the chat exists, it appends the message to the chat's message array, retrieves the full chats array from the session, updates it with the modified chat, and saves it back to the session. This pattern of retrieving, modifying, and saving is important when working with session data because the session needs to be explicitly updated to persist changes.

Finally, we'll implement the getConversation method. This method returns the entire conversation, including the system prompt and all messages.

The getConversation method retrieves the chat and constructs an array starting with the system prompt, followed by the chat messages. If the chat does not exist, it returns an empty array. The array_merge function is used to combine the system prompt with the messages. This structure is particularly useful when sending the conversation history to an AI service, as most AI APIs expect the conversation to start with a system message.

In this lesson, we explored the ChatManager class and its role in managing chat data within the model layer of our application. We learned about important Symfony concepts like RequestStack and dependency injection, which help us write clean, testable, and maintainable code. We discovered how to create and manage chats using Symfony's session component, add messages, and retrieve chat histories. The ChatManager is a crucial component for organizing chat data, ensuring that our chatbot can handle multiple conversations efficiently.

By using RequestStack and dependency injection, our ChatManager is decoupled from global state, making it easier to test and maintain. The session component provides a reliable way to persist data across requests, allowing our chatbot to maintain conversation context throughout a user's interaction with the application.

As you move on to the practice exercises, take the opportunity to experiment with modifying and extending the ChatManager functionality. This hands-on practice will reinforce the concepts covered in this lesson and prepare you for the next steps in our course. Keep up the great work, and I look forward to seeing your progress!