How a Chat Application Works

When you use Chahua, several parts of the application work together. You do not need to understand their code yet. Start with the job each part performs and how information moves between them.

The Main Parts

A client is an application a person uses to interact with Chahua. The PWA is one client; the Flutter app is another. In this book, frontend usually means the user-facing part of the PWA: its screens, buttons, forms, and local application state. These and other recurring terms are defined in the glossary.

The backend is a shared service used by every client. It identifies who is making a request, checks what they are allowed to do, applies Chahua’s rules, reads or changes stored information, and returns a result.

The database stores information that must remain available, such as users, chats, and messages. Clients do not access it directly. They ask the backend, and the backend decides what may be read or changed.

The basic flow often looks like person → client/frontend → backend → database. Results travel back in the other direction.

Requests and Responses

Many actions use an HTTP request and response. HTTP is a standard way for applications to exchange information: one side sends a request and the other sends a response. The client asks the backend to do something, then waits for an answer.

For example, opening a chat may cause the PWA to request its recent messages. The backend checks that the person may view the chat, reads the messages from the database, and sends them back. The PWA stores the result in its local state and displays it.

Real-Time Events

A chat application also needs updates that arrive without repeatedly asking for them. Chahua keeps a WebSocket connection open between a client and the backend. The backend uses this connection to send real-time events, such as an event announcing that a new message was created.

HTTP requests are useful when a client initiates an action. WebSocket events are useful when the backend needs to tell connected clients that something has changed. The WebSocket does not replace the API or database; it helps clients stay up to date.

A Message’s Journey

When you send a message from the PWA:

1. You enter text and select Send.
2. The frontend sends an HTTP request containing the message and chat information.
3. The backend identifies the sender and checks that the action is allowed.
4. The backend stores the message in PostgreSQL.
5. After the database change succeeds, the backend returns a response and sends WebSocket events to connected recipients.
6. Each client updates its local state and screen to show the message.

Real applications add details such as errors, retries, permissions, attachments, notifications, and temporary loading states. Keep the simpler journey above as your starting model.

A Map for the Rest of the Book

When exploring a feature, ask:

• What does the person see or do in the client?
• What request or real-time event crosses the client-backend boundary?
• What rule does the backend apply?
• What information is read or stored?
• How does the result reach every relevant client?

This journey shows how information moves through Chahua. The next chapter looks more closely at what each part owns, where application state lives, and how clients stay synchronized with the backend.