Теорія випливає з практичного досвіду, але людський розум не завжди переконаний або впевнений на 100%, поки не спробує це сам. Теоретично я знаю про мікросервіси, знаю, як будувати додатки, що краще масштабуються, брокери, черги і так далі!
Але давайте насправді спроектуємо один. Створимо чат додаток як інструмент для комунікації в організації. Користувач типу адміністратора має мати можливість створювати облікові записи співробітників. Співробітник може увійти в систему і вести персональні чати з іншими співробітниками.
Вимоги до системи:
Явні функціональні вимоги
- Управління користувачами
Реєстрація користувача
Система повинна дозволяти новому користувачу зареєструватися з унікальними обліковими даними (наприклад, електронною поштою або ім'ям користувача).
Система повинна перевіряти, чи є обраний ім'я користувача або електронна пошта унікальними.
Система повинна зберігати інформацію профілю користувача.
Аутентифікація користувачів
Система повинна аутентифікувати користувачів за допомогою пароля.
Система повинна підтримувати токен доступу до кінця дня.
2. Управління розмовами
Створення розмови
Система повинна дозволяти користувачам створювати розмови, додаючи принаймні одного іншого користувача як учасника.
3. Обмін повідомленнями
Відправка повідомлень
Система повинна дозволяти користувачам надсилати текстові повідомлення в будь-якій розмові, в якій вони беруть участь.
Система повинна ставити мітку часу для кожного повідомлення і зберігати ідентифікатор відправника.
Отримання повідомлень
Система повинна доставляти вхідні повідомлення в реальному часі кожному учаснику розмови.
Система повинна дозволяти користувачам переглядати історію чатів для кожної розмови.
Статус повідомлень
Система повинна вказувати статус доставки повідомлення (наприклад, надіслано, доставлено, прочитано) для кожного повідомлення.
Неявні функціональні вимоги
- Система повинна запобігати відправці порожніх повідомлень.
- Показувати зелений круг проти імені користувача в списку користувачів, якщо користувач онлайн.
- Сортувати список користувачів за кількістю непрочитаних повідомлень від користувача, показувати кількість невідкритих повідомлень на бейджі.
- Якщо користувач офлайн, він повинен мати можливість завантажити повідомлення, коли відвідує вікно чату.
Нефункціональні вимоги
1. Вимоги до продуктивності
Час відгуку
Система повинна доставляти повідомлення отримувачам в середньому за 1 секунду за ідеальних мережевих умов.
Система повинна отримувати 10 останніх повідомлень на сторінку протягом 3 секунд при прокручуванні на попередню сторінку.
Масштабованість
Система повинна підтримувати максимальну кількість 10 тис. одночасних користувачів без помітного зниження продуктивності.
Затримка
Система повинна підтримувати середню мережеву затримку не більше 200 мілісекунд для доставки повідомлень у реальному часі.
2. Доступність та надійність
Час безвідмовної роботи
Система повинна бути доступною з 7:00 до 19:00 з 99,9% часу безвідмовної роботи протягом цього періоду.
Терпимість до відмов
98,61%, припускаючи, що система працює 12 годин на день і може бути недоступна протягом 10 хвилин.
3. Вимоги до безпеки
Захист даних та шифрування
Система повинна шифрувати всі дані користувачів під час передачі.
4. Підтримка та розширюваність
Якість коду
База коду системи повинна відповідати кращим практикам програмування та мати відповідну документацію для забезпечення легкості в обслуговуванні.
Логування та моніторинг
Система повинна мати можливості для реального часу логування та моніторингу для виявлення та діагностики помилок або проблем з продуктивністю.
5. Сумісність
Сумісність з платформами
Система повинна підтримувати основні операційні системи та браузери Chrome для робочих столів.
API для інтеграції
Система повинна надавати REST API, щоб в майбутньому можна було розширити її для мобільних додатків.
Теорія виникає з практичного досвіду, але людський розум не завжди переконаний або впевнений на 100%, поки не спробує це самостійно. Теоретично я знаю про мікросервіси, знаю, як будувати додатки, що краще масштабуються, брокери, черги і так далі!
Але давайте насправді спроектуємо один. Створимо чат-додаток як інструмент для комунікації в організації. Користувач типу адміністратора має мати можливість створювати облікові записи співробітників. Співробітник може увійти в систему і вести персональні чати з іншими співробітниками.
Вимоги до системи:
Явні функціональні вимоги
- Управління користувачами
Реєстрація користувача
Система повинна дозволяти новому користувачу зареєструватися з унікальними обліковими даними (наприклад, електронною поштою або ім'ям користувача).
Система повинна перевіряти, чи є обране ім’я користувача або електронна пошта унікальними.
Система повинна зберігати інформацію профілю користувача.
Аутентифікація користувачів
Система повинна аутентифікувати користувачів за допомогою пароля.
Система повинна підтримувати токен доступу до кінця дня.
2. Управління розмовами
Створення розмови
Система повинна дозволяти користувачам створювати розмови, додаючи принаймні одного іншого користувача як учасника.
3. Обмін повідомленнями
Відправка повідомлень
Система повинна дозволяти користувачам надсилати текстові повідомлення в будь-якій розмові, в якій вони беруть участь.
Система повинна ставити мітку часу для кожного повідомлення і зберігати ідентифікатор відправника.
Отримання повідомлень
Система повинна доставляти вхідні повідомлення в реальному часі кожному учаснику розмови.
Система повинна дозволяти користувачам переглядати історію чатів для кожної розмови.
Статус повідомлень
Система повинна вказувати статус доставки повідомлення (наприклад, надіслано, доставлено, прочитано) для кожного повідомлення.
Неявні функціональні вимоги
- Система повинна запобігати відправці порожніх повідомлень.
- Показувати зелений круг проти імені користувача в списку користувачів, якщо користувач онлайн.
- Сортувати список користувачів за кількістю непрочитаних повідомлень від користувача, показувати кількість невідкритих повідомлень на бейджі.
- Якщо користувач офлайн, він повинен мати можливість завантажити повідомлення, коли відвідує вікно чату.
Нефункціональні вимоги
1. Вимоги до продуктивності
Час відгуку
Система повинна доставляти повідомлення отримувачам в середньому за 1 секунду за ідеальних мережевих умов.
Система повинна отримувати 10 останніх повідомлень на сторінку протягом 3 секунд при прокручуванні на попередню сторінку.
Масштабованість
Система повинна підтримувати максимальну кількість 10 тис. одночасних користувачів без помітного зниження продуктивності.
Затримка
Система повинна підтримувати середню мережеву затримку не більше 200 мілісекунд для доставки повідомлень у реальному часі.
2. Доступність та надійність
Час безвідмовної роботи
Система повинна бути доступною з 7:00 до 19:00 з 99,9% часу безвідмовної роботи протягом цього періоду.
Терпимість до відмов
98,61%, припускаючи, що система працює 12 годин на день і може бути недоступною протягом 10 хвилин.
3. Вимоги до безпеки
Захист даних та шифрування
Система повинна шифрувати всі дані користувачів під час передачі.
4. Підтримка та розширюваність
Якість коду
База коду системи повинна відповідати кращим практикам програмування та мати відповідну документацію для забезпечення легкості в обслуговуванні.
Логування та моніторинг
Система повинна мати можливості для реального часу логування та моніторингу для виявлення та діагностики помилок або проблем з продуктивністю.
5. Сумісність
Сумісність з платформами
Система повинна підтримувати основні операційні системи та браузери Chrome для робочих столів.
API для інтеграції
Система повинна надавати REST API, щоб в майбутньому можна було розширити її для мобільних додатків.
Цілісність даних та узгодженість
Узгодженість повідомлень
Система повинна забезпечити, щоб усі учасники розмови бачили однакові повідомлення в тому ж порядку.
Синхронізація даних
Система повинна синхронізувати повідомлення користувачів між пристроями протягом 3 секунд, забезпечуючи узгодженість.
Архітектура високого рівня
HLD для системи чату співробітників
Вся система складається з 3 мікросервісів:
Мікросервіс користувачів:
Додаток на Flask, який буде відповідати за надання REST API для створення користувачів, аутентифікації та авторизації.
Зберігає інформацію про користувачів у MySQL.
Мікросервіс розмов:
Додаток на Flask, який буде відповідати за надання WebSocket та REST API для створення та читання розмов, що включають наданий ідентифікатор користувача.
Зберігає розмови в MongoDB.
Web UI:
Додаток на Flask, який рендерить вікно чату.
Дизайн низького рівня
Класова та DB модель
Типовий випадок використання розмови
Дизайн API
1. Створення користувача
Endpoint: POST /user
Опис: Створює нового користувача з наданими даними.
Тіло запиту:
{
"user_name": "string",
"password": "string",
"first_name": "string",
"last_name": "string"
}
Відповідь:
201 Created: Користувача успішно створено.
400 Bad Request: Відсутні або неправильні дані.
{
"message": "User created successfully",
}
2. Аутентифікація користувача
Endpoint: POST /user/login
Опис: Аутентифікує користувача та повертає токен, якщо аутентифікація успішна.
Тіло запиту:
{
"user_name": "string",
"password": "string"
}
Відповідь:
200 OK: Аутентифікація успішна.
401 Unauthorized: Невірні облікові дані.
{
"token": "jwt_token",
"name": "first name"
"uuid":"user unique id"
}
3. Список користувачів
Endpoint: GET /user
Опис: Отримує список всіх користувачів.
Headers: Authorization: Bearer
Відповідь:
200 OK: Список користувачів.
403 Forbidden: Відсутній або недійсний токен.
[
{
"user_id": "uuid",
"first_name": "John",
"last_name": "Doe",
},
{
"user_id": "uuid",
"first_name": "Jane",
"last_name": "Doe"
}
]
4. Отримати конкретного користувача
Endpoint: GET /user/
Опис: Отримує інформацію про конкретного користувача.
Headers: Authorization: Bearer
Відповідь:
200 OK: Інформація про користувача.
403 Forbidden: Відсутній або недійсний токен.
[
{
"user_id": "uuid",
"first_name": "John",
"last_name": "Doe",
},
{
"user_id": "uuid",
"first_name": "Jane",
"last_name": "Doe"
}
]
5. Отримати кімнату на основі інформації про учасників
Endpoint: GET /room/by-participants
Опис: Отримує або створює кімнату з поточним користувачем та наданим учасником.
Параметри: ім'я учасника та uuid
Headers: Authorization: Bearer
Відповідь:
200 OK: Об’єкт кімнати
403 Forbidden: Відсутній або недійсний токен.
{
"room_type": 0
"room_id": "room_uuid",
"room_name":"room display name"
}
6. Отримати нещодавно активні кімнати для поточного користувача
Endpoint: GET /room/active-by-user
Опис: Отримує нещодавно активні кімнати для поточного користувача з кількістю непрочитаних повідомлень.
Headers: Authorization: Bearer
Відповідь:
200 OK: Список кімнат.
403 Forbidden: Відсутній або недійсний токен.
{
"room_type": 0
"room_id": "room_uuid",
"room_name":"room display name",
"unread_count":0
}
7. Прочитати повідомлення
Endpoint: GET /room/messages?room_id=<>
Опис: Отримує список всіх повідомлень для наданої кімнати.
Цілісність даних та узгодженість
Узгодженість повідомлень
Система повинна забезпечити, щоб усі учасники розмови бачили однакові повідомлення в тому ж порядку.
Синхронізація даних
Система повинна синхронізувати повідомлення користувачів між пристроями протягом 3 секунд, забезпечуючи узгодженість.
Архітектура високого рівня
HLD для системи чату співробітників
Вся система складається з 3 мікросервісів:
Мікросервіс користувачів:
Додаток на Flask, який буде відповідати за надання REST API для створення користувачів, аутентифікації та авторизації.
Зберігає інформацію про користувачів у MySQL.
Мікросервіс розмов:
Додаток на Flask, який буде відповідати за надання WebSocket та REST API для створення та читання розмов, що включають наданий ідентифікатор користувача.
Зберігає розмови в MongoDB.
Web UI:
Додаток на Flask, який рендерить вікно чату.
Дизайн низького рівня
Класова та DB модель
Типовий випадок використання розмови
Дизайн API
1. Створення користувача
Endpoint: POST /user
Опис: Створює нового користувача з наданими даними.
Тіло запиту:
{
"user_name": "string",
"password": "string",
"first_name": "string",
"last_name": "string"
}
Відповідь:
201 Created: Користувача успішно створено.
400 Bad Request: Відсутні або неправильні дані.
{
"message": "User created successfully",
}
2. Аутентифікація користувача
Endpoint: POST /user/login
Опис: Аутентифікує користувача та повертає токен, якщо аутентифікація успішна.
Тіло запиту:
{
"user_name": "string",
"password": "string"
}
Відповідь:
200 OK: Аутентифікація успішна.
401 Unauthorized: Невірні облікові дані.
{
"token": "jwt_token",
"name": "first name"
"uuid":"user unique id"
}
3. Список користувачів
Endpoint: GET /user
Опис: Отримує список всіх користувачів.
Headers: Authorization: Bearer
Відповідь:
200 OK: Список користувачів.
403 Forbidden: Відсутній або недійсний токен.
[
{
"user_id": "uuid",
"first_name": "John",
"last_name": "Doe",
},
{
"user_id": "uuid",
"first_name": "Jane",
"last_name": "Doe"
}
]
4. Отримати конкретного користувача
Endpoint: GET /user/
Опис: Отримує інформацію про конкретного користувача.
Headers: Authorization: Bearer
Відповідь:
200 OK: Інформація про користувача.
403 Forbidden: Відсутній або недійсний токен.
[
{
"user_id": "uuid",
"first_name": "John",
"last_name": "Doe",
},
{
"user_id": "uuid",
"first_name": "Jane",
"last_name": "Doe"
}
]
5. Отримати кімнату на основі інформації про учасників
Endpoint: GET /room/by-participants
Опис: Отримує або створює кімнату з поточним користувачем та наданим учасником.
Параметри: ім'я учасника та uuid
Headers: Authorization: Bearer
Відповідь:
200 OK: Об’єкт кімнати
403 Forbidden: Відсутній або недійсний токен.
{
"room_type": 0
"room_id": "room_uuid",
"room_name":"room display name"
}
6. Отримати нещодавно активні кімнати для поточного користувача
Endpoint: GET /room/active-by-user
Опис: Отримує нещодавно активні кімнати для поточного користувача з кількістю непрочитаних повідомлень.
Headers: Authorization: Bearer
Відповідь:
200 OK: Список кімнат.
403 Forbidden: Відсутній або недійсний токен.
{
"room_type": 0
"room_id": "room_uuid",
"room_name":"room display name",
"unread_count":0
}
7. Прочитати повідомлення
Endpoint: GET /room/messages?room_id=<>
Опис: Отримує список всіх повідомлень для наданої кімнати.
Headers: Authorization: Bearer
Відповідь:
200 OK: Список повідомлень.
403 Forbidden: Відсутній або недійсний токен.
[
{
"created": "datetime",
"updated": "datetime",
"message_id": "uuid",
"sender_uuid": "uuid",
"sender_name": "name",
"message": "name",
},
{
"created": "datetime",
"updated": "datetime",
"message_id": "uuid",
"sender_uuid": "uuid",
"sender_name": "name",
"message": "name"
}
]
Дизайн UI
Вхід (Окрім кнопки внизу, співробітники не можуть реєструватися самостійно)
Реєстрація користувача
Головний екран
Я планую реалізувати цей дизайн і скоро поділитися своїм досвідом, слідкуйте за оновленнями.
Headers: Authorization: Bearer
Відповідь:
200 OK: Список повідомлень.
403 Forbidden: Відсутній або недійсний токен.
[
{
"created": "datetime",
"updated": "datetime",
"message_id": "uuid",
"sender_uuid": "uuid",
"sender_name": "name",
"message": "name",
},
{
"created": "datetime",
"updated": "datetime",
"message_id": "uuid",
"sender_uuid": "uuid",
"sender_name": "name",
"message": "name"
}
]
Дизайн UI
Вхід (Окрім кнопки внизу, співробітники не можуть зареєструватися самостійно)
Реєстрація користувача
Головний екран
Я планую реалізувати цей дизайн і скоро поділитися своїм досвідом, слідкуйте за оновленнями.
Перекладено з: Practicing the modern app design