Backend для публічного веб-додатку з модерацією текстових повідомлень

Технічне завдання (ТЗ)

Бажаний термін виконання - 24 години (ТЕРМІНОВЕ!)

Backend для публічного веб-додатку з модерацією текстових повідомлень

1. Загальний опис

Необхідно розробити бекенд для веб-додатку, який працює в одному екземплярі, розміщеному у публічному просторі (екран / термінал / інсталяція).

Клієнтський додаток надсилає короткі текстові повідомлення (аналог SMS), які проходять модерацію та після схвалення відображаються на екрані.

Бекенд встановлюється на окремий ПК та працює:

в локальній мережі разом із клієнтським додатком;

або з доступом через інтернет (опційно).

2. Архітектурні та технологічні вимоги

2.1 Загальні вимоги

Технології мають бути поширені та легко підтримувані.

Заборонено використання екзотичних або вузькоспеціалізованих фреймворків, які ускладнюють передачу проєкту іншому розробнику.

Рішення повинно бути зрозумілим сторонньому розробнику без тривалого онбордингу.

2.2 Деплой та підтримка

Обовʼязково:

можливість швидкого розгортання системи;

можливість простого оновлення.

Допустимі та бажані варіанти:

зберігання коду в GitHub;

деплой через Docker / Docker Compose;

мінімальна кількість ручних кроків при оновленні.

Бекенд повинен запускатися:

на звичайному ПК (Windows / Linux);

без залежності від специфічної серверної інфраструктури.

3. Ролі та доступи

3.1 Клієнтський додаток

Доступ:

надсилання повідомлень;

отримання списку схвалених повідомлень;

отримання системного статусу.

Авторизація:

не обовʼязкова або реалізується через простий механізм (API-key, токен).

3.2 Адмінка (модерація)

Єдина роль — модератор.

Реалізація адмінки — на вибір розробника:

окрема веб-адмінка;

готова адмін-панель;

або інший стандартний підхід.

❗ Наявність окремого публічного API для адмінки не є обовʼязковою.

Головна вимога — функціональність та простота підтримки.

Функції модератора:

перегляд усіх повідомлень;

зміна статусу повідомлення;

редагування тексту перед схваленням;

керування системним станом додатку.

4. Дані та модель повідомлення

4.1 Повідомлення (Message)

Поле    Тип    Опис

id    string / UUID / int    Унікальний ідентифікатор

original_text    string    Оригінальний текст від клієнта

approved_text    string | null    Текст після модерації

status    enum    pending / approved / rejected

created_at    datetime    Дата та час отримання

reviewed_at    datetime | null    Дата модерації

ai_checked    boolean    Чи проходив перевірку ШІ

ai_result    string | null    Коментар або результат перевірки ШІ

5. Системний стан

5.1 SystemState

Поле    Тип    Опис

is_blocked    boolean    Чи заблокований екран

system_message    string    Системне повідомлення

updated_at    datetime    Дата останньої зміни

6. API для клієнтського додатку (обовʼязкове)

6.1 Надсилання повідомлення

POST /api/messages

{

  "text": "Коротке текстове повідомлення"

}

{

  "success": true,

  "message_id": "12345"

}

6.2 Отримання схвалених повідомлень

GET /api/messages/approved

{

  "messages": [

    {

      "id": "123",

      "text": "Схвалений або відредагований текст",

      "created_at": "2026-01-08T10:15:00Z"

    }

  ]

}

Повертаються виключно повідомлення зі статусом approved.

6.3 Отримання системного статусу

GET /api/system/status

{

  "is_blocked": true,

  "system_message": "Тимчасово недоступно"

}

7. Автоматична перевірка повідомлень через ШІ (опційно)

Автоматична перевірка текстів через OpenAI API.

Результат перевірки зберігається та доступний модератору.

ШІ не приймає фінального рішення, лише допомагає модерації.

8. Обмеження та захист

Обмеження довжини повідомлення (рекомендовано до 160–240 символів).

Базовий захист від спаму (rate-limit).

Валідація вхідних даних.

9. Очікуваний результат (MVP)

Працюючий бекенд з мінімальним API для клієнта.

Проста адмінка з однією роллю.

Швидке розгортання на ПК.

Можливість легко передати підтримку іншому розробнику.

Готовність до роботи як у локальній мережі, так і через інтернет.