Messaging System Backend

The app supports real-time messaging, where users can send personal messages to each other, or create group chats to have conversations between multiple team members.

📘 Backend Documentation: Group and Personal Chat System

Overview

This backend supports:

  • Personal and group messaging

  • Real-time-like polling with intelligent refresh

  • Group creation via modal with user search

  • Chat UI state preservation via query param (currentChatId)

  • Profile image, message state (sent, delivered, read)

  • PostgreSQL ENUMs and relationships via SQLAlchemy


🗂️ Database Models

User

Standard user model with profile data. Fields typically include:

id: Integer, primary key
username: String
first_name: String
last_name: String
image_route: String

MessageState ENUM


Chat

Represents a personal or group chat.

ChatUser

Many-to-many link table between Chat and User.


Message


GroupMeta (if implemented)

Extra info for group chats:


🔧 Routes and Views

1. POST /send-message

Sends a message to either a personal or group chat.

  • Requires: chat-id-field, message-input

  • Optional: is-personal-chat-field to distinguish chat type


2. GET /get-chat-messages/<chat_id>

Fetch messages from a personal chat.


3. GET /get-group-chat-messages/<chat_id>

Fetch messages from a group chat + metadata.


4. GET /search-global?q=...

Global user search (used by group creation modal)


5. POST /create-group-chat

Creates a new group with selected users.


6. POST /remove-user-from-group

Removes a user from a group. Optionally restrict to group admins.


📦 Supporting Utilities

verify_chat_access(user_id, chat_id)

Confirms user belongs to chat (used in all fetch/send routes).

serialize_messages(messages)

Returns message dictionaries with:

serialize_users(users)

Returns minimal public info for chat members.


🛡️ Auth / Session

Use verify_session(request) on routes to protect endpoints. This likely wraps cookie/session logic and sets request.user.


🧠 Notes

  • Message polling is client-side every ~3.5s, but the backend performs no heavy computation, so it scales acceptably for small/medium apps.

  • Use ETag or Last-Modified headers in future if backend cache validation is needed.

  • Add pagination or lazy-load if you expect message history to grow large.

Last updated