Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/6028| Назва: | Веб-застосунок для обміну повідомленнями з використанням клієнт-серверної архітектури |
| Автори: | Оксамитна, Любов Павлівна Танцюра, Артем Сергійович |
| Ключові слова: | ВЕБ-ЗАСТОСУНОК,;ОБМІН ПОВІДОМЛЕННЯМИ,;КЛІЄНТ-СЕРВЕРНА АРХІТЕКТУРА,;РЕАЛЬНИЙ ЧАС,;ХМАРНІ ТЕХНОЛОГІЇ,;АВТЕНТИФІКАЦІЯ,;ПРОГРАМНА РЕАЛІЗАЦІЯ,;ВЕБ-РОЗРОБКА. |
| Дата публікації: | 11-чер-2025 |
| Короткий огляд (реферат): | З кожним роком зростає попит на веб-рішення, які забезпечують миттєвий обмін повідомленнями з високим рівнем безпеки, доступності та зручності у використанні. Тема кваліфікаційної роботи бакалавра є актуальною в зв'язку з потребою розробки нових інструментів комунікації, які відповідають вимогам продуктивності, гнучкості та масштабованості, особливо для малого та середнього бізнесу, освітніх платформ і внутрішніх корпоративних систем. Метою кваліфікаційної роботи бакалавра є розробка функціонального веб-застосунку для обміну повідомленнями, що базується на клієнт-серверній архітектурі та забезпечує обмін повідомленнями в режимі реального часу з урахуванням сучасних вимог до продуктивності, масштабованості та безпеки. Об’єкт дослідження: процес побудови веб-застосунків, призначених для передачі повідомлень між користувачами в режимі онлайн. Предмет дослідження: веб-застосунок для обміну повідомленнями з використанням клієнт-серверної архітектури. Розроблений застосунок має чітко окреслену архітектуру та потенціал до масштабування. Його функціональність може бути розширена за рахунок підтримки групових чатів, передачі файлів, реалізації push-сповіщень, використання хмарних функцій Firebase для додаткової серверної логіки, інтеграції з іншими сервісами, такими як Telegram або Slack, а також впровадження адміністративної панелі для керування користувачами та повідомленнями. Відкрита структура рішення дозволяє гнучко адаптувати систему під нові вимоги, цілі або сфери застосування. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/6028 |
| Розташовується у зібраннях: | 122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Пояснювальна записка_Танцюра Артем_КН-2101_2024-2025.pdf Restricted Access | 2.24 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
(освітньо-кваліфікаційний рівень)
на тему: «Веб-застосунок для обміну повідомленнями з використанням клієнт-
серверної архітектури»
Виконав: студент 4 курсу, групи КН-2101
спеціальності 122 − «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Комп’ютерні науки та
(назва освітньої програми)
прикладне програмування
Танцюра Артем Сергійович
Керівник __________ Оксамитна Л.П.
(прізвище та ініціали)
Рецензент __________ Стась С.В.
(прізвище та ініціали)
Черкаси 2025 рік
Бланк завдання на кваліфікаційну роботу бакалавра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Бакалавр
Спеціальність 122 – Комп’ютерні науки
Освітня програма Комп’ютерні науки та прикладне програмування
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2025 р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Танцюрі Артему Сергійовичу
(прізвище, ім’я, по батькові)
Веб-застосунок для обміну повідомленнями з використанням клієнт-
1. Тема роботи серверної архітектури
Керівник роботи Оксамитна Л.П., к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «25» лютого 2025 р. №53/03-03.
2. Строк подання студентом роботи до 11 червня 2025 року.
3. Вихідні дані до роботи:
Практичні навички роботи з інформаційними ресурсами. Робота з базами даних.
Звіт з виробничої практики. Звіт з переддипломної практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Дослідження предметної області.
4.2. Проєктування та розробка веб-застосунку для обміну повідомленнями з використанням
клієнт-серверної архітектури.
4.3. Програмна реалізація.
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482.ЧДТУ. 52115-01.
5.2. Додаток Б. Текст програми.
5.3. Додаток В. Інструкція користувача.
5.4. Презентація у вигляді 18 слайдів.
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 17.12.2024
КАЛЕНДАРНИЙ ПЛАН
Строк
№ з/п Назва етапів кваліфікаційної роботи бакалавра виконання Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу
17.12.2024 Виконано
бакалавра.
2 Аналіз літературних джерел, об’єкту та предмету
до 12.02.2025 Виконано
дослідження.
3 Написання теоретичного розділу кваліфікаційної
до 18.03.2025 Виконано
роботи бакалавра.
4 Написання аналітичного розділу кваліфікаційної
до 01.04.2025 Виконано
роботи бакалавра.
5 Написання практичних розділів й висновків до
до 01.05.2025 Виконано
кваліфікаційної роботи бакалавра.
6 Передзахист кваліфікаційної роботи бакалавра
03.06.2025 Виконано
на засіданні кафедри КНСА.
7 Подання роботи завідувачу кафедри КНСА. до 10.06.2025 Виконано
8 Захист кваліфікаційної роботи бакалавра. 11.06.2025 Виконано
Студент _____________________________ Артем ТАНЦЮРА
(підпис)
Керівник роботи ____________________________ Любов ОКСАМИТНА
(підпис)
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 85 с., 19 рис., 13 використаних
джерел, 4 додатки.
Актуальність теми. З кожним роком зростає попит на веб-рішення, які
забезпечують миттєвий обмін повідомленнями з високим рівнем безпеки, доступності
та зручності у використанні. Тема кваліфікаційної роботи бакалавра є актуальною в
зв'язку з потребою в розробці нових інструментів комунікації, які відповідають
вимогам продуктивності, гнучкості та масштабованості, особливо для малого та
середнього бізнесу, освітніх платформ і внутрішніх корпоративних систем.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є
розробка функціонального веб-застосунку для обміну повідомленнями, що базується
на клієнт-серверній архітектурі та забезпечує обмін повідомленнями в режимі
реального часу з урахуванням сучасних вимог до продуктивності, масштабованості
та безпеки. Задачі, які потрібно вирішити:
проаналізувати існуючі рішення у сфері веб-месенджерів та виділити їх
сильні й слабкі сторони;
обґрунтувати вибір архітектури, технологій та інструментів для реалізації
веб-застосунку;
cпроєктувати клієнтську та серверну частини застосунку з урахуванням
принципів модульності та розширюваності;
реалізувати серверну логіку з використанням сучасного середовища
розробки;
розробити зручний інтерфейс користувача з використанням сучасних
веб-технологій;
провести тестування функціональності застосунку та оцінити його
продуктивність.
Об’єкт дослідження: процес побудови веб-застосунків, призначених для
передачі повідомлень між користувачами в режимі онлайн.
Предмет дослідження: веб-застосунок для обміну повідомленнями з
використанням клієнт-серверної архітектури.
Методи дослідження. У процесі виконання кваліфікаційної роботи бакалавра
було використано такі наукові методи дослідження:
Метод аналізу – для вивчення існуючих рішень у сфері веб-застосунків для
обміну повідомленнями та виявлення актуальних проблем і потреб користувачів.
Метод синтезу – для поєднання окремих технічних рішень у єдину
функціональну систему.
Метод моделювання – для побудови архітектури веб-застосунку на основі
клієнт-серверного підходу.
Порівняльний метод – для оцінки переваг і недоліків різних технологій,
використаних при розробці.
Перелік ключових слів: ВЕБ-ЗАСТОСУНОК, ОБМІН ПОВІДОМЛЕННЯМИ,
КЛІЄНТ-СЕРВЕРНА АРХІТЕКТУРА, FIREBASE, FIRESTORE, NEXT.JS, REACT,
АВТЕНТИФІКАЦІЯ, РЕАЛЬНИЙ ЧАС, ХМАРНІ ТЕХНОЛОГІЇ, ІНТЕРФЕЙС
КОРИСТУВАЧА, ЧАТ, ПРОГРАМНА РЕАЛІЗАЦІЯ, ТЕСТУВАННЯ, ВЕБ-
РОЗРОБКА.
ABSTRACT
Work contains. 85 pages, 19 figures, 13 sources used, 4 attachments.
Relevance of the topic. The demand for web solutions that enable instant messaging
with a high level of security, accessibility, and ease of use increases every year. The topic
is relevant due to the need to develop new communication tools that meet the requirements
of performance, flexibility, and scalability – especially for small and medium-sized
businesses, educational platforms, and internal corporate systems.
Purpose and tasks of the research. The developed application is intended to provide
user-friendly interaction, store message history, handle errors, and remain resilient to
failures.
The main objectives are as follows:
to analyze existing solutions in the field of web messengers and identify their
strengths and weaknesses;
to justify the choice of architecture, technologies, and tools for implementing
the web application;
to design the client and server parts of the application in accordance with the
principles of modularity and extensibility;
to implement the server-side logic using a modern development environment;
to develop a convenient user interface using modern web technologies;
to conduct functional testing of the application and evaluate its performance.
The object of research. The object of research is the process of developing web
applications designed for real-time message exchange between users.
The subject of research: The subject of research is the client-server architecture of
web applications and the technologies that ensure real-time messaging.
Research methods: During the implementation of the qualification thesis, the
following scientific methods were used:
Analysis – to study existing solutions in the field of messaging web applications and
identify current user problems and needs.
Synthesis – to combine separate technical solutions into a unified functional system.
Modeling – to design the architecture of the web application based on the client-server
approach.
Comparative method – to assess the advantages and disadvantages of various
technologies used in development.
The list of keywords: WEB APPLICATION, MESSAGING, CLIENT-SERVER
ARCHITECTURE, FIREBASE, FIRESTORE, NEXT.JS, REACT, AUTHENTICATION,
REAL-TIME, CLOUD TECHNOLOGIES, USER INTERFACE, CHAT, SOFTWARE
IMPLEMENTATION, TESTING, WEB-DEVELOPMENT.
7
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 9
ВСТУП 10
1 ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ 12
1.1 Аналіз сучасного стану вибору веб-застосунків для обміну повідомленнями 12
1.2 Огляд існуючих аналогів веб-застосунків для обміну повідомленнями з
використанням клієнт-серверної архітектури 15
1.2.1 Аналіз месенджеру «Slack» 15
1.2.2 Аналіз веб-додатку «Discord» 16
1.2.3 Аналіз веб-додатку «Telegram Web» 18
1.3 Аналіз порівнянь існуючих рішень розглянутих реалізацій та постановка
завдання 19
Висновки до розділу 1 21
2 ПРОЄКТУВАННЯ ВЕБ-ЗАСТОСУНКУ ДЛЯ ОБМІНУ ПОВІДОМЛЕННЯМИ З
ВИКОРИСТАННЯМ КЛІЄНТ-СЕРВЕРНОЇ АРХІТЕКТУРИ 22
2.1 Опис функціонального програмного середовища для розробки 22
2.2 Основні принципи розробки веб-застосунків 25
2.3 Архітектура веб-застосунку для обміну повідомленнями з використанням
клієнт-серверної архітектури 28
2.4 Розробка діаграми варіантів використання 32
2.5 Проєктування структури бази даних 33
2.6 Опис процесу проєктування структури веб-застосунку для обміну
повідомленнями з використанням клієнт-серверної архітектури 35
2.7 Проєктування інтерфейсу користувача 38
Висновки до розділу 2 41
3 ПРОГРАМНА РЕАЛІЗАЦІЯ 42
3.1 Постановка завдання 42
3.2 Інтерфейс веб-застосунку для обміну повідомленнями 47
8
3.3 Програмна реалізація веб-застосунку для обміну повідомленнями з
використанням клієнт серверної архітектури 49
3.4 Особливості тестування веб-застосунків 55
3.5 Тестування веб-застосунку для обміну повідомленнями з використанням
клієнт-серверної архітектури 57
Висновки до розділу 3 60
ВИСНОВКИ 62
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 65
Додаток А. Специфікація 482.ЧДТУ. 52115-01 66
Додаток Б. Текст програми 67
Додаток В. Інструкція користувача 79
Додаток Г. Структура бази даних 83
9
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І
ТЕРМІНІВ
API – Інтерфейс прикладного програмування – набір методів для
взаємодії між компонентами системи.
UI – Інтерфейс користувача – візуальні елементи, з якими
взаємодіє користувач.
UX – Досвід користувача – загальне враження від взаємодії з веб-
додатком.
SDK – Набір інструментів розробника – програмні засоби для
інтеграції функціоналу.
HTML – Мова розмітки гіпертексту – основа структури веб-сторінок.
CSS – Каскадні таблиці стилів – інструмент оформлення
зовнішнього вигляду елементів.
JS – JavaScript – мова програмування для створення
інтерактивності у браузері.
React – Бібліотека JavaScript для побудови інтерфейсів користувача
Next.js – Фреймворк для серверно-клієнтських React-додатків.
SPA – Односторінковий додаток, що працює без перезавантаження
сторінок.
CRUD – Створення, читання, оновлення, видалення – основні дії з
даними.
10
ВСТУП
У сучасному світі обмін інформацією в режимі реального часу став
невіддільною частиною повсякденного життя. Веб-застосунки для обміну
повідомленнями активно використовуються як у приватному, так і в професійному
середовищі. Завдяки розвитку інтернет-технологій та популяризації клієнт-
серверної архітектури з’явилася можливість створювати швидкі, масштабовані та
надійні системи, які забезпечують ефективну комунікацію між користувачами.
Актуальність кваліфікаційної роботи бакалавра.
З кожним роком зростає попит на веб-рішення, які забезпечують миттєвий
обмін повідомленнями з високим рівнем безпеки, доступності та зручності у
використанні. Сучасні веб-месенджери, що базуються на клієнт-серверній
архітектурі, дають змогу реалізувати функціонал обміну повідомленнями з
підтримкою різних протоколів і форматів даних. Тема кваліфікаційної роботи
бакалавра є актуальною в зв'язку з потребою в розробці нових інструментів
комунікації, які відповідають вимогам продуктивності, гнучкості та
масштабованості, особливо для малого та середнього бізнесу, освітніх платформ і
внутрішніх корпоративних систем.
Мета кваліфікаційної роботи бакалавра – розробка функціонального веб-
застосунку для обміну повідомленнями, що базується на клієнт-серверній
архітектурі та забезпечує обмін повідомленнями в режимі реального часу з
урахуванням сучасних вимог до продуктивності, масштабованості та безпеки.
Розроблений застосунок має забезпечувати зручну взаємодію користувачів,
зберігання історії повідомлень, обробку помилок та стійкість до збоїв. Задачі, які
потрібно вирішити:
проаналізувати існуючі рішення у сфері веб-месенджерів та виділити їх
сильні й слабкі сторони;
обґрунтувати вибір архітектури, технологій та інструментів для
реалізації веб-застосунку;
11
cпроєктувати клієнтську та серверну частини додатку з урахуванням
принципів модульності та розширюваності;
реалізувати серверну логіку з використанням сучасного середовища
розробки;
розробити зручний інтерфейс користувача з використанням сучасних
веб-технологій;
провести тестування функціональності застосунку та оцінити його
продуктивність.
Об’єкт дослідження: процес побудови веб-застосунків, призначених для
передачі повідомлень між користувачами в режимі онлайн.
Предмет дослідження: веб-застосунок для обміну повідомленнями з
використанням клієнт-серверної архітектури.
Методи дослідження. У процесі виконання кваліфікаційної роботи бакалавра
було використано такі наукові методи дослідження:
Метод аналізу – для вивчення існуючих рішень у сфері веб-застосунків для
обміну повідомленнями та виявлення актуальних проблем і потреб користувачів.
Метод синтезу – для поєднання окремих технічних рішень у єдину
функціональну систему.
Метод моделювання – для побудови архітектури веб-застосунку на основі
клієнт-серверного підходу.
Порівняльний метод – для оцінки переваг і недоліків різних технологій,
використаних при розробці.
12
1 ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ
1.1 Аналіз сучасного стану вибору веб-застосунків для обміну
повідомленнями
У сучасному інформаційному суспільстві веб-застосунки для обміну
повідомленнями відіграють ключову роль у забезпеченні швидкої та зручної
комунікації між користувачами. Їх використання стало повсякденною нормою як у
побуті, так і в бізнес-середовищі, де ефективна передача інформації напряму впливає
на швидкість прийняття рішень, координацію роботи команд і загальну
продуктивність. Розвиток технологій веб-програмування, зокрема клієнт-серверної
архітектури, веб-сокетів, хмарних сервісів та баз даних у реальному часі, створив
передумови для значного прогресу у сфері створення месенджерів. У зв’язку з цим
виникає потреба проаналізувати сучасний стан вибору веб-застосунків для обміну
повідомленнями, виявити їхні переваги, недоліки та визначити напрями подальшого
розвитку.
Одним із головних чинників, що впливає на популярність конкретного веб-
застосунку, є його здатність забезпечити стабільну передачу повідомлень із
мінімальними затримками. Більшість сучасних систем реалізовані з використанням
WebSocket або аналогічних протоколів, що забезпечують двосторонній зв’язок між
клієнтом і сервером. Такі рішення значно підвищують швидкість обміну
повідомленнями у порівнянні з традиційними HTTP-запитами. Важливо зазначити,
що в основі архітектури більшості популярних веб-месенджерів лежить модель
клієнт-сервер, яка дозволяє централізовано контролювати потоки інформації,
зберігати повідомлення, керувати сесіями користувачів і забезпечувати безпеку
даних.
Поширені приклади сучасних веб-застосунків для обміну повідомленнями –
це WhatsApp Web, Telegram Web, Slack, Microsoft Teams, Discord та інші. Вони
мають спільні риси, зокрема: підтримку обміну текстовими повідомленнями,
передачу медіа-файлів, синхронізацію з мобільними версіями, підтримку групових
13
чатів, каналів і можливість інтеграції зі сторонніми сервісами. Однак, у кожного з
цих сервісів є свої особливості, які визначають цільову аудиторію та сценарії
використання. Наприклад, Slack та Microsoft Teams орієнтовані передусім на бізнес-
комунікації, мають глибоку інтеграцію з офісними інструментами, можливість
створення просторів для командної роботи та багатофункціональні системи прав
доступу. Натомість Telegram і WhatsApp частіше використовуються в особистому
спілкуванні, хоча Telegram дедалі більше впроваджує функціональність,
притаманну корпоративним рішенням, як-от боти, канали, API для розробників.
Незважаючи на розмаїття рішень, існує низка проблем, з якими стикаються
користувачі веб-месенджерів. Серед них – обмежена підтримка офлайн-доступу,
прив’язка до мобільних номерів (як у WhatsApp), обмеження на розмір вкладень,
складність масштабування в умовах великого навантаження, недостатній рівень
шифрування на деяких етапах обробки повідомлень. Окрім того, деякі системи є
закритими, тобто їхній код не є відкритим для громадськості, що унеможливлює
незалежний аудит безпеки або кастомізацію для потреб конкретної організації.
З технічної точки зору, вибір веб-застосунку залежить від використовуваних
технологій і архітектурних підходів. Розробники дедалі частіше застосовують
JavaScript-фреймворки (React, Angular, Vue) для створення інтерфейсів користувача,
а також Node.js, Express.js або аналогічні технології на сервері. Для обміну
повідомленнями у реальному часі перевага надається WebSocket або бібліотекам на
його основі, таким як Socket.IO. У деяких випадках використовуються також
технології, що підтримують publish-subscribe моделі, наприклад MQTT або Redis
Pub/Sub. Як сховища даних найчастіше виступають реляційні або
документоорієнтовані бази даних: PostgreSQL, MongoDB, Firebase Realtime Database
тощо.
Одним із трендів останніх років є прагнення до створення децентралізованих
месенджерів, які не залежать від центрального сервера та забезпечують повну
конфіденційність обміну. Проте, такі рішення поки що не мають широкого
розповсюдження через складність реалізації, проблеми з масштабуванням і
обмежену підтримку з боку браузерів. Водночас, впровадження наскрізного
14
шифрування (end-to-end encryption) поступово стає стандартом, що значно підвищує
безпеку передачі даних навіть у централізованих системах.
Також варто звернути увагу на UX/UI аспекти, які суттєво впливають на
сприйняття та зручність використання веб-додатків. Інтерфейс повинен бути
інтуїтивно зрозумілим, швидко реагувати на дії користувача, адаптуватися під різні
розміри екранів, а також мати можливість персоналізації. Підтримка темного
режиму, push-сповіщень, індикаторів активності, редагування повідомлень — усе це
стало очікуваними функціями для сучасного користувача. Відсутність подібного
функціоналу часто сприймається як недолік.
Важливу роль також відіграє мобільна адаптивність веб-застосунків, адже
значна частина користувачів заходить до месенджерів через смартфони. У зв’язку з
цим веб-рішення мають бути добре оптимізовані та здатні ефективно працювати в
мобільних браузерах або через прогресивні веб-додатки (PWA), які поєднують
переваги звичайного сайту й нативного застосунку.
На сьогоднішній день конкуренція між веб-месенджерами продовжує
зростати. Компанії намагаються розширити свої сервіси, додаючи підтримку
відеозв’язку, реакцій на повідомлення, інтеграцій із системами управління
проєктами, можливість створення чат-ботів та автоматизаційних сценаріїв. Усе це
сприяє підвищенню функціональної насиченості веб-додатків, але водночас
ускладнює їхню архітектуру та процес розробки.
Таким чином, аналіз сучасного стану веб-застосунків для обміну
повідомленнями демонструє стрімкий розвиток цього сегмента ІТ-індустрії.
Основними напрямами є підвищення швидкодії, безпеки, масштабованості та
зручності для користувача. Разом із тим залишається простір для вдосконалення
існуючих рішень, що створює підґрунтя для розробки нових інструментів, зокрема
спеціалізованих веб-застосунків, які можна адаптувати до конкретних потреб і умов
використання. У цьому контексті доцільним є створення власного веб-застосунку
для обміну повідомленнями з акцентом на простоту, відкритість архітектури,
мінімальні затримки при передачі даних та гнучкість налаштувань, що й зумовлює
вибір теми даної кваліфікаційної роботи бакалавра.
15
1.2 Огляд існуючих аналогів веб-застосунків для обміну
повідомленнями з використанням клієнт-серверної архітектури
На сучасному етапі розвитку інформаційних технологій існує велика кількість
веб-застосунків для обміну повідомленнями, які базуються на клієнт-серверній
архітектурі. До найпопулярніших рішень належать Slack, Telegram Web, Discord,
Microsoft Teams та WhatsApp Web. Усі ці системи реалізують модель обміну
повідомленнями, де клієнтська частина взаємодіє з централізованим сервером, що
обробляє запити, зберігає дані й забезпечує маршрутизацію повідомлень між
користувачами.
Ключовими особливостями таких рішень є підтримка обміну текстовими
повідомленнями, передачі файлів, реалізація групових чатів, push-сповіщень, а
також інтеграція з іншими сервісами. Технологічно ці застосунки здебільшого
використовують WebSocket або подібні механізми для забезпечення комунікації в
реальному часі, а також бази даних для збереження історії повідомлень.
Хоча існуючі рішення є функціонально насиченими, вони часто є складними у
налаштуванні, не відкритими для гнучкого модифікування або надлишковими для
простих сценаріїв використання. Це створює необхідність у розробці власного веб-
застосунку, адаптованого до конкретних вимог користувача або організації.
1.2.1 Аналіз месенджеру «Slack»
«Slack» є одним із найвідоміших корпоративних месенджерів, який активно
використовується для внутрішньої комунікації в компаніях та проєктних командах
[1]. Засстосунок працює за клієнт-серверною моделлю: клієнтські запити
надсилаються до централізованих серверів через REST API або WebSocket-
з’єднання. Клієнтська частина реалізована з використанням JavaScript та React, а
серверна – на основі хмарної інфраструктури.
«Slack» підтримує організацію роботи через канали, які можуть бути
публічними або приватними, а також обмін приватними повідомленнями між
користувачами [1]. Окрім текстових повідомлень, сервіс дозволяє надсилати файли,
додавати реакції на повідомлення, запускати опитування, а також використовувати
16
інтеграції з багатьма сторонніми сервісами: Google Drive, Trello, GitHub, Jira, Zoom
та іншими.
Серед ключових переваг «Slack» – зручна навігація, потужна система пошуку,
можливість використання ботів та розширень, а також підтримка темної теми і
гарячих клавіш (рис. 1.1). Безпека даних забезпечується шифруванням TLS під час
передачі інформації та захистом при зберіганні в хмарі. Однак, «Slack» є
пропрієтарним продуктом з обмеженим доступом до внутрішніх механізмів, а
повний функціонал доступний лише у платних планах.
Рисунок 1.1 – Інтерфейс користувача месенджеру «Slack» [1]
1.2.2 Аналіз веб-додатку «Discord»
«Discord» – ще один потужний веб-додаток для обміну повідомленнями, який
здобув широку популярність не тільки серед геймерів, а й серед освітніх установ,
технічних спільнот та неформальних груп (рис 1.2) [2]. Його основою є клієнт-
серверна архітектура, в якій комунікація реалізована через WebSocket-з'єднання, що
дозволяє передавати текст, голос, відео та медіа в реальному часі.
17
У «Discord» користувачі створюють «сервери» – це об'єднання каналів для
текстового та голосового спілкування [2]. В межах кожного сервера можуть бути
окремі канали з власними правами доступу, що зручно для структурованої
комунікації. Завдяки своїй архітектурі, «Discord» дозволяє обслуговувати мільйони
одночасних з’єднань з високою продуктивністю.
Важливою особливістю платформи є підтримка ботів, які можна створювати
через публічне API. Це відкриває широкі можливості для автоматизації та
кастомізації функцій сервера. Додаток має потужну систему ролей, що дозволяє
налаштувати доступ до різних каналів. Безпека реалізована через шифрування
з’єднань, а також використання системи двофакторної аутентифікації.
«Discord» має веб-версію, десктопні та мобільні додатки, що синхронізуються
між собою [2]. Його основна перевага – реальний час взаємодії з мінімальною
затримкою, широкі можливості налаштування та висока стабільність навіть при
великому
Рисунок 1.2 – Інтерфейс користувача веб-додатку «Discord» [2]
18
1.2.3 Аналіз веб-додатку «Telegram Web»
Telegram Web – це веб-версія одного з найшвидших і найбезпечніших
месенджерів, що використовує клієнт-серверну архітектуру та власний протокол
MTProto. Telegram орієнтований як на особисте, так і на групове спілкування,
підтримує чати, канали, групи з тисячами учасників, обмін медіафайлами, голосові
та відеодзвінки.
У веб-версії Telegram клієнтська частина виконує функції інтерфейсу, обробки
запитів та взаємодії з сервером. Сервер відповідає за авторизацію, маршрутизацію
повідомлень, збереження історії та управління користувачами. MTProto забезпечує
ефективну та безпечну передачу даних, включаючи наскрізне шифрування у
«секретних чатах», які недоступні у веб-версії, проте активно використовуються на
мобільних пристроях.
Рисунок 1.3 – Графічний інтерфейс користувача сервісу «Microsoft To Do» [3]
Telegram підтримує кросплатформенну синхронізацію, завдяки чому
користувачі можуть продовжити спілкування з будь-якого пристрою. Окрім того,
сервіс дозволяє створювати ботів, які можуть автоматизувати відповіді, запис
19
користувачів, обробку форм тощо. Telegram також вирізняється відкритим API та
політикою доступності, що робить його зручним для розробників і стартапів.
Незважаючи на високий рівень функціональності, Telegram Web має деякі
обмеження порівняно з мобільною версією, зокрема відсутність підтримки
голосових чатів і секретних чатів. Проте, як веб-додаток, він є прикладом ефективної
реалізації масштабованого клієнт-серверного рішення для обміну повідомленнями.
1.3 Аналіз порівнянь існуючих рішень розглянутих реалізацій та
постановка завдання
На основі попереднього огляду можна зробити висновок, що всі розглянуті
веб-додатки (Slack, Discord, Telegram Web) реалізовані за класичною клієнт-
серверною архітектурою та забезпечують ефективну передачу повідомлень у
реальному часі. Проте кожен з них має різний ступінь відкритості,
функціональності, гнучкості інтеграції та складності використання. У таблиці нижче
наведено порівняльний аналіз основних характеристик:
Таблиця 1.1 – Порівняльна таблиця веб-додатків для обміну повідомленнями
Критерій Slack Discord Telegram Web
Платформа для
Корпоративний Універсальний
Тип платформи спільнот і
месенджер месенджер
геймерів
Клієнт-сервер,
Клієнт-сервер, Клієнт-сервер,
Архітектура REST API +
WebSocket MTProto
WebSocket
Висока,
Висока, залежить Висока, особливо
Швидкодія оптимізована під
від тарифу на мобільних
реальний час
Добра, але Висока, підходить
Масштабованість переважно у для великих Висока
платній версії спільнот
Доступна через
Можливість Обмежена, закрите Частково доступна
API, відкритий
кастомізації ПЗ через API і ботів
протокол
20
MTProto, наскрізне
TLS, корпоративні
Безпека передачі TLS, 2FA шифрування
політики
(частково)
Наявність
Так, частково Так Так
відкритого API
Незважаючи на багатий функціонал проаналізованих рішень, вони мають кілька
спільних обмежень. Зокрема, більшість із них:
не дозволяють гнучко адаптувати інтерфейс і функціонал під конкретні
потреби організації чи проєкту;
потребують складної інтеграції або платних підписок для повного
функціоналу;
не мають відкритого коду або є обмеженими у зміні бізнес-логіки.
З огляду на це, існує доцільність створення власного веб-застосунку для
обміну повідомленнями, який буде простішим в реалізації, адаптивним до
індивідуальних потреб і заснованим на сучасних відкритих технологіях.
Постановка завдання. У рамках даної кваліфікаційної роботи бакалавра
ставиться завдання розробити веб-застосунок для обміну повідомленнями на основі
клієнт-серверної архітектури, який забезпечить:
обмін повідомленнями в реальному часі між зареєстрованими користувачами;
простий та інтуїтивно зрозумілий інтерфейс;
зберігання історії повідомлень у базі даних;
систему автентифікації користувачів;
мінімальний набір функцій, необхідних для ефективного текстового
спілкування;
використання сучасного технологічного стеку;
можливість масштабування та подальшого розширення функціоналу.
Таким чином, в ході реалізації буде спроєктовано і створено власний прототип
веб-месенджеру, що слугуватиме основою для подальших досліджень, навчальних
або комерційних рішень.
21
Висновки до розділу 1
У цьому розділі проаналізовано сучасний стан використання веб-застосунків
для обміну повідомленнями, їх архітектурні особливості, функціональні можливості
та технологічні підходи.
Було встановлено, що більшість популярних рішень, таких як Slack, Discord і
Telegram Web, реалізовані на основі клієнт-серверної архітектури та забезпечують
ефективний обмін даними в реальному часі. Разом із тим, ці сервіси мають низку
обмежень, зокрема щодо адаптації під індивідуальні потреби, складності інтеграції
з іншими системами та залежності від закритих інфраструктур.
Порівняльний аналіз підтвердив, що хоча існуючі месенджери демонструють
високу стабільність, масштабованість і безпеку, вони здебільшого орієнтовані на
масове або корпоративне використання, що не завжди відповідає вимогам
спеціалізованих або освітніх середовищ. Це обґрунтовує актуальність створення
власного веб-застосунку, який дозволяє реалізувати мінімально необхідний
функціонал, адаптований до конкретного сценарію використання.
У результаті проведеного аналізу було сформульовано завдання розробки веб-
застосунку для обміну повідомленнями з використанням клієнт-серверної
архітектури. Передбачено використання сучасного стеку технологій, підтримку
обміну повідомленнями в реальному часі, автентифікацію користувачів та
збереження історії спілкування. Отримані результати слугуватимуть основою для
подальшого проєктування та реалізації системи в наступних розділах роботи.
22
2 ПРОЄКТУВАННЯ ВЕБ-ЗАСТОСУНКУ ДЛЯ ОБМІНУ
ПОВІДОМЛЕННЯМИ З ВИКОРИСТАННЯМ КЛІЄНТ-СЕРВЕРНОЇ
АРХІТЕКТУРИ
2.1 Опис функціонального програмного середовища для розробки
У процесі розробки веб-застосунку для обміну повідомленнями надзвичайно
важливим є вибір функціонального середовища програмування, яке б забезпечувало
зручність, ефективність і стабільність виконання завдань на всіх етапах життєвого
циклу програмного забезпечення – від написання коду до його тестування й
налагодження. У даній роботі було обрано середовище розробки Visual Studio Code
(VS Code), що на сьогодні є одним з найпопулярніших і найзатребуваніших
інструментів серед веб-розробників по всьому світу.
Visual Studio Code – це легкий, кросплатформенний редактор коду з відкритим
вихідним кодом, створений і підтримуваний компанією Microsoft [4]. Він поєднує у
собі функціональність повноцінного інтегрованого середовища розробки (IDE) та
гнучкість традиційних текстових редакторів. Його головною перевагою є те, що він
дозволяє працювати з найрізноманітнішими мовами програмування, інструментами
та фреймворками за рахунок підтримки широкої екосистеми розширень. Завдяки
цьому VS Code однаково ефективно підходить як для фронтенд-, так і для бекенд-
розробки, що робить його універсальним інструментом у проєктах з клієнт-
серверною архітектурою.
Однією з ключових характеристик середовища є підтримка багатомовності.
VS Code з «коробки» підтримує JavaScript, HTML, CSS, TypeScript, Python, C++, C#,
PHP, JSON, YAML та багато інших мов. Проте можливість легко додавати
підтримку нових мов через розширення робить його придатним практично для будь-
якого типу проєктів. У випадку створення веб-застосунку для обміну
повідомленнями це дає змогу працювати в єдиному середовищі над усіма частинами
проєкту – клієнтською, серверною, конфігураційною та навіть документаційною.
23
Суттєвим чинником при виборі середовища стала його кросплатформенність.
Visual Studio Code доступний для трьох основних операційних систем: Windows,
macOS і Linux [4]. Це дозволяє команді розробників, яка працює на різних
платформах, використовувати одне й те саме середовище з однаковим інтерфейсом
та поведінкою. Така уніфікація значно полегшує кооперацію в команді, сприяє
обміну знаннями та зменшує ймовірність виникнення помилок через відмінності у
середовищах розробки.
Зручною функціональністю редактора є автодоповнення коду (IntelliSense),
яка забезпечує підказки під час написання програмного коду, включаючи назви
змінних, функцій, параметрів, методів об’єктів тощо. Особливо корисною ця
можливість є в роботі з мовами JavaScript і TypeScript, де завдяки аналізу контексту
підказки допомагають уникнути синтаксичних і логічних помилок ще до запуску
коду. Це суттєво прискорює процес розробки й підвищує її точність.
Окремо слід відзначити інтеграцію з системою контролю версій Git, яка є
невід’ємною частиною VS Code. Вбудовані інструменти дозволяють виконувати всі
основні операції з Git-репозиторіями без необхідності виходити за межі редактора:
створювати коміти, перемикатися між гілками, робити злиття, переглядати історію
змін, проводити аналіз конфліктів. Це суттєво підвищує ефективність роботи
розробника та дозволяє зберігати цілісність коду на всіх етапах його змін.
Візуальна привабливість середовища також відіграє важливу роль. Інтерфейс
Visual Studio Code відзначається мінімалізмом, зручним розміщенням елементів,
широкими можливостями кастомізації (включно з темами оформлення), а також
підтримкою кількох мов, зокрема української. Навігація по проєкту, відкриття
файлів, пошук по коду, швидке перемикання між редакторами та терміналом – все
це реалізовано інтуїтивно та гнучко, що робить роботу комфортною навіть у великих
проєктах.
Вбудований термінал дозволяє запускати команди оболонки (bash, PowerShell,
cmd тощо) безпосередньо в межах редактора [4]. Це дає змогу встановлювати
пакети, запускати сервер, збирати проєкт або виконувати інші дії, не перемикаючись
24
між вікнами. Для веб-розробника, який працює з такими інструментами, як Node.js,
npm або yarn, це є особливо зручним.
Величезну роль у роботі відіграє система розширень, яка дозволяє розширити
базову функціональність редактора під конкретні задачі. Наприклад, у процесі
розробки веб-додатку часто використовуються такі розширення як Prettier
(автоматичне форматування коду), ESLint (статичний аналіз коду на наявність
помилок і невідповідностей стилю), Bracket Pair Colorizer (виділення парних дужок),
GitLens (розширений перегляд історії Git), Live Server (локальний сервер для
перегляду змін у реальному часі), Material Icon Theme (візуальні іконки для файлів і
папок), Firebase Tools (інтеграція з хмарними сервісами). Завдяки цьому VS Code
перетворюється на потужне середовище, адаптоване саме до специфіки
створюваного застосунку.
Значною перевагою є також підтримка віддаленої розробки. Завдяки
розширенням, таким як Remote SSH або Dev Containers, можна працювати з кодом,
що розміщений на віддалених серверах або у Docker-контейнерах, немов він
локальний. Це корисно при розробці на серверних середовищах або у спільних
середовищах CI/CD, а також для команди, яка працює над однією базою коду в
хмарі.
Visual Studio Code також підтримує зневадження коду (debugging) – ще одна
важлива функція, що дозволяє зупиняти виконання коду в певних точках,
переглядати значення змінних, викликати стек і аналізувати логіку роботи додатку.
Для JavaScript- та Node.js-застосунків інтеграція відлагоджувача відбувається без
додаткових налаштувань, що дає змогу швидко знаходити й усувати помилки.
Нарешті, варто відзначити спільноту користувачів та документацію. Visual
Studio Code має активну спільноту, велику кількість навчальних матеріалів, офіційну
та сторонню документацію, відео-уроки, блоги й форуми. Це особливо важливо для
початківців, які можуть швидко знайти відповідь на будь-яке питання, що виникає в
процесі розробки, або знайти оптимальне розширення для свого кейсу.
Таким чином, вибір Visual Studio Code, як функціонального середовища
розробки для створення веб-застосунку, обумовлений його широкою
25
функціональністю, підтримкою сучасних вебтехнологій, високою продуктивністю,
гнучкістю налаштування, активною підтримкою з боку спільноти та зручністю в
роботі. Саме ці якості зробили його оптимальним рішенням для реалізації проєкту з
обміну повідомленнями, що базується на клієнт-серверній архітектурі.
Рисунок 2.1 – Користувацький інтерфейс середовища розробки Visual Studio
Code [4]
2.2 Основні принципи розробки веб-застосунків
Розробка веб-застосунків є складним багатоступеневим процесом, що
потребує чіткого дотримання теоретичних і практичних принципів програмної
інженерії. Ці принципи є фундаментом, на якому базується ефективне створення,
масштабування, супровід та розвиток веб-рішень. Вони охоплюють як архітектурні
підходи, так і організацію коду, вибір технологій, принципи взаємодії з
користувачем, безпеку, продуктивність та інші аспекти. У межах даної роботи
26
розглянемо основні принципи, які забезпечують створення якісного,
масштабованого та зручного для користувача веб-застосунку.
Першим базовим принципом розробки є архітектурна структурованість, яка
передбачає чітке розділення проєкту на логічні частини. Найпоширенішим підходом
є використання клієнт-серверної архітектури. У цій моделі фронтенд (клієнт)
відповідає за взаємодію з користувачем, а бекенд (сервер) – за обробку даних,
авторизацію, зберігання інформації та логіку обміну [5]. Такий підхід дозволяє
досягти високої гнучкості, спрощує масштабування системи, а також дає змогу
одночасно працювати над різними частинами проєкту різним розробникам або
командам [5].
Другим принципом є інкапсуляція та модульність коду, що дозволяє
розбивати додаток на окремі компоненти чи модулі з чітко визначеною
відповідальністю. Це особливо важливо в сучасних фреймворках, таких як React, де
вся структура фронтенду базується на компонентному підході. Кожен компонент
повинен мати свою функцію, бути незалежним від інших компонентів настільки,
наскільки це можливо, та легко повторно використовуватися у різних частинах
інтерфейсу. На серверній частині модульність реалізується шляхом розділення
контролерів, сервісів, моделей і middleware. Це значно полегшує обслуговування
коду, тестування, а також підвищує його читабельність і зрозумілість.
Третім фундаментальним принципом є відокремлення логіки від
представлення (separation of concerns). У веб-застосунках це означає, що інтерфейс
користувача (HTML, CSS, JSX) має бути ізольований від бізнес-логіки (обробка
запитів, робота з базами даних, авторизація тощо). Такий розподіл дозволяє
змінювати зовнішній вигляд або логіку застосунку незалежно один від одного, не
порушуючи загальної структури.
Одним із ключових аспектів є також оптимізація продуктивності. Веб-додатки
мають бути швидкими, реагувати без затримок, мінімізувати кількість запитів до
сервера та завантаження ресурсів. Сучасні фреймворки надають інструменти для
покращення продуктивності: кешування, lazy loading, code splitting, мінімізація
файлів, використання CDN для розповсюдження контенту тощо. Крім цього,
27
важливе значення має структура бази даних, коректне використання індексів,
оптимізація SQL-запитів або запитів до NoSQL-баз, а також обмеження надмірної
передачі даних у мережі.
Наступним принципом є безпечність веб-застосунку. Забезпечення безпеки є
критично важливим, оскільки веб-застосунки найчастіше працюють у відкритому
середовищі Інтернету. Захист має охоплювати такі аспекти, як автентифікація
користувачів, авторизація доступу до ресурсів, шифрування переданих даних (через
HTTPS), захист від XSS-атак, CSRF-атак, SQL-ін’єкцій, обмеження кількості спроб
входу, валідація вхідних даних як на клієнтській, так і на серверній стороні. Важливо
також не зберігати паролі у відкритому вигляді, а використовувати сучасні
криптографічні алгоритми хешування з сіллю (наприклад, bcrypt).
Окремо слід згадати принцип зручності для користувача (usability). Інтерфейс
повинен бути простим, інтуїтивно зрозумілим, адаптивним до різних пристроїв, а
навігація – логічною та послідовною. UX/UI-дизайн є важливою частиною сучасної
розробки, оскільки від нього залежить, наскільки ефективно користувач буде
взаємодіяти з системою. Кольорова гама, шрифти, відстані між елементами,
наявність повідомлень про помилки або підтвердження дій – усе це формує
враження від додатку та впливає на задоволення користувачів.
Ще одним важливим принципом є адаптивність і респонсивність веб-
застосунків. У зв’язку з широким розповсюдженням мобільних пристроїв додатки
повинні однаково добре відображатися як на комп’ютерах, так і на смартфонах або
планшетах. Для цього використовуються технології адаптивної верстки – Flexbox,
CSS Grid, медіа-запити. Усе це дозволяє створити універсальний інтерфейс, який
змінюється відповідно до розміру екрана, зберігаючи функціональність і зручність.
У розробці сучасних веб-застосунків також важливим є принцип
інтерактивності. Інтерфейс повинен реагувати на дії користувача без необхідності
повного перезавантаження сторінки. Саме тому широкого розповсюдження набули
технології, які дозволяють створювати односторінкові застосунки (SPA), де контент
динамічно оновлюється на сторінці завдяки використанню JavaScript-фреймворків,
28
таких як React, Angular, Vue. Це забезпечує більш плавну взаємодію, кращу
швидкість роботи та приємніший користувацький досвід.
Принцип відтворюваності (reproducibility) є також важливим – здатність
проєкту бути однаково зібраним та розгорнутим у різних середовищах. Для цього
використовуються системи керування залежностями (npm, yarn), середовища
контейнеризації (Docker), а також системи безперервної інтеграції (CI/CD). Завдяки
цим інструментам будь-який розробник або адміністратор може швидко запустити
проєкт у тестовому або бойовому середовищі без втрати стабільності.
Ще одним невіддільним елементом є тестування веб-застосунків. Безперервна
перевірка функціональності є запорукою стабільної роботи системи.
Використовуються різні види тестування: модульне (unit testing), інтеграційне,
функціональне, регресійне. Наявність автоматизованих тестів дозволяє оперативно
перевірити зміни та уникнути появи критичних помилок після внесення нових
функцій.
Важливим принципом є масштабованість – здатність системи витримувати
зростання кількості користувачів, обсягу даних або навантаження без втрати
продуктивності. Цей принцип реалізується через оптимізацію архітектури,
застосування горизонтального та вертикального масштабування, розділення
відповідальностей між сервісами (наприклад, мікросервіси), використання
балансувальників навантаження та хмарних рішень.
Розробка веб-застосунків повинна ґрунтуватися на принципах відкритості до
змін і підтримки. Це означає, що код має бути написаний з урахуванням можливої
подальшої модифікації: із дотриманням іменних конвенцій, наявністю документації,
коментарів, використанням шаблонів проєктування, що дозволяє легко змінювати
структуру або логіку додатку без повного переписування системи.
2.3 Архітектура веб-застосунку для обміну повідомленнями з
використанням клієнт-серверної архітектури
У розробці сучасних веб-застосунків для обміну повідомленнями критично
важливим є вибір ефективної та гнучкої архітектури, яка забезпечить надійність,
29
масштабованість, швидкодію та зручність підтримки. Архітектурна модель, обрана
у даному проєкті, базується на класичному підході клієнт-серверної взаємодії, де
клієнт та сервер функціонують як окремі логічні сутності, що обмінюються даними
через уніфіковані інтерфейси [5]. Однак, особливістю цієї реалізації є використання
хмарної платформи Firebase як повноцінного бекенду, що надає сервіси збереження,
автентифікації та обміну даними без потреби в створенні окремого фізичного
сервера.
Фронтенд-частина веб-застосунку реалізована з використанням сучасного
фреймворку Next.js, який побудований на основі бібліотеки React. Такий вибір
зумовлений необхідністю забезпечення високої інтерактивності інтерфейсу,
динамічного оновлення вмісту без перезавантаження сторінки, підтримки
маршрутизації та серверного рендерингу. Компонентна модель, запропонована
React, дозволяє розробнику розбивати інтерфейс користувача на окремі логічні
частини, які відповідають за конкретні функції – відображення списку повідомлень,
форму введення тексту, інтерфейс логіну чи реєстрації [6]. Ці компоненти
взаємодіють між собою через пропси та стани, керовані засобами React, що
забезпечує гнучкість при розширенні або зміні функціональності застосунку [6].
Клієнтська частина також включає логіку взаємодії з Firebase. Взаємодія з
сервером не відбувається через традиційні REST API або GraphQL-запити, як у
багатьох класичних рішеннях, а безпосередньо через Firebase SDK. Це дозволяє
клієнту напряму звертатися до хмарної бази даних, автентифікаційного модуля та
інших сервісів. Такий підхід спрощує архітектуру, зменшує кількість проміжних
ланок і забезпечує негайне оновлення даних в інтерфейсі завдяки підтримці
синхронізації в реальному часі. Зокрема, Firestore – основна база даних в даному
проєкті підтримує реальні оновлення, що означає миттєву реакцію на зміни у
сховищі без необхідності ручного оновлення даних.
Firebase у цій архітектурі виступає як повноцінний бекенд-as-a-service. Це
означає, що усі серверні функції, які зазвичай реалізуються вручну за допомогою
Node.js або іншого серверного середовища, делегуються готовим хмарним
рішенням. Firebase надає модулі для автентифікації, бази даних, хмарного зберігання
30
файлів, розгортання та моніторингу додатку. Зокрема, Firebase Authentication
відповідає за обробку облікових записів користувачів, входу, реєстрації, а також
зберігання інформації про поточну сесію. Він інтегрується безпосередньо з
клієнтом, де перевірка автентичності користувача здійснюється через токени, що
зберігаються у браузері та автоматично додаються до кожного запиту.
Однією з ключових архітектурних переваг даного рішення є реалізація обміну
повідомленнями у режимі реального часу. Завдяки тому, що Firestore підтримує
підписку на зміну даних, клієнтський додаток автоматично оновлює інтерфейс при
кожному новому повідомленні, доданому в базу. Це забезпечує ефект миттєвої
комунікації, який є критичним для сучасних чат-додатків. Кожен користувач,
підключений до спільного чату, бачить нове повідомлення одразу після його
надсилання іншим користувачем без потреби оновлювати сторінку чи надсилати
додаткові запити.
Оскільки застосунок працює без традиційного бекенду, уся бізнес-логіка
розташована на стороні клієнта. Це означає, що клієнт відповідає за валідацію форм,
обробку помилок, визначення формату даних для запису в базу, а також за керування
станами додатку. Такий підхід значно пришвидшує розробку, але водночас потребує
підвищеної уваги до безпеки, оскільки код, що містить логіку доступу до ресурсу,
зберігається на клієнті. У цьому контексті особливо важливою є система правил
безпеки Firebase Security Rules, яка визначає, які саме операції можуть виконувати
користувачі залежно від їх прав доступу. Наприклад, лише авторизовані користувачі
можуть створювати повідомлення або переглядати чати, до яких вони мають доступ.
Ще однією важливою архітектурною особливістю є логіка збереження даних.
У Firestore дані зберігаються у вигляді колекцій та документів. Повідомлення, як
правило, є документами в окремій колекції, що може бути вкладеною у документ,
який представляє чат або канал. Така структура є гнучкою, дозволяє групувати
повідомлення за чатами, фільтрувати їх за датою або автором, а також реалізовувати
додаткові функції, такі як пагінація, пошук або реакції на повідомлення. Завдяки
NoSQL-природі Firestore розробник має можливість організувати дані у будь-якій
формі, що найкраще відповідає вимогам застосунку.
31
З погляду архітектури розгортання, такий веб-застосунок легко масштабується
завдяки можливості Firebase автоматично обробляти велике навантаження. Оскільки
сервер не реалізується вручну, а вся логіка обробляється на стороні клієнта або через
хмарну інфраструктуру Google, застосунок залишається стабільним навіть за
великої кількості активних користувачів. У разі потреби в розширенні
функціональності можна інтегрувати додаткові сервіси Firebase, такі як Cloud
Functions для реалізації обробки на сервері, або Cloud Messaging для push-сповіщень.
Ще одним перевагами обраної архітектури є мінімізація інфраструктурних
витрат. Відсутність необхідності орендувати сервери, налаштовувати бази даних,
слідкувати за безпекою з’єднань та оновленням серверного ПЗ робить такий підхід
особливо привабливим для невеликих команд, навчальних проєктів або швидких
MVP-рішень. Завдяки Firebase весь бекенд існує як сервіс, за яким відповідає окрема
платформа, що дозволяє зосередити увагу саме на бізнес-логіці та користувацькому
досвіді.
У підсумку, архітектура розробленого додатку демонструє ефективне
поєднання компонентно-орієнтованого клієнтського інтерфейсу на основі Next.js з
безсерверним бекендом, реалізованим через Firebase. Такий підхід відповідає
сучасним трендам у розробці веб-застосунків, забезпечує високу продуктивність,
простоту підтримки та розширення, а також надає всі необхідні інструменти для
створення повноцінного засобу обміну повідомленнями в реальному часі.
32
Рисунок 2.2 – Архітектурна схема
2.4 Розробка діаграми варіантів використання
Діаграма варіантів використання (use case diagram) (рис. 2.3) є важливою
частиною моделювання системи, яка дозволяє наочно відобразити функціональність
веб-застосунку з точки зору взаємодії користувача з системою [7]. Така діаграма
допомагає визначити основні сценарії поведінки, виявити ролі користувачів та
встановити межі системи.
У даному веб-застосунку, що реалізований на основі Next.js та Firebase,
основними учасниками є зареєстрований користувач та гість. Гість має обмежений
доступ і може лише переглядати інтерфейс входу або зареєструватися, тоді як
зареєстрований користувач отримує повний набір функцій: надсилання та
отримання повідомлень у реальному часі, перегляд історії чатів, вихід із системи.
Кожен варіант використання є окремим функціональним елементом системи,
що реалізується через взаємодію клієнтської частини з сервісами Firebase.
Наприклад, при надсиланні повідомлення клієнтська логіка взаємодіє з базою даних
Firestore, де зберігається новий запис, а інші користувачі миттєво отримують
оновлення завдяки підписці на зміни. Аутентифікація, у свою чергу, базується на
33
сервісі Firebase Authentication, що дозволяє користувачам входити у систему з
використанням електронної пошти та пароля.
Загалом, діаграма варіантів використання охоплює основні взаємодії між
користувачами та системою, формуючи основу для подальшого моделювання
компонентів, класів та сценаріїв.
Рисунок 2.3 – Діаграма варіантів використання
2.5 Проєктування структури бази даних
У веб-застосунку для обміну повідомленнями з використанням клієнт-
серверної архітектури на базі Firebase Cloud Firestore дані зберігаються у вигляді
колекцій і документів. Структура бази даних має бути ретельно спроєктована з
урахуванням специфіки NoSQL – денормалізованого зберігання інформації, де дані
групуються навколо основних сутностей та часто дублюються з метою оптимізації
запитів.
Основними сутностями у системі є користувачі, повідомлення та чати. Кожен
користувач зберігається в окремій колекції з унікальним ідентифікатором, який
також використовується для посилань у повідомленнях і чатах. Повідомлення
зберігаються як вкладені документи в колекції чату, що дозволяє ефективно
витягувати повідомлення в межах одного чату та відслідковувати історію
спілкування. Чат, у свою чергу, пов’язує між собою учасників через їх
ідентифікатори.
34
Хоча структура Firestore відрізняється від реляційних баз, для візуалізації
логічних зв’язків доцільно використовувати ER-діаграму, яка демонструє сутності,
їх атрибути та зв’язки між ними [9]. Нижче подано відповідну діаграму у синтаксисі
PlantUML.
Рисунок 2.4 – Entity-Relationship diagram
У цій структурі таблиця User містить основну інформацію про користувачів.
Chat є незалежною сутністю, яка представляє окрему розмову. ChatMember – це
зв'язувальна таблиця для реалізації зв'язку "багато-до-багатьох" між користувачами
та чатами. Message зберігає текстові повідомлення, які відносяться до певного чату
та мають автора. Зв’язки показують, що користувач може бути учасником багатьох
чатів, чат містить багато повідомлень, а кожне повідомлення має відправника.
Ця модель є концептуальною та адаптованою для розуміння логіки структури
даних у Firestore, хоча фактичне зберігання у Firebase реалізується у вигляді
вкладених документів без чіткої нормалізації. Якщо потрібно, можу допомогти з
генерацією зображення з цього PlantUML або адаптацією під SQL.
35
2.6 Опис процесу проєктування структури веб-застосунку для обміну
повідомленнями з використанням клієнст-серверної архітектури
Процес проєктування веб-застосунку з використанням клієнт-серверної
архітектури передбачає системний підхід до формування логіки, інтерфейсу,
маршрутизації, збереження даних, обробки подій та взаємодії з зовнішніми
сервісами. У випадку веб-застосунку для обміну повідомленнями цей процес є
особливо важливим, оскільки необхідно забезпечити передачу даних у реальному
часі, підтримку множинних сесій, синхронізацію повідомлень і високий рівень
надійності.
На першому етапі проєктування визначаються основні сценарії використання
додатку – автентифікація, перегляд чатів, відправлення та отримання повідомлень.
На основі цих сценаріїв формується загальна структура системи, яка поділяється на
клієнтську частину (інтерфейс користувача та логіка у браузері) та серверну частину
(керування даними та користувачами за допомогою хмарної інфраструктури
Firebase).
Особливу увагу було приділено логіці ініціалізації сесії, підписки на
оновлення в реальному часі, обробки введення повідомлення та виводу нових
повідомлень на екран. Для забезпечення реактивної поведінки додатку
застосовується модель обміну повідомленнями з використанням Firebase Cloud
Firestore, яка дозволяє клієнту автоматично отримувати оновлення з бази без
ручного оновлення сторінки.
Користувач починає взаємодію із застосунком зі сторінки авторизації, де може
увійти до системи за допомогою облікових даних або зареєструвати новий акаунт.
Після введення даних система надсилає запит до Firebase Authentication. У разі
успішного входу клієнт отримує токен автентифікації, який дозволяє здійснювати
подальшу взаємодію з базою даних. Усі подальші запити перевіряються на наявність
авторизації, відповідно до чого відображається інтерфейс користувача.
Після входу користувач бачить список доступних чатів, які він створив або до
яких був запрошений. Кожен чат має унікальний ідентифікатор, що дозволяє
36
фільтрувати повідомлення відповідно до вибраної розмови. Надсилання нового
повідомлення супроводжується записом документа до відповідної колекції у
Firestore. Інші клієнти, які підписані на цю колекцію, миттєво отримують оновлення
та відображають повідомлення у своєму інтерфейсі.
Нижче наведено розроблені діаграми діяльності процесу авторизації та
процесу надсилання повідомлень (рис. 2.5-2.6) та діаграму послідовності отримання
повідомлення в реальному часі (рис. 2.7).
Рисунок 2.5 – Діаграма діяльності процесу авторизації користувача
37
Рисунок 2.6 – Діаграма діяльності надсилання повідомлення
Рисунок 2.7 – Діаграма послідовності отримання повідомлення в реальному часі
38
Проєктування структури застосунку здійснювалося з урахуванням принципів
модульності, реактивності, масштабованості та простоти підтримки. Застосування
Firebase дозволяє уникнути необхідності самостійної реалізації серверної частини,
делегуючи обробку даних хмарному сервісу, що також значно підвищує безпеку та
стабільність роботи застосунку.
Інтерфейс клієнта побудований на компонентному підході, що полегшує
обслуговування коду, тестування та подальшу розробку. Кожен компонент
відповідає за конкретну дію – відображення чатів, виведення повідомлень, обробка
форм тощо. Вся взаємодія з базою даних реалізована через Firebase SDK, що
дозволяє легко управляти підписками на дані, обробляти зміни у реальному часі та
зберігати інформацію з мінімальними затримками.
В цілому, розробка структури застосунку забезпечує повну підтримку
ключових функцій – авторизації, обміну повідомленнями, синхронізації, що є
критичним для забезпечення якісної взаємодії між користувачами у середовищі
реального часу.
2.7 Проєктування інтерфейсу користувача
Проєктування інтерфейсу користувача є одним з основних етапів створення
веб-застосунку, оскільки саме через інтерфейс користувач взаємодіє з
функціональністю системи. У випадку застосунку для обміну повідомленнями
особливу увагу було приділено простоті, зручності та швидкості навігації, а також
здатності інтерфейсу адаптуватися до різних розмірів екранів.
Після авторизації користувач потрапляє на головну сторінку додатку, яка
поділена на декілька основних візуальних блоків. Ліворуч розташований список
доступних чатів, де відображаються назви або учасники розмов. Центральна частина
екрану призначена для відображення активного діалогу. У верхній частині
присутній заголовок із даними про активний чат, а нижня частина містить поле
введення повідомлень разом із кнопкою надсилання. Інтерфейс забезпечує негайну
реакцію на дії користувача: повідомлення, щойно надіслане, одразу відображається
39
у стрічці, а поле введення очищується. Процес взаємодії з інтерфейсом побудований
таким чином, щоб користувач не мав потреби шукати потрібні функції. Усі важливі
елементи розміщені у межах досяжності одного-двох кліків. Для зручності
передбачена можливість швидкого виходу з акаунту, а також перемикання між
чатами без оновлення сторінки. Усі елементи інтерфейсу є інтерактивними та
забезпечують візуальний зворотний зв’язок: кнопки змінюють свій вигляд при
наведенні, підказки з’являються при фокусі, а повідомлення про помилки або
статуси дій відображаються у вигляді ненав’язливих повідомлень у кутку екрана.
Головна мета інтерфейсного дизайну полягала у створенні середовища, яке не
відволікає користувача від головної дії – комунікації. Тому, візуальне оформлення
витримане в нейтральних тонах із використанням контрастних акцентів лише для
найважливіших дій – надсилання повідомлень, переходу між чатами, виходу з
облікового запису. Такий підхід дозволяє зменшити візуальне навантаження і
зробити інтерфейс інтуїтивно зрозумілим навіть для нових користувачів.
Застосунок підтримує адаптивне відображення – він однаково добре
функціонує на екранах різної ширини. На мобільних пристроях деякі частини
інтерфейсу можуть згортатися або переміщатися для забезпечення зручного
перегляду. Наприклад, список чатів автоматично ховається за меню, яке
відкривається за потреби, що дає змогу зосередити увагу на активному діалозі.
Особливу увагу було приділено типографіці та розмірності елементів.
Текстові блоки мають достатній контраст і читабельність, відстані між елементами
оптимізовані для швидкого сприйняття. Іконки використовуються лише там, де вони
однозначно передають функцію – наприклад, іконка виходу з системи, стрілка для
згортання меню або позначка надсилання.
Інтерфейс також передбачає обробку нестандартних ситуацій. Наприклад,
якщо втрачається інтернет-з’єднання, користувач бачить відповідне повідомлення у
верхній частині екрана. У разі виникнення помилки при надсиланні повідомлення
система відображає сповіщення з поясненням. Усі повідомлення про статус дій
зникають автоматично через декілька секунд, не порушуючи загального візуального
ритму роботи з застосунком.
40
Інтерфейс реалізовано з урахуванням принципів доступності. Всі інтерактивні
елементи мають достатній розмір для натискання, контраст кольорів відповідає
стандартам WCAG, а також підтримується навігація з клавіатури. Це розширює
потенційне коло користувачів і дозволяє комфортно працювати з додатком в різних
умовах – як на роботі, так і в дорозі.
З технічного боку всі елементи інтерфейсу створені з використанням сучасних
веб-технологій, які дозволяють забезпечити швидку реакцію на події, плавні анімації
та повну взаємодію з хмарним бекендом у реальному часі. У результаті створено
простий, легкий та функціональний інтерфейс, що повністю відповідає завданням
комунікаційного додатку.
Узагальнюючи, можна стверджувати, що проєктування інтерфейсу
користувача базувалося на принципах зручності, доступності, функціональності та
адаптивності. Отриманий результат (рис. 2.8) дозволяє користувачеві інтуїтивно
взаємодіяти з усіма можливостями системи, не потребуючи попереднього навчання
або інструкцій, що є запорукою ефективного використання веб-застосунку для
обміну повідомленнями в реальному часі.
Рисунок 2.8 – Інтерфейс користувача веб-застосунку
41
Висновки до розділу 2
У другому розділі було проведено комплексне проєктування веб-застосунку
для обміну повідомленнями з використанням клієнт-серверної архітектури. В
результаті опрацювання визначено функціональне середовище для розробки,
обґрунтовано вибір технологічного стеку, описано основні принципи розробки, а
також побудовано логічну та візуальну структуру системи.
Розробка архітектури веб-застосунку здійснювалась на основі моделі
розділення клієнтської та серверної частин, де клієнт реалізований за допомогою
Next.js, а серверна логіка делегована сервісам платформи Firebase. Такий підхід
дозволив забезпечити обмін повідомленнями в реальному часі, автоматичну
синхронізацію та масштабованість без потреби в окремому серверному оточенні.
У межах проєктування були створені діаграми варіантів використання,
діаграми діяльності та послідовності, які відображають логіку основних сценаріїв
роботи системи: авторизації, надсилання та отримання повідомлень. Окремо
проаналізовано структуру бази даних, спроєктовано сутності та зв’язки між ними у
вигляді ER-діаграми, що дозволяє ефективно зберігати й обробляти дані в Firestore.
Важливе місце посіло проєктування інтерфейсу користувача, де реалізовано
інтуїтивну, адаптивну та функціонально орієнтовану структуру. Забезпечено
мінімалізм в дизайні, зручність переходів між чатами, негайне відображення
повідомлень, а також адекватне візуальне реагування на дії користувача.
Таким чином, всі етапи проєктування реалізовані з дотриманням сучасних
стандартів веб-розробки, що створює надійну основу для подальшої реалізації
функціоналу, тестування та розгортання веб-застосунку у виробничому середовищі.
Розділ демонструє завершене бачення логічної, архітектурної та візуальної
структури веб-застосунку, що повністю відповідає поставленим у роботі вимогам.
42
3 ПРОГРАМНА РЕАЛІЗАЦІЯ
3.1 Постановка завдання
На основі проведеного аналізу, обґрунтування вибору архітектурного підходу
та спроєктованої структури застосунку, постає завдання програмної реалізації
системи для обміну повідомленнями, що працює в реальному часі та побудована за
принципами клієнт-серверної взаємодії. Постановка завдання охоплює
формулювання вимог до функціоналу, визначення технологічного підходу до
реалізації, деталізацію цілей, задач і очікуваних результатів.
Метою цієї частини роботи є реалізація інтерактивного, адаптивного і
функціонального застосунку, який дозволяє користувачам обмінюватися
повідомленнями в реальному часі з мінімальними затримками, підтримує
автентифікацію, забезпечує простий і зрозумілий інтерфейс, а також гарантує
стабільність роботи при зростанні кількості активних сесій. Рішення повинне
відповідати принципам модульності, масштабованості та безпеки.
На початковому етапі реалізації необхідно забезпечити створення базової
інфраструктури застосунку. Це включає налаштування середовища розробки,
підключення обраного фреймворку, ініціалізацію проєкту, організацію файлової
структури, а також підключення хмарних сервісів Firebase, які виступатимуть
серверною частиною додатку. Реалізація повинна забезпечити з’єднання з базою
даних Firestore, налаштування доступу до сервісу автентифікації, а також
визначення правил безпеки на рівні Firebase Security Rules.
Ключовим функціональним компонентом застосунку є система обміну
повідомленнями. Завданням розробника є реалізація механізму, за яким користувач,
маючи дійсний акаунт, може надсилати текстові повідомлення до вибраного чату, а
також миттєво отримувати повідомлення, надіслані іншими користувачами. Для
цього потрібно реалізувати не лише форму введення повідомлень, але й підключити
клієнт до бази даних у режимі реального часу, щоб забезпечити автоматичне
оновлення вмісту інтерфейсу без перезавантаження сторінки. У рамках цього
43
функціоналу важливо також передбачити логіку відображення повідомлень у
хронологічному порядку, відображення автора, часу надсилання та стилізацію
вхідних і вихідних повідомлень.
Окремим завданням є реалізація функціоналу автентифікації. Користувач
повинен мати можливість зареєструвати новий акаунт із використанням електронної
пошти та пароля, а також входити до системи з уже існуючим акаунтом. Усі
функціональні частини застосунку мають бути доступні лише для авторизованих
користувачів. У випадку, якщо користувач не увійшов до системи, він автоматично
перенаправляється на сторінку входу. Для цього необхідно реалізувати механізми
перевірки стану авторизації та налаштувати захист маршрутів у межах клієнтської
частини.
Після входу користувач повинен мати змогу переглядати список чатів. Якщо
система передбачає групові або приватні чати, необхідно реалізувати логіку
зберігання метаданих про чати, зокрема їх унікальних ідентифікаторів, переліку
учасників, назв тощо. У випадку реалізації базового одноканального чату (спільного
для всіх), слід обмежитися одним чатом, до якого автоматично підключаються всі
авторизовані користувачі. У будь-якому з варіантів список повідомлень має бути
пов’язаний із конкретним чатом і завантажуватись автоматично при відкритті
відповідного інтерфейсу.
Інтерфейс застосунку повинен бути побудований згідно з раніше
спроєктованою структурою. Його розробка має відповідати вимогам адаптивності, а
саме – інтерфейс повинен коректно відображатися на різних пристроях, зокрема на
мобільних телефонах, планшетах та ПК. Для цього використовуються сучасні
підходи до верстки, такі як гнучкі сітки, адаптивні стилі, а також можливість
приховування або автоматичного перемикання між елементами залежно від ширини
вікна.
Крім реалізації основного функціоналу, важливо забезпечити стабільність та
обробку помилок. Застосунок має реагувати на випадки втрати з’єднання з
інтернетом, відсутність доступу до бази даних, неправильне введення даних, а також
на дії, які не дозволені згідно з політикою безпеки. Усі ці ситуації повинні
44
супроводжуватися відповідними повідомленнями для користувача, які не заважають
роботі, але водночас інформують про поточний стан системи.
До задач реалізації також входить обробка подій життєвого циклу застосунку.
Наприклад, після виходу користувача з системи повинна очищатися його сесія, а
інтерфейс повертатися на сторінку входу. Під час переходу між сторінками має
зберігатися контекст користувача, що забезпечує безперервну роботу застосунку.
Також передбачається збереження повідомлень у базі даних для подальшого
доступу – історія чату має бути доступною після повторного входу до системи.
З технічного боку, реалізація веб-застосунку передбачає використання таких
технологій, як JavaScript, React, Next.js для створення інтерфейсу користувача, а
також Firebase для бекенд-функціоналу. Інтеграція з Firebase виконується за
допомогою офіційного SDK, який дозволяє здійснювати всі необхідні операції:
авторизацію, читання та запис повідомлень, підписку на оновлення, обробку
помилок та забезпечення безпеки на рівні клієнта. Збереження повідомлень, їх
завантаження та відображення реалізується через функції взаємодії з Firestore –
хмарною базою даних NoSQL, яка автоматично оновлює клієнтську частину при
зміні даних. Окрему увагу в процесі розробки необхідно приділити забезпеченню
безпеки. Необхідно гарантувати, що користувач може переглядати лише ті дані, до
яких має доступ, не може підмінити повідомлення інших користувачів або
надсилати дані від чужого імені. Це досягається не лише за рахунок клієнтських
перевірок, а й через використання правил доступу Firebase, які визначають дозволи
на читання і запис у базі залежно від авторизаційного стану користувача.
Постановка завдання в межах програмної реалізації завершується
визначенням результатів, які мають бути досягнуті після завершення етапу. У
підсумку має бути створено повністю функціональний веб-застосунок, доступний у
браузері, який підтримує реєстрацію та вхід користувачів, обмін повідомленнями в
реальному часі, збереження повідомлень, безпечну авторизацію, адаптивний
інтерфейс і обробку помилок. Застосунок повинен мати зрозумілу навігацію,
працювати стабільно, мати сучасний візуальний вигляд і відповідати критеріям
45
якості веб-застосунків. Усі функції повинні бути протестовані та забезпечувати
взаємодію між кількома користувачами в режимі реального часу.
У процесі реалізації веб-застосунку для обміну повідомленнями розробка
велася за компонентним підходом, де кожен інтерфейсний та функціональний блок
представлений у вигляді окремої логічної одиниці. Такі компоненти виконують роль
незалежних класів у межах логіки побудови системи.
Діаграма класів (рис. 3.1) дозволяє узагальнити архітектурну модель
застосунку з погляду об’єктно-орієнтованої парадигми, що значно полегшує
розуміння структури, зв’язків та відповідальностей між елементами.
Основними логічними одиницями виступають модулі, які відповідають за вхід
користувача, відображення списку чатів, побудову заголовків та підвалу чату, а
також головну обробку повідомлень. Усі ці компоненти взаємодіють між собою
через передачу параметрів, станів та обробників подій, які дозволяє розглянути
діаграма класів [10].
Рисунок 3.1 – Діаграма класів проєкту
Компонент Login відповідає за автентифікацію користувача за допомогою
інтеграції з Firebase. Він відображається у випадку, якщо користувач ще не
46
авторизований, і містить метод виклику автентифікації через обліковий запис
Google.
Компонент Sidebar реалізує логіку побудови бокового меню, де
відображається список чатів. Він взаємодіє з базою даних, завантажуючи відповідні
чати, а також дозволяє створити новий чат. Компонент реагує на натискання
користувача, перенаправляючи його до конкретного діалогу.
Компонент Topbar відповідає за відображення заголовка активного чату. Він
містить інформацію про учасника розмови, з яким ведеться діалог, і
використовується у верхній частині інтерфейсу чату.
Компонент Bottombar реалізує введення нового повідомлення. Він зберігає
текстове значення введеного повідомлення та реалізує логіку надсилання до
Firestore. Після натискання кнопки повідомлення додається до відповідної колекції
повідомлень.
Chat як компонент реалізує головну логіку відображення розмови. Він
завантажує повідомлення із бази даних, відображає їх у хронологічному порядку,
формує зовнішній вигляд повідомлень залежно від відправника, а також підключає
верхню (Topbar) та нижню (Bottombar) частину інтерфейсу.
Клас Message уявляє собою структуру даних, яка містить текст повідомлення,
відправника та часову мітку. Такі повідомлення зберігаються в Firestore та
виводяться на інтерфейс користувача.
Компонент App контролює відображення всього додатку. Якщо користувач не
авторизований, показується Login, якщо авторизований – відповідна частина
застосунку, включаючи Sidebar, Chat і Topbar.
Всі ці класи логічно пов’язані між собою: Sidebar відповідає за навігацію між
чатами, Chat використовує Topbar і Bottombar, а Message є частиною внутрішньої
структури діалогу. Така архітектура дозволяє забезпечити модульність, зручність
тестування та гнучке масштабування функціоналу в майбутньому.
47
3.2 Інтерфейс веб-застосунку для обміну повідомленнями
Інтерфейс користувача – це ключовий елемент веб-застосунку що
безпосередньо впливає на ефективність взаємодії користувача з системою. У процесі
реалізації веб-застосунку для обміну повідомленнями особлива увага приділялася
створенню простого, інтуїтивного, адаптивного та мінімалістичного інтерфейсу.
Його головне завдання – забезпечити максимально зручну комунікацію між
користувачами без зайвих елементів, які могли б відволікати або ускладнювати
навігацію.
Початковий екран застосунку відображає форму авторизації. Інтерфейс
побудований навколо єдиного функціонального елемента – кнопки входу за
допомогою Google. Візуально ця сторінка представлена у вигляді компактного блоку
з логотипом сервісу в центрі та кнопкою входу в нижній частині. Такий підхід дає
змогу користувачеві швидко зрозуміти, що для початку роботи потрібно
авторизуватися через обліковий запис Google. Сторінка має стриману кольорову
гаму, де фон затемнений, а елементи управління мають яскраво виражений акцент.
Це сприяє фокусуванню уваги на головній дії – вході в систему.
Після успішної авторизації користувач автоматично перенаправляється до
головного вікна чату. Інтерфейс розділений на кілька логічних частин. Ліворуч
розміщується бічна панель з аватаром, кнопкою створення нового чату та списком
доступних діалогів. Для кожного діалогу відображається адреса електронної пошти
іншого учасника або назва чату, що дозволяє швидко ідентифікувати потрібну
розмову. Кнопка створення нового чату винесена окремо й візуально виділена для
полегшення доступу до цієї функції.
Центральна частина інтерфейсу – це вікно активного чату. У верхній частині
розташований заголовок, який містить аватар і email користувача, з яким ведеться
переписка. У центральній зоні відображається потік повідомлень, який автоматично
оновлюється в реальному часі. Повідомлення візуально розділяються залежно від
відправника: вхідні розташовуються ліворуч та мають блакитне тло, вихідні –
48
праворуч і позначаються світло-зеленим фоном. Таке оформлення забезпечує чітке
візуальне розмежування між повідомленнями користувача та його співрозмовника.
Нижня частина інтерфейсу чату – панель введення повідомлення. Вона
включає текстове поле та кнопку надсилання. Після введення тексту й натискання
кнопки повідомлення миттєво зберігається в базі даних Firestore і відображається в
чаті без перезавантаження сторінки. Цей механізм реалізовано за допомогою
реального часу синхронізації з Firestore, що забезпечує високий рівень
інтерактивності й плавності в роботі застосунку [8].
Уся система побудована відповідно до принципів адаптивного дизайну.
Інтерфейс коректно масштабується на різних пристроях – як на широкоформатних
моніторах, так і на мобільних екранах. У мобільній версії деякі елементи, такі як
список чатів, можуть бути згортаними або переміщатися у вигляді окремого меню,
що відкривається за потреби. Завдяки цьому користувач отримує повний функціонал
незалежно від типу пристрою.
Інтерфейс реалізований засобами React і стилізований із використанням
сучасних CSS-інструментів [11]. Під час розробки було забезпечено підтримку
візуального зворотного зв’язку: зміна кольору елементів при наведенні, індикатори
активного стану, валідація полів. Наприклад, кнопка надсилання недоступна при
порожньому полі, а після відправки повідомлення поле очищується автоматично, що
створює відчуття плавної взаємодії з системою.
Загалом інтерфейс демонструє збалансоване поєднання функціональності та
простоти. Він не перевантажений візуальними ефектами, але при цьому повністю
відповідає сучасним вимогам до UI-дизайну. Завдяки цьому користувач має змогу
зосередитися на основному – спілкуванні, без потреби витрачати час на пошук
функцій або адаптацію до інтерфейсу.
Візуальна частина інтегрована в архітектуру проєкту таким чином, що
дозволяє легко підтримувати, розширювати й змінювати структуру інтерфейсу без
суттєвого впливу на логіку застосунку.
49
3.3 Програмна реалізація веб-застосунку для обміну повідомленнями з
використанням клієнт-серверної архітектури
Реалізація веб-застосунку для обміну повідомленнями проводилася за
компонентно-орієнтованим підходом із використанням сучасних веб-технологій.
Основу клієнтської частини становить фреймворк Next.js, який дозволяє поєднувати
можливості React для створення односторінкових застосунків із функціональністю
серверного рендерингу [12]. Серверна частина додатку реалізована на основі
Firebase, який виконує роль інфраструктури для автентифікації користувачів,
збереження повідомлень і обміну даними в реальному часі.
Ключовим етапом реалізації стало налаштування клієнт-серверної взаємодії.
За збереження користувачів і повідомлень відповідає хмарна база даних Cloud
Firestore, яка підтримує автоматичне оновлення вмісту клієнтського інтерфейсу
через механізм підписки (onSnapshot) [8]. Це означає, що при додаванні нового
повідомлення до бази, всі підписані клієнти миттєво отримують оновлення без
необхідності оновлювати сторінку чи здійснювати додаткові запити.
Перед початком реалізації було створено проєкт Firebase, де налаштовано
Authentication, Firestore Database і Firebase SDK. Дані про конфігурацію (ключ API,
ідентифікатори проєкту, домени автентифікації) були підключені до клієнтської
частини додатку через окремий файл ініціалізації. Firebase SDK імпортується
безпосередньо у компоненти, які здійснюють обробку повідомлень, створення чатів,
автентифікацію та інші дії з даними.
Процес авторизації користувачів реалізований через Google Sign-In, що надає
можливість входу за допомогою облікового запису Google. У разі успішної
автентифікації Firebase надає об’єкт користувача, який містить унікальний
ідентифікатор, email та аватар. Ця інформація зберігається у стані застосунку й
надалі використовується для відображення ідентифікатора в чаті, фільтрації
повідомлень та контролю доступу.
Уся логіка побудови інтерфейсу реалізована засобами React. Кожна частина
UI – вхід, чат, бічне меню, повідомлення, текстове поле – реалізована як окрема
50
функціональна одиниця з внутрішнім станом та обробниками подій. Наприклад,
після введення тексту в поле повідомлення, значення зберігається у стані й
передається до Firestore при натисканні кнопки надсилання. Далі повідомлення
автоматично зберігається у відповідній колекції в базі даних та миттєво передається
іншим користувачам.
Структура бази даних складається з колекцій "chats" та "messages". Кожен чат
має унікальний ID, створений при натисканні на кнопку створення нового чату.
Повідомлення зберігаються як вкладені документи в межах кожного чату. Всі
повідомлення мають інформацію про відправника, вміст та часову мітку. Запис
нового повідомлення супроводжується додаванням документа до підколекції, після
чого оновлюється інтерфейс за допомогою onSnapshot.
Для безпечної роботи застосунку реалізовано обмеження доступу через
Firebase Security Rules. Наприклад, лише авторизований користувач має право
запису повідомлень до свого чату. Читання дозволяється лише для користувачів, які
мають доступ до відповідного документу чату. Це дозволяє зберігати
персоналізацію чатів, ізолювати повідомлення одного користувача від іншого та
уникати стороннього втручання в хід розмови.
Крім цього, було реалізовано функцію відображення історії повідомлень. При
відкритті певного чату відбувається завантаження всіх відповідних повідомлень із
Firestore у хронологічному порядку. Інтерфейс миттєво адаптується, оновлюючи
потік повідомлень у разі додавання нових або зміни існуючих даних.
У межах застосунку передбачено обробку помилок – наприклад, якщо не
вдалося здійснити автентифікацію або якщо користувач вийшов з системи,
інтерфейс повертається на екран входу. Також реалізовано захист маршрутів:
маршрути, що потребують авторизації, закриті для неавторизованих користувачів.
Перевірка автентичності виконується за допомогою Firebase Auth Listener.
Важливим етапом реалізації стала адаптація інтерфейсу до різних розмірів
екрану. Всі стилі реалізовані з урахуванням вимог до адаптивності: гнучкі сітки,
медіа-запити, умовне відображення елементів. Це дозволяє працювати з додатком як
51
на ПК, так і на мобільному пристрої без втрати функціональності чи зручності
користування.
Користувацький досвід також покращується завдяки використанню плавних
переходів, фокусів на текстових полях, миттєвому очищенню після надсилання, а
також кольоровому розділенню повідомлень. Сторонні бібліотеки не
використовуються, що дозволяє зберегти мінімальну вагу додатку й забезпечити
швидке завантаження. У фінальному варіанті веб-додатку реалізовано повний
базовий функціонал системи обміну повідомленнями в реальному часі з
урахуванням основних вимог: підтримка автентифікації, збереження повідомлень,
синхронізація, захист доступу, адаптивний дизайн та інтуїтивний інтерфейс.
Реалізація є масштабованою: за потреби її можна розширити додатковими
функціями – приватними чатами, груповими розмовами, підтримкою файлів, push-
сповіщеннями або використанням Cloud Functions для обробки подій на сервері.
Програмна реалізація веб-застосунку побудована за принципами
компонентно-орієнтованої архітектури. Уся функціональність поділена на окремі
компоненти, кожен з яких відповідає за чітко визначений набір дій. Основні
компоненти, що формують логіку взаємодії з користувачем та базою даних,
наведено нижче.
Login (рис 3.2) – компонент, який відповідає за автентифікацію користувачів.
Він забезпечує вхід до системи за допомогою Google-акаунта через Firebase
Authentication. Після натискання кнопки авторизації викликається метод
signInWithGoogle, який ініціалізує процес входу. У випадку успішного входу
користувач автоматично перенаправляється до головного інтерфейсу додатку.
Компонент реалізований з використанням Chakra UI та має просту, фокусовану
структуру, де відображається лише логотип і кнопка входу.
52
Рисунок 3.2 – Компонент Login.js
Sidebar (рис. 3.3) – бічна панель, яка виконує роль навігаційного меню між
чатами. Вона відображає список активних чатів, дозволяє створювати новий чат і
здійснювати вихід із системи. Компонент завантажує список чатів з бази Firestore,
фільтрує ті, де бере участь поточний користувач, і дозволяє перейти до конкретної
розмови. Також у верхній частині панелі відображається аватар та ім’я користувача,
що підвищує персоналізацію інтерфейсу.
Рисунок 3.3 – Компонент Sidebar.js
53
Topbar – верхня панель активного чату. Вона відображає інформацію про
співрозмовника, зокрема аватар та адресу електронної пошти. Цей компонент є
статичним у межах діалогу і не містить додаткової логіки, однак виконує важливу
роль у формуванні структури діалогового вікна.
Bottombar – нижня панель введення повідомлень. Вона містить текстове поле,
де користувач вводить повідомлення, а також реалізує логіку його надсилання. При
натисканні кнопки надсилання повідомлення зберігається в базі даних Firebase з
урахуванням ID поточного чату, адресата та часу надсилання. Компонент
автоматично очищує поле після відправлення, що підвищує зручність взаємодії.
_app.js (рис. 3.4) – компонент, який є точкою входу для всієї програми. Тут
реалізується перевірка стану авторизації користувача. Якщо дані ще завантажуються
— відображається індикатор завантаження. Якщо користувач не авторизований –
викликається компонент Login. Якщо авторизований – рендериться основний
застосунок. Таким чином, _app.js виконує логіку контролю доступу та загальне
стилістичне оформлення через ChakraProvider.
Рисунок 3.4 – Компонент _app.js
54
index.js – головна сторінка додатку, яка відображає Sidebar. Вона
використовується як основний маршрут, де відображається список чатів, доступних
користувачу, без активного діалогу. Перехід до конкретного чату відбувається при
взаємодії з Sidebar.
[id].js (рис. 3.5) – головна логіка діалогу між користувачами. Цей файл
обробляє маршрут /chat/:id, який відповідає певному чату. Компонент завантажує
дані про чат, список повідомлень, а також забезпечує їх відображення в реальному
часі. Він також підключає верхню та нижню панель і забезпечує автоматичну
прокрутку до останнього повідомлення. Усі повідомлення завантажуються у
хронологічному порядку за допомогою orderBy ("timestamp").
Рисунок 3.5 – Компонент [id].js
Кожен компонент пов’язаний з іншими через передачу параметрів, спільний
доступ до автентифікації користувача та спільну роботу з Firebase. Така структура
дозволяє підтримувати чітке розділення обов’язків, спрощує тестування і
модифікацію окремих частин без впливу на загальну архітектуру застосунку.
55
3.4 Особливості тестування веб-застосунків
Тестування веб-застосунків є важливою складовою процесу забезпечення
якості програмного продукту. Його основна мета – виявити помилки, недоліки та
непередбачені сценарії поведінки системи до моменту її розгортання у реальному
середовищі. Для застосунків, які працюють у режимі реального часу та побудовані
за клієнт-серверною архітектурою, зокрема таких, як веб-застосунок для обміну
повідомленнями, тестування набуває особливої важливості, оскільки необхідно не
лише перевірити загальну функціональність, а й переконатися у правильності
синхронізації даних, стабільності при навантаженні та коректності відображення
інтерфейсу.
Під час тестування веб-застосунків виділяють декілька рівнів перевірки, кожен
з яких має свої цілі, інструменти та методи. Основними є модульне тестування,
інтеграційне тестування, функціональне тестування, тестування інтерфейсу
користувача, тестування безпеки, адаптивності та продуктивності.
У межах модульного тестування перевіряються окремі частини логіки, як-от
функції надсилання повідомлень, перевірки автентифікації, обробники подій тощо.
Хоча в проєкті використано переважно Firebase SDK та компоненти React,
можливим є написання юніт-тестів для окремих функцій обробки введених даних,
перевірки правильності формування об'єктів повідомлень або виклику зовнішніх
методів Firebase. Такі тести дозволяють перевірити правильність поведінки
функціоналу в ізоляції.
Інтеграційне тестування передбачає перевірку взаємодії між різними
компонентами. У випадку цього веб-додатку критичним є правильне з'єднання
клієнта з Firebase: зокрема, успішна автентифікація, підключення до Firestore,
підписка на оновлення повідомлень і коректне збереження нових повідомлень. Тут
особливо важливо тестувати реальні сценарії: чи відображається нове повідомлення
для обох користувачів у реальному часі, чи зберігаються часові мітки, чи працює
автоматичне оновлення інтерфейсу без перезавантаження сторінки.
56
Функціональне тестування охоплює перевірку того, чи працює система згідно з
поставленими вимогами. Наприклад, чи можливий вхід через Google-акаунт, чи
формується список чатів, чи надсилається повідомлення, чи можливо вийти із
системи. Таке тестування може проводитися вручну або з використанням
фреймворків типу Cypress чи Playwright, які дозволяють автоматизувати сценарії з
натисканням кнопок, заповненням полів, переходом між сторінками. Тестування
інтерфейсу користувача є важливим при оцінці якості взаємодії з системою.
Зокрема, перевіряється коректність відображення компонентів на різних пристроях,
відповідність кольорової гами, правильне вирівнювання елементів, реакція на
натискання та інші дії користувача. У застосунку, який було реалізовано, велика
увага приділялася адаптивності: тому тестування охоплювало екрани різної ширини,
відображення повідомлень на мобільних пристроях, функціональність навігації на
смартфонах.
Ще одним важливим напрямом є тестування безпеки. Оскільки веб-застосунок
взаємодіє з Firebase – системою, що реалізує політику доступу через Security Rules,
необхідно перевірити, що неавторизований користувач не має доступу до закритих
чатів або функцій, які йому не належать. Також слід переконатися, що повідомлення
не можуть бути модифіковані сторонніми особами, а користувачі не мають
можливості надсилати повідомлення від імені інших.
У рамках тестування продуктивності важливо перевірити, як система
поводиться при збільшенні кількості користувачів або повідомлень. Для цього
моделюються ситуації інтенсивного обміну повідомленнями або одночасного входу
великої кількості користувачів у чат. Firestore дозволяє масштабувати додаток
автоматично, проте інтерфейсна частина має бути достатньо оптимізованою, щоб
обробляти великі обсяги даних без затримок. Для цього перевіряється час
завантаження повідомлень, плавність прокрутки, швидкість реакції кнопок тощо.
Особливою формою є тестування на збої – перевірка поведінки системи при
втраті з’єднання з мережею, розриві сесії, закритті браузера або очищенні кешу. У
таких випадках додаток має зберігати поточний стан або повідомляти користувача
про необхідність повторного входу. Наприклад, якщо користувач втрачає інтернет-
57
з'єднання, у чаті має з'явитися повідомлення про помилку, але додаток не повинен
завершувати роботу.
У контексті тестування веб-застосунку для обміну повідомленнями важливо
також перевірити сценарії багатокористувацької взаємодії. Сюди входить одночасне
відкриття чату з двох пристроїв, надсилання повідомлень з обох сторін, перевірка
синхронного відображення повідомлень, валідація хронології надсилання тощо. Це
дозволяє переконатися, що система правильно реалізує режим реального часу.
Варто також згадати про тестування доступності – перевірку можливості
використання додатку людьми з особливими потребами. Хоча в рамках реалізації
базового функціоналу це не було головним пріоритетом, однак уже на етапі розмітки
коду важливо використовувати семантичні елементи, додавати атрибути aria-label, а
також забезпечити достатній контраст кольорів та доступність навігації з клавіатури.
Таким чином, тестування веб-застосунку є багаторівневим процесом, що
включає в себе перевірку як окремих функцій, так і всієї системи в цілому. Для
додатків із клієнт-серверною архітектурою, які працюють у режимі реального часу,
важливо забезпечити точність передачі даних, правильну синхронізацію між
клієнтами, стійкість до помилок та загроз, а також відповідність загальним
принципам веб-розробки. Усі ці аспекти були враховані в межах реалізації та
тестування розробленого застосунку, що дозволяє говорити про його придатність до
використання в реальному середовищі.
3.5 Тестування веб-застосунку для обміну повідомленнями з
використанням клієнт-серверної архітектури
Тестування реалізованого веб-застосунку для обміну повідомленнями є
важливою частиною життєвого циклу програмного продукту, що дозволяє
гарантувати його коректну роботу, надійність та стабільність при реальній
експлуатації. У додатку, де важливу роль відіграють такі аспекти, як обробка
повідомлень у реальному часі, автентифікація, рендеринг інтерфейсу та взаємодія з
хмарною базою даних, тестування повинно охоплювати не лише кінцевий
58
функціонал, а й внутрішню логіку, структуру та відповідність очікуваній поведінці
системи.
У рамках даної кваліфікаційної роботи бакалавра було реалізовано перевірку
застосунку як вручну, так і за допомогою автоматизованих тестів. Особливу увагу
приділено модульному тестуванню, яке дозволяє оцінити правильність роботи
окремих логічних блоків у ізоляції від решти системи [13]. Це дає змогу своєчасно
виявити логічні помилки, порушення очікуваної структури або неправильне
поводження функцій при змінних вхідних даних.
Першим етапом тестування стало створення сценаріїв для перевірки
коректності авторизації. Метою було перевірити, чи викликається функція
автентифікації при натисканні кнопки входу, чи правильно обробляються помилки
при невдалому вході, чи відображається відповідний інтерфейс залежно від стану
авторизації користувача. Було створено умовні тести, які перевіряють:
чи викликається signInWithPopup() з об’єктом auth (рис. 3.6);
чи змінюється стан користувача після авторизації;
чи перенаправляє система користувача до головної сторінки після входу.
Рисунок 3.6 – Модульний тест для авторизації
Наступним блоком тестування є функції надсилання повідомлень (рис. 3.7). У
межах тесту перевірялося, чи створюється об’єкт повідомлення з потрібними
полями, чи викликається функція запису в базу даних, і чи очищується поле
введення після відправки. Також моделювалися ситуації, коли поле повідомлення
порожнє – в таких випадках надсилання не повинно відбуватися. Наведений нижче
модульний тест перевіряє, що при наявності тексту у полі надсилається
повідомлення:
59
Рисунок 3.7 – Модульний тест для надсилання повідомлень
Особливе значення має тестування відображення повідомлень (рис. 3.8). У
додатку реалізована підписка до бази даних через Firebase onSnapshot, і важливо
було перевірити, що компоненти правильно рендерять повідомлення в
хронологічному порядку, що відправлені повідомлення відображаються з
відповідною стилізацією, і що при завантаженні інтерфейс автоматично
прокручується до останнього повідомлення. Для цього створено макети даних, які
імітують об’єкти Firestore:
Рисунок 3.8 – Модульний тест для відображення повідомлень
Тестування логіки виводу чатів включало перевірку, чи правильно
відображаються лише ті чати, в яких бере участь поточний користувач, чи
відбувається редирект при виборі чату, та чи правильно рендериться список без
помилок. Для цього застосовано перевірку умовного рендерингу та взаємодії з
useRouter (у випадку використання Next.js).
Окремим типом перевірки стала валідація на безпеку даних. Хоча перевірка
Firebase Security Rules не може бути реалізована у форматі класичного юніт-тесту, у
рамках ручного тестування були перевірені сценарії доступу до чатів
60
неавторизованими користувачами, спроба надсилання повідомлень без входу,
перегляд чужих повідомлень тощо. Усі ці сценарії були успішно заблоковані за
рахунок правильно налаштованих правил безпеки Firebase.
Значну роль відіграло тестування відображення інтерфейсу. Було перевірено,
як змінюється розташування елементів при зміні розміру вікна, чи залишаються
активними кнопки, чи правильно працюють поля введення та стилі при взаємодії. У
разі некоректного завантаження компонентів застосунок має відображати індикатор
завантаження, а не порожній екран або помилки.
У межах продуктивності було змодельовано надсилання великої кількості
повідомлень у короткий проміжок часу. Завдяки реальному часу оновлення Firestore,
інтерфейс залишався стабільним, а прокручування не викликало затримок. Це
свідчить про ефективну реалізацію механізму обробки даних, що надходять через
WebSocket-з'єднання Firebase.
Підсумовуючи проведене тестування, можна стверджувати, що веб-
застосунок пройшов усі основні типи перевірок: модульне, інтеграційне,
функціональне та UI-тестування. Було перевірено як окремі функції, так і сценарії
поведінки користувача в реальному часі. Автоматизовані тести дозволили
забезпечити стабільність логіки в умовах зміни даних, а ручні перевірки виявили й
усунули неочевидні UX-проблеми.
Таким чином, тестування веб-застосунку підтвердило його функціональну
готовність до реального використання, відповідність заявленим вимогам, а також
стійкість до помилок і нестандартних ситуацій. Завдяки тестам вдалося забезпечити
високу якість, зручність і стабільність комунікаційної системи, побудованої за
клієнт-серверною архітектурою.
Висновки до розділу 3
У третьому розділі здійснено безпосередню реалізацію веб-застосунку для
обміну повідомленнями з використанням клієнт-серверної архітектури, що
базується на сучасних веб-технологіях. У результаті виконаної роботи реалізовано
61
повнофункціональний засіб комунікації, який підтримує авторизацію, створення
чатів, обмін повідомленнями в реальному часі, динамічне оновлення інтерфейсу та
роботу з хмарною базою даних Firebase Firestore.
Розробка розпочалася з формулювання завдання, де було визначено основні
цілі – забезпечення простого, швидкого і стабільного способу обміну текстовими
повідомленнями. Після цього описано архітектуру клієнтської частини, побудовану
за допомогою Next.js, та реалізовано її взаємодію з серверною частиною, яка
представлена сервісами Firebase. У межах реалізації створено набір взаємозалежних
компонентів, що забезпечують обробку авторизації, рендеринг списку чатів,
введення та виведення повідомлень.
Окрему увагу було приділено інтерфейсу користувача. Реалізовано
адаптивний, мінімалістичний, інтуїтивно зрозумілий інтерфейс, що забезпечує легку
навігацію та взаємодію без перевантаження елементами. Кожен етап взаємодії із
застосунком – від входу в систему до перегляду й надсилання повідомлень –
продуманий таким чином, щоб забезпечити позитивний досвід користування.
Здійснено комплексне тестування розробленого застосунку, що включало як
модульні, так і інтеграційні тести, а також ручну перевірку функціональності,
адаптивності та взаємодії з Firebase. Запропоновані тестові сценарії дозволили
виявити потенційні недоліки та переконатися в коректності роботи логіки
застосунку. Сформовано набір юніт-тестів, які перевіряють логіку надсилання
повідомлень, взаємодію з базою даних, авторизацію та обробку подій.
У результаті програмної реалізації було створено стабільний і масштабований
веб-застосунок, що відповідає сучасним вимогам до інтерактивних інформаційних
систем, працює у режимі реального часу, має чітко визначену архітектуру та легко
піддається подальшому розширенню. Завершення цього етапу підтверджує
готовність програмного продукту до розгортання та практичного застосування.
62
ВИСНОВКИ
У ході виконання кваліфікаційної роботи бакалавра було розроблено
повноцінний веб-застосунок для обміну повідомленнями, заснований на сучасній
клієнт-серверній архітектурі. Цей застосунок реалізує базову, але функціонально
завершену модель комунікаційного середовища, що дозволяє користувачам
здійснювати авторизований вхід, переглядати наявні чати, створювати нові розмови,
надсилати та отримувати повідомлення в режимі реального часу. Така система є
універсальною і придатною для використання як у приватному спілкуванні, так і в
корпоративному середовищі.
Результати виконаної роботи свідчать про досягнення поставленої мети –
створення стабільного, адаптивного та функціонального інструменту обміну
повідомленнями, який відповідає сучасним вимогам до веб-застосунків.
Реалізований застосунок демонструє коректну інтеграцію між клієнтською
частиною, розробленою на основі Next.js, та хмарною серверною частиною, що
побудована на платформі Firebase. Такий підхід забезпечив мінімізацію витрат на
інфраструктуру, спростив підтримку й масштабування, а також дозволив
сфокусувати увагу на логіці застосунку та зручності користувача.
Ключовою перевагою розробленого застосунку є підтримка обміну
повідомленнями в реальному часі. Завдяки використанню Firebase Firestore із
механізмами підписки на зміни (onSnapshot), забезпечено автоматичне оновлення
вмісту інтерфейсу без перезавантаження сторінки. Це дозволяє користувачам
отримувати нові повідомлення миттєво, що створює природне відчуття «живого»
спілкування, характерного для сучасних месенджерів.
Не менш важливим досягненням є реалізація авторизації користувачів через
інтеграцію з Google. Це не лише спрощує процес входу до системи, а й дозволяє
обмежити доступ до даних і розмежувати права користувачів. Впровадження
Firebase Authentication гарантує збереження конфіденційності та контрольованість
дій у межах додатку, що є необхідною умовою для будь-якої безпечної веб-
платформи.
63
Важливе значення в розробці мало проєктування та реалізація
користувацького інтерфейсу. Всі елементи інтерфейсу були створені відповідно до
сучасних вимог до UI/UX-дизайну: інтерфейс є інтуїтивно зрозумілим, адаптивним,
структурованим і візуально легким. Забезпечено підтримку роботи на пристроях із
різними розмірами екранів, зокрема на мобільних, що значно розширює потенційне
коло користувачів. Візуальні елементи виконані з дотриманням принципів
контрастності, гнучкості сітки, логічного групування та мінімалізму, що створює
приємне середовище для щоденного використання.
У процесі реалізації застосунку було зосереджено увагу на модульності та
повторному використанні коду. Компоненти побудовані за принципами
функціонального розділення, що спрощує обслуговування, тестування та подальший
розвиток. Така структура дозволяє легко вносити зміни до окремих частин проєкту,
не зачіпаючи всю систему в цілому, що є важливою перевагою в умовах динамічних
змін вимог або оновлень інфраструктури.
Також особливу увагу приділено перевірці працездатності та якості
розробленого рішення. Було проведено як ручне, так і автоматизоване тестування
логіки програми. Написані модульні тести перевірили роботу окремих
функціональних блоків, зокрема обробку авторизації, надсилання повідомлень,
взаємодію з базою даних і відображення інтерфейсу. Результати тестування
підтвердили стабільну роботу основних функцій, коректну обробку виняткових
ситуацій, а також стійкість системи до навантаження та некоректних дій
користувачів.
Розроблений застосунок має чітко окреслену архітектуру та потенціал до
масштабування. Його функціональність може бути розширена за рахунок підтримки
групових чатів, передачі файлів, реалізації push-сповіщень, використання хмарних
функцій Firebase для додаткової серверної логіки, інтеграції з іншими сервісами,
такими як Telegram або Slack, а також впровадження адміністративної панелі для
керування користувачами та повідомленнями. Відкрита структура рішення дозволяє
гнучко адаптувати систему під нові вимоги, цілі або сфери застосування.
64
Загалом, виконання даної кваліфікаційної роботи бакалавра дозволило на
практиці засвоїти основи побудови повноцінного веб-застосунку реалізувати
принципи клієнт-серверної взаємодії, поглибити знання з розробки інтерфейсів,
роботи з хмарними сервісами та організації обміну даними в реальному часі.
Отриманий результат може бути використаний як навчальний приклад, основа для
стартап-проєкту або база для впровадження більш складних функцій у сфері веб-
комунікацій.
Таким чином, розробка і впровадження веб-застосунку для обміну
повідомленнями засвідчує здатність автора самостійно аналізувати, проєктувати,
реалізовувати та перевіряти сучасні веб-системи, що відповідають актуальним
стандартам галузі.
65
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Веб-ресурс «Slack». URL: https://slack.com/ (дата звернення: 18.04.2025).
2. Веб-додаток «Discord». URL: https://discord.com/ (дата звернення: 18.04.2025).
3. Веб-додаток «Telegram Web». URL: https://web.telegram.org/ (дата звернення:
18.04.2025).
4. «Visual Studio Code». URL: https://code.visualtudio.com/ (дата звернення:
21.04.2025).
5. «Client-server model». URL: https://en.wikipedia.org/wiki/Client–server_model
(дата звернення: 21.04.2025).
6. «React». URL: https://en.wikipedia.org/wiki/React_(software) (дата звернення:
29.04.2025).
7. "Use case diagram". URL: https://en.wikipedia.org/wiki/Use_case_diagram (дата
звернення: 01.05.2025).
8. "Firebase Cloud Firestore". URL: https://firebase.google.com/docs/firestore (дата
звернення: 04.05.2025).
9. "ERD". URL: https://en.wikipedia.org/wiki/Entity–relationship_model (дата
звернення: 04.05.2025).
10. "Class Diagram". URL: https://en.wikipedia.org/wiki/Class_diagram (дата
звернення: 10.05.2025).
11. "CSS". URL: https://en.wikipedia.org/wiki/CSS (дата звернення: 15.05.2025).
12. "Next.js". URL: https://nextjs.org/ (дата звернення: 19.05.2025).
13. "Unit Testing". URL: https://en.wikipedia.org/wiki/Unit_testing (дата звернення:
23.05.2025).
66
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2025 р.
ВЕБ-ЗАСТОСУНОК ДЛЯ ОБМІНУ ПОВІДОМЛЕННЯМИ З
ВИКОРИСТАННЯМ КЛІЄНТ-СЕРВЕРНОЇ АРХІТЕКТУРИ
Специфікація
482.ЧДТУ. 52115-01
Листів 2
Розробник ____________________ Танцюра А.С.
Керівник ____________________ Оксамитна Л.П.
Черкаси – 2025
67
482.ЧДТУ. 52115-01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 52115-01 12 01 Текст програми
482.ЧДТУ. 52115-01 34 01 Інструкція користувача
482.ЧДТУ. 52115-01 90 01 Структура бази даних
68
ДОДАТОК Б
ВЕБ-ЗАСТОСУНОК ДЛЯ ОБМІНУ ПОВІДОМЛЕННЯМИ З
ВИКОРИСТАННЯМ КЛІЄНТ-СЕРВЕРНОЇ АРХІТЕКТУРИ
Текст програми
482.ЧДТУ. 52115-01 12 01
Листів 10
Розробник _____________ Танцюра А.С.
Черкаси – 2025
69
Bottombar.js
import { useState } from "react";
import { FormControl, Input, Button } from "@chakra-ui/react";
import { serverTimestamp, addDoc, collection } from "firebase/firestore";
import { db } from "../firebaseconfig";
export default function Bottombar({id, user}) {
const [input, setInput] = useState("");
const sendMessage = async (e) => {
e.preventDefault();
await addDoc(collection(db, `chats/${id}/messages`), {
text: input,
sender: user.email,
timestamp: serverTimestamp()
})
setInput("");
}
return (
<FormControl
p={3}
onSubmit={sendMessage}
as="form"
>
<Input placeholder="Type a message..." autoComplete="off" onChange={e =>
setInput(e.target.value)} value={input} />
<Button type="submit" hidden>Submit</Button>
</FormControl>
)
}
Login.js
import Head from "next/head";
import { ChatIcon } from "@chakra-ui/icons";
import { Box, Button, Center, Stack } from "@chakra-ui/react";
import { useSignInWithGoogle } from "react-firebase-hooks/auth";
import { auth } from "../firebaseconfig";
70
export default function Login() {
const [signInWithGoogle, user, loading, error] = useSignInWithGoogle(auth);
return (
<>
<Head>
<title>Login</title>
</Head>
<Center h="100vh">
<Stack
align="center"
bgColor="gray.600"
p={16}
rounded="3xl"
spacing={12}
boxShadow="lg"
>
<Box
bgColor="blue.500"
w="fit-content"
p={5}
rounded="3xl"
boxShadow="md"
>
<ChatIcon w="100px" h="100px" color="white" />
</Box>
<Button boxShadow="md" onClick={() => signInWithGoogle("", {prompt:
"select_account"})}>Sign In with Google</Button>
</Stack>
71
</Center>
</>
)
}
Sidebarjs
import { Avatar } from "@chakra-ui/avatar";
import { Button } from "@chakra-ui/react";
import { IconButton } from "@chakra-ui/button";
import { Flex, Text } from "@chakra-ui/layout";
import { ArrowLeftIcon } from "@chakra-ui/icons";
import { signOut } from "firebase/auth";
import { auth } from "../firebaseconfig";
import { useAuthState } from 'react-firebase-hooks/auth';
import { useCollection } from 'react-firebase-hooks/firestore';
import { collection, addDoc } from "@firebase/firestore";
import { db } from "../firebaseconfig";
import getOtherEmail from "../utils/getOtherEmail";
import { useRouter } from "next/router";
export default function Sidebar() {
const [user] = useAuthState(auth);
const [snapshot, loading, error] = useCollection(collection(db, "chats"));
const chats = snapshot?.docs.map(doc => ({id: doc.id, ...doc.data()}));
const router = useRouter();
const redirect = (id) => {
router.push(`/chat/${id}`);
}
const chatExists = email => chats?.find(chat => (chat.users.includes(user.email)
&& chat.users.includes(email)))
const newChat = async () => {
const input = prompt("Enter email of chat recipient");
if (!chatExists(input) && (input != user.email)) {
await addDoc(collection(db, "chats"), { users: [user.email, input] })
72
}
}
const chatList = () => {
return (
chats?.filter(chat => chat.users.includes(user.email))
.map(
chat =>
<Flex key={Math.random()} p={3} align="center" _hover={{bg: "gray.100",
cursor: "pointer"}} onClick={() => redirect(chat.id)}>
<Avatar src="" marginEnd={3} />
<Text>{getOtherEmail(chat.users, user)}</Text>
</Flex>
)
)
}
return (
<Flex
// bg="blue.100"
h="100%"
w="300px"
borderEnd="1px solid" borderColor="gray.200"
direction="column"
>
<Flex
// bg="red.100"
h="81px" w="100%"
align="center" justifyContent="space-between"
borderBottom="1px solid" borderColor="gray.200"
p={3}
>
<Flex align="center">
<Avatar src={user.photoURL} marginEnd={3} />
<Text>{user.displayName}</Text>
73
</Flex>
<IconButton size="sm" isRound icon={<ArrowLeftIcon />} onClick={() =>
signOut(auth)} />
</Flex>
<Button m={5} p={4} onClick={() => newChat()}>New Chat</Button>
<Flex overflowX="scroll" direction="column" sx={{scrollbarWidth: "none"}}
flex={1} >
{chatList()}
</Flex>
</Flex>
)
}
Topbar.js
import { Flex, Heading, Avatar } from "@chakra-ui/react"
export default function Topbar({email}) {
return (
<Flex
bg="gray.100"
h="81px" w="100%"
align="center"
p={5}
>
<Avatar src="" marginEnd={3} />
<Heading size="lg">{email}</Heading>
</Flex>
)
}
[id].js
import { Flex, Text } from "@chakra-ui/layout"
import Sidebar from "../../components/Sidebar"
74
import Head from "next/head"
import { useRouter } from "next/router"
import { useCollectionData, useDocumentData } from 'react-firebase-hooks/firestore';
import { useAuthState } from 'react-firebase-hooks/auth';
import { collection, doc, orderBy, query } from "firebase/firestore"
import { db, auth } from "../../firebaseconfig"
import getOtherEmail from "../../utils/getOtherEmail"
import Topbar from "../../components/Topbar"
import Bottombar from "../../components/Bottombar"
import { useRef, useEffect } from "react";
export default function Chat() {
const router = useRouter();
const { id } = router.query;
const [user] = useAuthState(auth);
const [chat] = useDocumentData(doc(db, "chats", id));
const q = query(collection(db, `chats/${id}/messages`), orderBy("timestamp"));
const [messages] = useCollectionData(q);
const bottomOfChat = useRef();
const getMessages = () =>
messages?.map(msg => {
const sender = msg.sender === user.email;
return (
<Flex key={Math.random()} alignSelf={sender ? "flex-start" : "flex-end"}
bg={sender ? "blue.100" : "green.100"} w="fit-content" minWidth="100px"
borderRadius="lg" p={3} m={1}>
<Text>{msg.text}</Text>
</Flex>
)
})
useEffect(() =>
setTimeout(
bottomOfChat.current.scrollIntoView({
behavior: "smooth",
block: 'start',
75
}), 100)
, [messages])
return (
<Flex
h="100vh"
>
<Head><title>Chat App</title></Head>
<Sidebar />
<Flex flex={1} direction="column">
<Topbar email={getOtherEmail(chat?.users, user)} />
<Flex flex={1} direction="column" pt={4} mx={5} overflowX="scroll"
sx={{scrollbarWidth: "none"}}>
{getMessages()}
<div ref={bottomOfChat}></div>
</Flex>
<Bottombar id={id} user={user} />
</Flex>
</Flex>
)
}
Home.module.css
.container {
padding: 0 2rem;
}
.main {
min-height: 100vh;
padding: 4rem 0;
flex: 1;
display: flex;
76
flex-direction: column;
justify-content: center;
align-items: center;
}
.footer {
display: flex;
flex: 1;
padding: 2rem 0;
border-top: 1px solid #eaeaea;
justify-content: center;
align-items: center;
}
.footer a {
display: flex;
justify-content: center;
align-items: center;
flex-grow: 1;
}
.title a {
color: #0070f3;
text-decoration: none;
}
.title a:hover,
.title a:focus,
.title a:active {
text-decoration: underline;
}
.title {
margin: 0;
line-height: 1.15;
font-size: 4rem;
}
77
.title,
.description {
text-align: center;
}
.description {
margin: 4rem 0;
line-height: 1.5;
font-size: 1.5rem;
}
.code {
background: #fafafa;
border-radius: 5px;
padding: 0.75rem;
font-size: 1.1rem;
font-family: Menlo, Monaco, Lucida Console, Liberation Mono, DejaVu Sans Mono,
Bitstream Vera Sans Mono, Courier New, monospace;
}
.grid {
display: flex;
align-items: center;
justify-content: center;
flex-wrap: wrap;
max-width: 800px;
}
.card {
margin: 1rem;
padding: 1.5rem;
text-align: left;
color: inherit;
text-decoration: none;
border: 1px solid #eaeaea;
border-radius: 10px;
78
transition: color 0.15s ease, border-color 0.15s ease;
max-width: 300px;
}
.card:hover,
.card:focus,
.card:active {
color: #0070f3;
border-color: #0070f3;
}
.card h2 {
margin: 0 0 1rem 0;
font-size: 1.5rem;
}
.card p {
margin: 0;
font-size: 1.25rem;
line-height: 1.5;
}
.logo {
height: 1em;
margin-left: 0.5rem;
}
@media (max-width: 600px) {
.grid {
width: 100%;
flex-direction: column;
}
}
79
ДОДАТОК В
ВЕБ-ЗАСТОСУНОК ДЛЯ ОБМІНУ ПОВІДОМЛЕННЯМИ З
ВИКОРИСТАННЯМ КЛІЄНТ-СЕРВЕРНОЇ АРХІТЕКТУРИ
ІНСТРУКЦІЯ КОРИСТУВАЧА
482. ЧДТУ. 52115-01 34 01
Листів 3
Розробник _____________ Танцюра А.С.
Черкаси – 2025
80
Після відкриття веб-застосунку на екрані відображено вікно входу, що містить
логотип сервісу та кнопку авторизації за допомогою Google-акаунта, як на рис. В.1.
Користувач має змогу розпочати роботу з додатком, натиснувши на кнопку «Sign In
with Google», після чого система перенаправляє його до стандартної форми входу
Google. У разі успішної автентифікації відбувається автоматичне повернення до
інтерфейсу застосунку з наданим доступом до функціоналу.
Рисунок В.1 – Сторінка авторизації
Після входу користувач бачить головну сторінку чату (рис. В.2), що поділена
на кілька логічних зон. На лівій панелі відображено список доступних чатів, у яких
бере участь користувач, а також розташовано кнопку створення нового чату.
Центральну частину займає вікно активного діалогу, в якому виводяться всі
повідомлення, відсортовані за часом. У нижній частині сторінки розташовано
текстове поле для введення повідомлень та елемент для їх надсилання. Інтерфейс
оформлено у світлих кольорах, повідомлення вхідного та вихідного типу візуально
розрізняються за кольоровою гамою та вирівнюванням на екрані.
81
Рисунок В.2 – Головна сторінка веб-застосунку з відкритою перепискою
Користувач має змогу створити нову розмову з іншим учасником, натиснувши
на кнопку «New Chat», яка розташована на лівій панелі інтерфейсу. Після цього
з’являється модальне вікно (рис. В.3), в якому необхідно ввести електронну пошту
користувача, з яким планується спілкування. Після підтвердження адресата чат
автоматично створюється та з’являється у списку доступних діалогів.
Рисунок В.3 – Модальне вікно створення нової переписки
У межах активного чату користувач має змогу ввести повідомлення у
відповідному текстовому полі в нижній частині екрана. Повідомлення зберігається
у хмарній базі даних та миттєво з’являється на екрані як у відправника, так і в
82
отримувача. Система підтримує обмін повідомленнями в реальному часі, що
дозволяє забезпечити плавне спілкування без потреби перезавантаження сторінки
або ручного оновлення.
У разі необхідності вийти з системи користувач має змогу скористатися
кнопкою виходу, що розташована у верхній частині бокового меню, поряд з
аватаром або ім’ям користувача. Після виходу застосунок повертає користувача на
стартовий екран з формою авторизації.
Інтерфейс додатку автоматично адаптується під розміри екрана, завдяки чому
користувач має змогу працювати як з комп’ютера, так і з мобільного пристрою без
втрати зручності. Всі функції додатку залишаються доступними незалежно від типу
пристрою.
Система автоматично зберігає історію повідомлень, тож при повторному вході
користувач має змогу побачити попередні повідомлення, надіслані в межах кожного
чату. Крім того, при втраті з’єднання з мережею інтерфейс продовжує працювати у
режимі очікування, і повідомлення буде надіслано після відновлення доступу до
Інтернету.
Робота з додатком не вимагає попередньої підготовки або спеціальних знань.
Інтерфейс є інтуїтивно зрозумілим, візуально легким і забезпечує комфортне
користування всіма основними функціями обміну повідомленнями.
83
ДОДАТОК Г
ВЕБ-ЗАСТОСУНОК ДЛЯ ОБМІНУ ПОВІДОМЛЕННЯМИ З
ВИКОРИСТАННЯМ КЛІЄНТ-СЕРВЕРНОЇ АРХІТЕКТУРИ
Структура бази даних
482. ЧДТУ. 52115-01 90 01
Листів 2
Розробник _____________ Танцюра А.С.
Черкаси – 2025
84
У межах реалізованого веб-застосунку для обміну повідомленнями
структура бази даних побудована на хмарній NoSQL-платформі Firebase Firestore.
Організація даних відповідає документно-орієнтованій моделі, де дані зберігаються
у вигляді колекцій, документів і вкладених підколекцій. Такий підхід дозволяє
забезпечити масштабованість, високу швидкодію та зручність доступу до інформації
в режимі реального часу.
Основу структури становлять дві основні колекції: users та chats. Кожна з
них містить відповідні документи та підколекції.
Кожен документ у колекції users відповідає одному авторизованому
користувачу додатку. Ідентифікатором документа є унікальний UID, який надається
системою автентифікації Firebase.
Структура документа:
− uid – унікальний ідентифікатор користувача (string);
− email – електронна пошта користувача (string);
− photoURL – посилання на аватар користувача (string);
− displayName – ім’я користувача (string, необов’язкове).
Колекція chats містить усі чати, створені користувачами. Кожен документ у
цій колекції відповідає окремому чату (приватному або груповому).
Структура документа:
− chatId – унікальний ідентифікатор чату (автоматично створюється
Firestore);
− users – масив email-адрес користувачів, що беруть участь у чаті (array of
strings);
− createdAt – дата створення чату (timestamp).
Кожен документ підколекції messages зберігає одне повідомлення, що
надійшло у відповідний чат.
Структура документа messages:
− text – текст повідомлення (string);
85
− sender – email відправника (string);
− timestamp – мітка часу відправлення (timestamp).
Повідомлення у підколекції впорядковуються за допомогою поля timestamp,
що дозволяє відображати діалог у хронологічному порядку. Оновлення цієї
підколекції в режимі реального часу забезпечується через метод onSnapshot().
Рисунок Г.1 – Структура бази даних у вигляді діаграми «Сутність-Зв’язок»