Розгляд завершальних етапів розробки: збирання, тестування (CI/CD) та розгортання на хостингах (Vercel, AWS). Аналіз основних вразливостей (XSS), налаштування систем моніторингу помилок після релізу та розгляд архітектурних рішень (Мікрофронтенди) для масштабних корпоративних систем.
Доведення коду до стану git commit — це лише середина життєвого циклу програмного продукту. Для інженерів 4-го курсу критично важливо розуміти процес “доставки” цього коду до кінцевого мільйонного користувача так, щоб система не впала від навантаження, не була зламана хакерами та автоматично оновлювалась без втручання людини.
Ця фінальна лекція присвячена “дорослому” світу Frontend-архітектури (DevOps для Frontend), стандартам веб-безпеки OWASP та сучасним підходам до масштабування кодових баз, коли в одному репозиторії працюють сотні розробників одночасно.
Continuous Integration (CI): Безперервна інтеграція.
Це процес, який автоматизує злиття коду (Merge) від багатьох розробників у головну гілку main.
Замість того, щоб вірити розробнику “на слово”, що його код працює, підключається CI-сервер (наприклад, GitHub Actions, GitLab CI).
Continuous Deployment (CD): Безперервне розгортання. Процес автоматичної доставки перевіреного коду на публічні сервери, щоб його побачили користувачі.
Типовий Pipeline (Github Actions YAML файл):
push своєї гілки.npm ci замість npm i для точної фіксації версій).npm run lint (Перевірка на сміття у коді).npm run test (Якість логіки).npm run build (Чи компілюється TypeScript? Чи не падає Webpack/Vite?).main -> автоматично відправити файли збірки (/dist або /.next) на AWS або Vercel.Frontend-системи зараз деплояться двома принципово різними шляхами.
Лідери — Vercel, Netlify, Cloudflare Pages. Цей шлях створений спеціально для сучасних SSG/SSR фреймворків (Next.js, Remix). Ви просто даєте Vercel посилання на ваш GitHub репозиторій. Vercel сам відстежує коміти, сам запускає білд і миттєво роздає ваш сайт на 300+ серверів по всьому світу (CDN edge networks) так, що користувач в Японії і користувач в Україні отримують сайт з найближчого до них дата-центру за 50 мілісекунд.
Використовується корпораціями з високими вимогами до безпеки (Банки, Медицина), які не можуть віддавати свій код на публічний Vercel, або використовують класичні SPA додатки (без SSR).
Dockerfile. Це інструкція збірки.Dockerfile описано: “Візьми чистий Nginx (веб-сервер), поклади в папку /usr/share/nginx/html файли після npm run build і відкрий порт 80”.docker run.Світ фронтенду є публічним (будь-хто може натиснути F12 і прочитати ваш JS код). Тому головне правило архітектури: “Ніколи не довіряй клієнту”.
Головна вразливість клієнтських додатків — XSS (Cross-Site Scripting).
Це коли зловмисник вставляє (injects) шкідливий JavaScript замість тексту, наприклад, у форму коментарів: <img src="x" onerror="alert(document.cookie)">. Коли інші користувачі відкривають цей коментар, скрипт виконується у їхніх браузерах і краде їхні паролі чи сесії.
Як React захищає від XSS?
React “з коробки” має сильну броню: всі дані (Props та State), що генеруються у JSX-дужках {user.name}, автоматично проходять процес Екранування (Escaping). Тег <script> перетвориться у безпечний рядок <script> і просто відрендериться як текст, не виконавшись як код.
Коли React вразливий:
Проте є обхідний маневр (Escape Hatch). Властивість dangerouslySetInnerHTML. Її використовують для рендеру статей з баз даних формату WYSIWYG або Markdown.
// ❌ АРХІТЕКТУРНА ПОМИЛКА: XSS ВРАЗЛИВІСТЬ!
// Якщо в user.bio буде <script>...</script>, він виконається!
const UserProfile = () => {
return <div dangerouslySetInnerHTML=></div>;
};
// ✅ РІШЕННЯ: САНІТАРИЗАЦІЯ (Sanitization)
// Використовуємо бібліотеку DOMPurify перед рендером
import DOMPurify from "dompurify";
const SafeProfile = () => {
// Всі шкідливі теги (object, script, iframe) будуть вирізані, залишаться лише безпечні (p, b, i)
const cleanHtml = DOMPurify.sanitize(user.bio);
return <div dangerouslySetInnerHTML=></div>;
};
Після логіну сервер віддає клієнту Токен доступу (JWT). Клієнтський додаток має його десь зберігати, щоб відправляти з кожним наступним API-запитом.
Поширені помилки Junior-розробників:
localStorage або sessionStorage: Це найгірше рішення. До localStorage має доступ БУДЬ-ЯКИЙ JavaScript код на сторінці. При найменшій XSS-атаці зловмисник вкраде ВСІ токени доступу.Правильний Enterprise-шлях (BFF - Backend for Frontend):
Set-Cookie.HttpOnly, Secure та SameSite=Strict.HttpOnly забороняє браузеру (і будь-якому JavaScript коду, включаючи хакерський) звертатися до куки через document.cookie.Коли додаток (Моноліт) розростається до масштабів Netflix або AliExpress, збірка Webpack може тривати годину, а зміни команди “А” постійно ламають код команди “Б”.
Парадигма Мікросервісів для бекенду отримала свого брата у фронтенді — Мікрофронтенди. Це архітектура, де візуально єдиний сайт (Single Page Application) насправді є агрегацією кількох абсолютно незалежних міні-додатків, розроблених різними командами.
server1.com.server2.com.server1 і з server2, поєднуючи їх у єдиний DOM без необхідності загальної перекомпіляції!“В мене на локальному комп’ютері працює”, — ця фраза не має сенсу у Production, де у мільйонів клієнтів можуть бути старі браузери, AdBlock-розширення чи перебої з інтернетом.
Коли після релізу в додаток заходить клієнт, і в нього стається фатальний JavaScript Error, екран стає білим. Розробники ніколи про це не дізнаються, бо це сталося у браузері клієнта, а не на сервері.
Для вирішення цього використовують системи “Відстеження помилок” (Error Tracking), стандартом з яких є Sentry.io.
В корінь React-проєкту додається ErrorBoundary від Sentry. Якщо будь-який компонент викидає TypeError чи обривається Promise, Sentry “перехоплює” його і робить скріншот стек-трейсу, версію браузера клієнта, інформацію про його кліки перед помилкою і відправляє це JSON-звітом на сервер розробників у Telegram/Slack або Jira. Це дозволяє команді швидко писати Hotfixes ще до того, як клієнти залишать скарги у підтримці.
localStorage), передаючи відповідальність за керування сесіями у захищені HttpOnly Cookies.localStorage браузера порівняно з Cookie, яка має прапорець HttpOnly. Чим зловмисник може скористатися в першому випадку і що блокує його в другому?Sentry під час експлуатації продукту в Production-середовищі? Що вони можуть зафіксувати такого, чого не помітять тести?