Ключові висновки

Архітектура - це компроміс, а не медаль. Немає «найкращого» стеку на всі випадки. Є набір trade-off'ів: швидкість розробки vs масштабованість, простота деплою vs незалежність команд, багатий UX vs SEO і перше завантаження.

Технології циклічні. Серверний рендеринг → AJAX → SPA → знову SSR. Моноліт → мікросервіси → modular monolith. Кожен виток спіралі зберігає уроки попереднього покоління.

Копіювати Big Tech небезпечно без їхнього контексту. Netflix розрізав моноліт, коли в нього були сотні інженерів і власна хмарна платформа. Стартап із трьома розробниками отримає розподілений моноліт: усі мінуси складності без виграшу в масштабуванні.

Спостережуваність і дані - частина архітектури з 2010-х. Логів у stdout недостатньо для систем із двадцяти сервісів. Метрики, трейси й поліглотне зберігання - не «інфраструктурна розкіш», а умова супроводжуваності.

ШІ у 2020-х додає новий шар. Векторні бази, RAG, оркестрація викликів LLM - це не «ще одне API», а окрема архітектурна вісь поруч із класичним бекендом.

---

Вступ: чому архітектура ніколи не стоїть на місці

Вебзастосунок - це завжди угода між трьома силами: чого хоче користувач (швидко, зручно, надійно), що можуть залізо й мережа (латентність, пропускна здатність, батарея телефона) і що може команда (кількість людей, досвід, бюджет на інфраструктуру). Коли будь-яка з цих сил зсувається, архітектуру переглядають.

Зростання аудиторії тисне на горизонтальне масштабування й кешування. Прискорення інтернету та поява 4G/5G дали змогу переносити логіку в браузер - звідси SPA і важкі фронтенди. Потужні смартфони зробили можливим JavaScript, який раніше «гальмував» на кожному кліку. Хмари знизили ціну експериментів із розподіленими системами й одночасно підняли ціну помилок в експлуатації.

Важливо відокремлювати застаріле від помилкового. CGI-скрипти на Perl у 2003 році були розумним вибором: простий деплой, зрозуміла модель, мінімум залежностей. Те, що сьогодні для нового проєкту ви обрали б FastAPI або Rails, не робить Perl «поганим» - він розв'язував задачі своєї епохи в межах тодішніх обмежень.

---

Глава 1. Веб початку 2000-х: епоха серверного рендерингу

Який вигляд мав типовий сайт у 2005 році

Типовий сценарій був лінійним: браузер надсилає HTTP-запит → вебсервер (Apache, IIS, nginx у зародковому стані) передає його застосунку → застосунок читає дані з MySQL або PostgreSQL → шаблонізатор збирає HTML → сервер віддає готову сторінку. JavaScript на сторінці, якщо й був, обмежувався валідацією форм, простими ефектами та лічильниками. Будь-яка дія - зміна фільтра, додавання в кошик, надсилання коментаря - найчастіше означала повне перезавантаження документа.

Для користувача це означало помітні паузи й «блимання» білого екрана. Для розробника - передбачуваність: уся логіка на сервері, стан у сесії або cookie, налагодження через логи на одній машині.

Популярні технології

Спільна риса: мова на сервері генерує HTML. Клієнт - тонкий термінал для відображення.

Типова архітектура

[Браузер] → [Веб-сервер] → [Монолітний застосунок] → [Шаблонізатор] → HTML
                                     ↓
                              [База даних]

Три шари, один процес (або кластер однакових процесів за балансувальником). Деплой - залити файли по FTP або перезапустити один WAR-файл. Жодних окремих «фронтенд-збірок», API-контрактів між командами, оркестраторів контейнерів.

Плюси й мінуси

Плюси: низький поріг входу; один репозиторій і один деплой; SEO «з коробки» - пошуковик бачить готовий HTML; відносно просте налагодження й моніторинг.

Мінуси: кожен клік - round-trip на сервер; складно будувати багатий інтерактивний UI; сервер витрачає CPU на рендеринг сторінок на кожен запит; горизонтальне масштабування впирається в сесії й спільну БД.

Ця модель не зникла. Вона еволюціонувала - у фреймворки з MVC, у SSR-фреймворки нового покоління, у HTMX-підхід «HTML із сервера, мінімум JS». Але у 2005 році вона була єдиною масовою відповіддю на запитання «як зробити сайт із даними».

---

Глава 2. Поява AJAX і народження Web 2.0

Що змінилося

У середині 2000-х сторінки перестали повністю перезавантажуватися при кожній дії. Браузер почав запитувати лише дані - JSON, XML або фрагмент HTML - і оновлювати частину DOM. Користувач отримав відчуття «застосунку всередині браузера» без встановлення клієнта.

Революція AJAX

AJAX (Asynchronous JavaScript and XML) спирався на XMLHttpRequest - API, що з'явилося ще в Internet Explorer 5, але стало масовим після стандартизації та прикладів від Google. Асинхронний запит не блокував UI; відповідь оброблялася callback'ом і локально змінювала інтерфейс.

Ключовий зсув: сервер віддає дані, клієнт вирішує, як їх показати. Межа відповідальності змістилася.

Проєкти, які змінили індустрію

• Gmail (2004) - пошта без перезавантаження вкладки; довів, що веб може конкурувати з десктопом.
• Google Maps (2005) - панорамування й зум без round-trip; показав цінність плавного UI.
• Facebook - стрічка, лайки, сповіщення в реальному часі; масштабував патерн на сотні мільйонів користувачів.

Ці продукти не «винайшли JavaScript» - вони показали бізнес-цінність багатого клієнта. Конкуренти змушені були копіювати UX.

Нові проблеми й наслідки

Логіка розділилася між сервером і браузером без чітких контрактів. Дублювання валідації: на клієнті «для зручності», на сервері «для безпеки». JavaScript на сторінках виріс із кілобайтів до мегабайтів. З'явилися перші «спагеті» з callback hell.

Наслідок для архітектури: почалося багаторічне перенесення стану й поведінки в клієнт. За десять років це приведе до SPA; у 2007 році - до перших REST-подібних ендпоінтів «для фронтенду».

---

Глава 3. Епоха MVC-фреймворків

Чому з'явилися MVC-фреймворки

Зі зростанням AJAX-застосунків і кількості сторінок монолітні скрипти «все в одному файлі» перестали масштабуватися організаційно. Потрібні були домовленості: де живе бізнес-логіка, де представлення, де обробка запитів. MVC (Model-View-Controller) дало спільний словник.

Популярні рішення

• Ruby on Rails (2004) - «convention over configuration», Active Record, генератори; пришвидшив стартапи.
• Symfony, CodeIgniter, Yii, Laravel - екосистема PHP зі зрілими ORM та екосистемою пакетів.
• ASP.NET MVC - відповідь Microsoft на Rails для .NET-світу.
• Django, Spring MVC - Python і Java з тим самим поділом.

Концепція MVC

• Model - дані й бізнес-правила (часто через ORM).
• View - шаблон того, що побачить користувач.
• Controller - приймає HTTP-запит, викликає модель, обирає view.

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

Що дала MVC-архітектура

Чистіший код, повторне використання partial-шаблонів і layout'ів, пришвидшення розробки CRUD-застосунків. З'явилися домовленості про деплой: міграції БД, оточення, asset pipeline.

Обмеження

Товсті контролери - уся логіка осіла в шарі, який мав лише маршрутизувати. Товсті моделі - Active Record змішує персистентність і домен. Моноліти росли: один репозиторій, десятки модулів, спільна база. MVC упорядкувала код усередині моноліту, але не розв'язала проблему масштабування команд - звідси шлях до сервісів і мікросервісів.

---

Глава 4. JavaScript стає повноцінною мовою фронтенду

Зростання можливостей браузерів

Рушій V8 (Chrome, 2008) і змагання браузерів за швидкість JIT-компіляції зробили JavaScript придатним для тисяч рядків логіки, а не лише для скриптів на 50 рядків. З'явилися ES5, модулі, Canvas, Web Workers. JavaScript перестав бути «мовою для кнопочок».

Перші фронтенд-фреймворки

jQuery не вбивав серверний рендеринг - він оживляв сторінки поверх нього. Backbone і Ember уже передбачали, що клієнт володіє станом.

Проблема: інтерфейс складніший за сервер

На складних екранах (дашборди, редактори, багатокрокові форми) код представлення випередив серверний за обсягом і складністю. Команди почали наймати «фронтенд-розробників» як окрему роль. Збірка (Browserify, пізніше Webpack) стала обов'язковою.

Поява SPA

Single Page Application - одна HTML-оболонка, далі навігація й дані через JavaScript та API. URL змінюється через History API; контент підвантажується без повного перезавантаження. UX наближається до нативних застосунків; ціна - важкий перший завантажувальний бандл і складність SEO без додаткових хитрощів.

---

Глава 5. Революція Angular, React і Vue

Чому SPA захопили ринок

Після смартфонів і App Store користувачі очікували миттєвої реакції інтерфейсу. SPA давали плавні переходи, оптимістичні оновлення, офлайн-кеш (Service Workers пізніше). Для B2B-дашбордів і SaaS це стало стандартом якості.

Три стовпи

Angular (2010, перезапуск 2016) - повний фреймворк: маршрутизація, DI, форми, HTTP-клієнт. TypeScript за замовчуванням. Підхід «усе включено» зручний ентерпрайзу з довгими циклами планування.

React (2013) - бібліотека UI з компонентною моделлю й Virtual DOM. Не нав'язує маршрутизацію та стан - екосистему (Redux, React Router) обирають окремо. Повторно використовувані компоненти змінили дизайн-системи.

Vue (2014) - низький поріг входу, реактивність «з коробки», поступове впровадження в legacy-сторінки. Швидко виріс у Китаї та Європі.

Як змінилася архітектура

Бекенд став API. Сервер рідше віддає HTML - частіше JSON по REST. Фронтенд став окремим застосунком зі своїм репозиторієм, CI, деплоєм на CDN або статичний хостинг. Контракт між командами - OpenAPI-документ (пізніше) або усна домовленість (часто й болісно).

З'явився типовий стек 2015-2020: React + Node.js (BFF або повноцінний API) + PostgreSQL + Redis + Docker. Поділ дав змогу наймати спеціалістів; ускладнив версіонування API й узгодження релізів.

---

Глава 6. Народження API-first архітектури

Що таке API-first

Спочатку контракт, потім реалізація. Команди описують ендпоінти, схеми запитів і відповідей, коди помилок - до написання коду. Клієнти (веб, iOS, Android, партнери) можуть працювати паралельно з бекендом за mock-серверами.

REST як стандарт

REST (Representational State Transfer) закріпив звичні патерни:

• Ресурси - /users/42, /orders/99/items
• HTTP-методи - GET читає, POST створює, PUT/PATCH оновлює, DELETE видаляє
• JSON - легкий формат для JavaScript-клієнтів

Простота пояснення й налагодження через curl зробила REST домінуючим стилем публічних API.

Плюси

Незалежність команд і клієнтів; один бекенд для вебу й мобільних застосунків; простіші інтеграції з партнерами та webhook'ами.

Мінуси

Версіонування - /v1/ vs заголовки vs зламні зміни в тому самому URL. Надлишкові запити - екран профілю тягне п'ять GET для пов'язаних сутностей (проблема, яку пізніше атакував GraphQL). Overfetching - клієнт отримує поля, які не показує.

API-first залишається здоровим принципом; суперечка йде про форму API (REST, GraphQL, gRPC, tRPC для full-stack TypeScript).

---

Глава 7. Поява мікросервісів

Чому відійшли від монолітів

Коли в моноліті працюють п'ятдесят команд, кожен деплой - лотерея: чужий модуль ламає ваш. Спільна база даних стає вузьким місцем і полем конфліктів міграцій. Горизонтальне масштабування «усього застосунку» дорожче, ніж масштабування лише сервісу звітів або пошуку.

Що таке мікросервіс

Невеликий самостійний сервіс із власною базою даних (в ідеалі), власним деплоєм і чіткою зоною відповідальності. Спілкується мережею - HTTP, gRPC, черги повідомлень.

Хто популяризував

Публічні історії Netflix, Amazon («two-pizza teams»), Google (внутрішня інфраструктура на роки раніше за ринок) створили наратив: успіх гігантів пов'язаний із мікросервісами. Менш публічно обговорювали вартість - сотні інженерів платформи, культура blameless postmortem, зрілий моніторинг.

Типова мікросервісна архітектура

[Клієнти] → [API Gateway] → [Сервіс A] [Сервіс B] [Сервіс C]
                 ↓                    ↓         ↓
            [Auth]              [БД A]   [Черга] → [Сервіс D]

Gateway - єдина точка входу, TLS, rate limiting, маршрутизація. Черги (RabbitMQ, Kafka) - асинхронні задачі й слабка зв'язність.

Переваги й недоліки

Плюси: незалежний деплой; масштабування окремих сервісів; технологічна різноманітність (Python для ML, Go для воркерів).

Мінуси: розподілені транзакції й узгодженість; мережеві збої та каскадні відмови; складність локальної розробки («підніми 15 контейнерів»); потрібна спостережуваність рівня, якого моноліт не вимагав.

Мікросервіси - інструмент організаційного масштабу, а не технічний апгрейд за замовчуванням. Детальніше про пастки зростання складності - у статті чому ERP перетворюються на моноліти.

---

Глава 8. Контейнеризація й Docker

Чому Docker змінив ринок

До Docker розробник казав: «У мене працює» - і все падало на проді через іншу версію libc, відсутнє розширення PHP або розбіжність шляхів. Віртуальні машини розв'язували ізоляцію, але були важкими: хвилини на старт, гігабайти на диск.

Що приніс Docker

Контейнер - ізольований процес із власною файловою системою з образу. Образ збирається з Dockerfile, версіонується в реєстрі (Docker Hub, ECR, GCR). Однаковий артефакт від ноутбука до production.

Вплив на архітектуру

Деплой пришвидшився: docker pull + перезапуск замість ручного налаштування сервера. Мікросервіси стали практичними - не «15 JVM на 15 VM», а «15 легких контейнерів на кількох хостах». З'явився шар оркестрації - без нього десятки контейнерів під ручним керуванням нежиттєздатні.

---

Глава 9. Kubernetes і хмарна революція

Чому Docker недостатньо

За сотень сервісів потрібні: автоматичний restart контейнерів, що впали, балансування трафіку, rolling update без даунтайму, secrets, ліміти CPU/RAM, service discovery - щоб payments-v2 знаходив users без hardcoded IP.

Що приніс Kubernetes

Декларативні маніфести: бажаний стан (3 репліки, образ app:1.2.3), кластер сам підтягує фактичний. HPA - автомасштабування за CPU або кастомними метриками. Self-healing - перевідтворення pod'ів на вузлах, що впали.

Нова реальність

Infrastructure as Code - Terraform, Pulumi; GitOps - Argo CD, Flux; термін Cloud Native - застосунки, спроєктовані під динамічне середовище, а не під «вічний сервер».

Ціна успіху

Різке зростання операційної складності. Команда з восьми розробників рідко потребує повного K8s-кластера; managed-платформи (ECS, Cloud Run, Fly.io, Railway) свідомо продають «менше Kubernetes в обличчя».

---

Глава 10. Serverless-підхід

Ідея

Взагалі не керувати серверами - завантажуєш функцію, платформа запускає її за подією (HTTP, черга, cron). Масштабування до нуля й до тисяч інстансів - задача хмари.

Платформи

AWS Lambda, Azure Functions, Google Cloud Functions; надбудови на кшталт Vercel Functions і Cloudflare Workers ближчі до edge.

Коли корисний

Нестабільне навантаження (раз на годину один запит vs пік у Чорну п'ятницю); подієві пайплайни (файл завантажено → обробка → сповіщення); швидкі прототипи API.

Обмеження serverless-підходу

Cold start - пауза при першому виклику після простою; критично для latency-sensitive API. Ліміти часу виконання й розміру пакета. Vendor lock-in - прив'язка до API та екосистеми однієї хмари. Налагодження й локальна емуляція складніші, ніж у контейнера.

Serverless - не заміна всьому бекенду, а спеціалізований шар для коротких stateless-задач.

---

Глава 11. Повернення серверного рендерингу

Чому SPA критикують

Типовий React-SPA під час першого візиту: порожній HTML → завантажити JS (сотні KB-MB) → виконати → запросити дані → відрендерити. Повільне перше завантаження б'є по LCP і конверсії в мобільних мережах. SEO без SSR/пререндеру проблематичне для контентних сайтів. Доступність і робота без JS страждають, якщо весь контент клієнтський.

Нове покоління фреймворків

• Next.js - SSR, SSG, ISR на React; де-факто стандарт для full-stack React.
• Nuxt - те саме для Vue.
• Remix - вебстандарти, вкладені маршрути, progressive enhancement.
• SvelteKit, Astro - менше JS на клієнті, острівна архітектура.

Підходи

Гібридна архітектура

Статичні сторінки - SSG; особистий кабінет - клієнтська інтерактивність; каталог - SSR із кешем CDN. Найкраще з двох світів - якщо команда готова до складності збірки й двох середовищ виконання (сервер + браузер).

---

Глава 12. Сучасні архітектурні стилі

Modular Monolith

Моноліт із жорсткими межами модулів усередині одного деплою. Модулі спілкуються через явні API, не лізуть у чужі таблиці. Простіший у супроводі, ніж розподілена система; дешевший, ніж мікросервіси для команди до ~20 людей. Модуль можна пізніше вирізати в сервіс, якщо межі вже доведені.

Знову популярний після хвилі «розрізали моноліт і пошкодували».

Мікросервіси - коли виправдані

Дуже великі продукти, десятки автономних команд, різні профілі навантаження підсистем, зріла платформа (K8s, observability, SRE). Без цього - розподілений моноліт із мережевою латентністю.

Event-Driven Architecture (EDA)

Сервіси публікують події («Замовлення створено»), підписники реагують асинхронно. Слабка зв'язність, масштабування споживачів, аудит через журнал подій.

Інструменти: Apache Kafka (висока пропускна здатність, зберігання), RabbitMQ (класичні черги), NATS (легкий, cloud-native).

CQRS

Command Query Responsibility Segregation - різні моделі для запису й читання. Запис іде в нормалізовану OLTP-базу; читання - з денормалізованих проєкцій або окремого сховища. Застосовують за екстремального навантаження на читання й складних звітів; ціна - складність синхронізації й затримка eventual consistency.

---

Глава 13. Архітектура фронтенду сьогодні

Component-Based Architecture

React, Vue, Angular, як і раніше, будують UI з повторно використовуваних компонентів з ізольованим станом і props. Відмінності - в екосистемі, моделі реактивності й корпоративних вимогах.

Design Systems

Єдині бібліотеки (Material, Ant Design, власні Storybook-кити) синхронізують візуальну мову й поведінку між продуктами. Архітектурний виграш - менше дублювання, швидше узгодження з дизайном.

Micro Frontends

Незалежні команди деплоять частини одного порталу (шапка - команда A, каталог - B). Module Federation, iframe, web components. Виправдано за організаційного поділу; дорого в інтеграції та продуктивності на старті.

BFF (Backend for Frontend)

Спеціалізований API під конкретний клієнт: мобільному BFF віддає агрегований екран одним запитом; веб-BFF - іншу форму. Знижує overfetching і приховує внутрішню мікросервісну кашу від тонкого клієнта.

---

Глава 14. Як змінювалися бази даних

Ера SQL

MySQL, PostgreSQL, Oracle - ACID, JOIN'и, строга схема. Десятиліттями одне джерело правди для моноліту. PostgreSQL у 2010-2020-х відкусив значну частку «універсальної» БД завдяки JSON, розширенням і надійності.

NoSQL-революція

Зростання навантажень Web 2.0 і небажання жити в жорсткій схемі за продукту, що швидко змінюється:

• MongoDB - документи, гнучка схема
• Cassandra - запис у ширину, відмовостійкість
• Redis - кеш, сесії, черги, структури даних у пам'яті

CAP-теорема й eventual consistency увійшли до обов'язкового словника архітектора.

NewSQL і поліглотна персистентність

CockroachDB, TiDB - розподілений SQL із горизонтальним масштабуванням. Polyglot Persistence - різні сховища під різні задачі: PostgreSQL для транзакцій, Elasticsearch для пошуку, Redis для кешу, S3 для файлів. Архітектура даних стала набором, а не одним вибором на весь проєкт.

---

Глава 15. Спостережуваність як частина архітектури

Чому логів недостатньо

У моноліті grep по одному файлу часто знаходив причину. У системі з двадцяти сервісів запит проходить через gateway, auth, три сервіси й чергу - без кореляції ви бачите двадцять не пов'язаних між собою stack trace.

Три стовпи Observability

1. Logs - дискретні події з контекстом (structured logging, JSON).
2. Metrics - агрегати в часі (RPS, latency p99, error rate).
3. Traces - шлях одного запиту через усі hop'и (trace id у заголовках).

Інструменти

Prometheus + Grafana - метрики й дашборди. OpenTelemetry - стандарт інструментування. Jaeger, Tempo - візуалізація трейсів. Без цього мікросервіси й serverless сліпі у продакшені.

Спостережуваність закладають під час проєктування - не «додамо після інциденту».

---

Глава 16. Штучний інтелект змінює архітектуру

Нові вимоги

Застосунки з LLM не зводяться до одного HTTP-виклику. Потрібні: керування промптами й версіями моделей, ліміти токенів і вартості, кеш ембеддингів, приватність даних, fallback за недоступності провайдера.

Нові компоненти

• Embeddings - векторне подання тексту для семантичного пошуку.
• Retrieval - вибір релевантних фрагментів із бази знань.
• RAG (Retrieval-Augmented Generation) - модель відповідає, спираючись на ваші документи, а не лише на навчання.

Типова схема AI-застосунку

[Клієнт] → [API / Orchestrator] → [LLM API]
                 ↓                        ↑
          [Vector DB] ← [Embeddings pipeline]
                 ↓
          [Document store / CRM / wiki]

Оркестратор вирішує: коли викликати інструмент, коли шукати у векторній БД, коли ескалювати людині. Векторні сховища (pgvector, Pinecone, Qdrant, Weaviate) стали таким самим архітектурним вибором, як Redis десять років тому.

---

Глава 17. Які ідеї виявилися помилковими - у контексті

Не «технології-провали», а недоречне застосування:

Мікросервіси для малих проєктів. Три розробники не отримують вигоди від незалежного деплою п'яти сервісів; натомість отримують операційне пекло.

Надмірна розподіленість. Синхронні ланцюжки із семи HTTP-викликів на один клік користувача; saga без компенсацій; «усе в Kafka» без споживачів.

Передчасна оптимізація. Шардінг БД за тисячі користувачів; multi-region до product-market fit.

Сліпе копіювання Big Tech. Ваш стартап не Netflix; їхні рішення оплачені їхнім масштабом болю.

Помилка не в ідеї мікросервісу або SPA, а в невідповідності ідеї розміру команди, бюджету й реальному навантаженню.

---

Глава 18. Що нас чекає в наступні 10 років

AI-assisted development - агенти генерують код та інфраструктуру; архітектор фокусується на межах модулів і обмеженнях, а не на бойлерплейті.

Edge computing - логіка ближче до користувача (Cloudflare Workers, Deno Deploy); менше round-trip, жорсткіші ліміти CPU.

WebAssembly - важкі обчислення й порти наявних бібліотек у браузері без повного перенесення логіки на сервер.

Локальні AI-моделі - приватність і офлайн; гібрид «мала модель на пристрої + велика в хмарі за потреби».

Агентні системи - ланцюжки автономних кроків з інструментами; нові вимоги до безпеки, аудиту й human-in-the-loop.

Self-healing applications - автоматичний rollback, canary на рівні платформи, remediation runbook'и від ШІ за типових інцидентів.

Прогнози розмиті; напрям зрозумілий: більше автоматизації рутини, більше гібридних моделей (edge + cloud, local LLM + API, SSR + islands), більше тиску на простоту там, де складність не окупається.

---

Висновок

Головний урок двадцяти років

Ідеальної архітектури не існує. Кожна - компроміс між швидкістю розробки, вартістю володіння, UX, надійністю та швидкістю змін бізнесу. Те, що сьогодні називають «legacy», учора було правильною відповіддю на вчорашні обмеження.

Як обирати архітектуру сьогодні

1. Розмір команди - моноліт або modular monolith для невеликої групи; мікросервіси за доведеного болю координації.
2. Бюджет - managed-сервіси vs власний K8s; вартість інцидентів vs вартість хмари.
3. Бізнес-задачі - контентний сайт, SaaS, маркетплейс, real-time - у кожного різний профіль навантаження й SEO.
4. Траєкторія зростання - закладайте межі модулів рано; різати на сервіси пізніше, коли межі зрозумілі.

Фінальна думка

Найстійкіші проєкти рідко будують на наймоднішій архітектурі. Вони будують на найпростішій архітектурі, яка розв'язує поточну задачу і не заважає еволюціонувати завтра. Історія вебу - не перегони за хайпом, а низка осмислених відповідей на змінні обмеження. Ваш наступний вибір стеку буде правильним, якщо ви чесно назвете ці обмеження ще до того, як відкриєте README чергового фреймворку.