Веб-стек для стартапів у епоху AI-агентів: Next.js, MUI та Firebase
Стартап-стек для веб-розробки в епоху кодувальних агентів: Next.js, MUI, Firebase, Vercel та PostHog, із мінімальною налаштуванням агента та поясненням вибору кожного інструменту.
Джерела: The Teach Stack for Building Full-Stack Apps in the AI-Agentic Era (2026 Edition)
Вибір технологій, коли код наполовину написаний машиною
Інструменти для програмування, такі як Claude Code та Codex, змінили спосіб створення програмного забезпечення. Ітерації відбуваються набагато швидше, що є корисним лише за умови, що код залишається достатньо підтримуваним та масштабованим для подальшого розвитку проекту.
Стартапи на ранніх етапах залежать від швидкості ітерацій. Вимоги швидко змінюються, функції додаються щодня, а код постійно переписується. У таких умовах обрані технології мають дозволяти швидко адаптуватися без погіршення користувацького досвіду.
Наведена нижче сукупність технологій є результатом приблизно чотирьох років експериментів із сучасними інструментами на реальній навчальній платформі. Вона охоплює автентифікацію, інтерфейс користувача, бекенд, хостинг, тестування та багато іншого; метою завжди було швидке створення нового на основі кодової бази, яку все ще можуть підтримувати люди, з інфраструктурою, здатною до масштабування.
Збереження простоти агентів та коду
Агенти полегшують швидке вдосконалення: виправлення помилок, нові функції та оптимізація продуктивності приходять дуже швидко. Вони також сприяють надмірній складності архітектури, адже додавання тисяч рядків коду є тривіальним. Важливо стримуватися від вирішення проблем, яких ще немає, та підтримувати простоту коду, інфраструктури та користувацького досвіду.
Невелика, проста налаштування допомагають навіть у цю епоху розробки з використанням агентів. Агенти краще координують свої дії, функції випускаються швидше, помилки легше виправляти, а люди можуть продовжувати підтримувати існуюче.
Підхід до використання агентів у продакшн-коді є збалансованим, а налаштування — скромними:
- Тримайте файл
AGENTS.mdабоCLAUDE.mdякомога коротшим. Додавайте до нього лише те, що повторюється у кожній розмові, а також деталі про проект, які агенти постійно неправильно розуміють. - Надто великі файли з інструкціями можуть погіршити продуктивність моделі та зробити її менш корисною.
На серверах MCP сервіс PostHog забезпечує легкий доступ до слідів помилок та журналів, що прискорює відлагоджування. Context7 надає моделі актуальну документацію до бібліотек, щоб агенти могли користуватися найновішою інформацією про бібліотеки та фреймворки. У більшості випадків агенти самостійно вирішують проблеми без допомоги сервера MCP, тому їх увімкнення рідко є необхідним.
Основне правило полягає у тому, що кожен додатковий інструмент, навичка чи сервер конкурують за увагу моделі. Усе, що не заслуговує на місце у поточному завданні, краще не використовувати, а налаштування можна переглянути щоразу, коли з’являється повторювана помилка, яку можна було б виправити однією інструкцією.
Фронтенд: React та Next.js
React є найпопулярнішим вибором для основи багатьох проєктів типу full-stack. Vue та Svelte також є варіантами, але велика екосистема бібліотек React полегшує додавання функцій та зміну напрямку розвитку, тому розробники віддають йому перевагу.
Слабкою стороною є пошукові системи. Google та Bing використовують ботів, які читають HTML-код сторінки, а сторінка, створена за допомогою React, зазвичай починається з порожнього тіла від сервера. Щоб сайт з’явився у результатах пошуку, перша відповідь від сервера має містити HTML із правильною інформацією про сторінку.
Next.js справляється з цим. Це фреймворк React, який пропонує серверну обробку та статичну генерацію, тож сторінки спочатку обробляються на сервері, а потім HTML надсилається до браузера, що означає, що початковий контент містить усе необхідне для ботів. Після цього на клієнта надсилається лише необхідний JavaScript, що зменшує розмір пакету. Це покращує як користувацький досвід, так і здатність пошукових роботів розуміти контент.
Текущим стандартом у проектах Next.js є app router, який полегшує використання таких функцій, як поступова статична генерація та часткова попередня обробка, що робить додаток швидшим. Нові проекти слід створювати з його використанням.
React рухається у напрямку серверної обробки, дещо наближаючись за принципами до PHP, а app router забезпечує гарний досвід розробки для компонентів, які спочатку обробляються на сервері. Кешування, Turbopack та налаштування, зручні для пошукових роботів, дозволяють швидко створювати та вдосконалювати продукт.
Інтерфейс користувача: бібліотека компонентів замість індивідуального дизайну
Традиційний розробка веб-сайтів включає планування, дизайн інтерфейсу та користувацького досвіду, реалізацію та численні обміни між дизайнерами та розробниками. Стартапи не можуть дозволити собі тривалий цикл роботи.
Найефективнішим підходом є вибір надійної рамки для створення інтерфейсу — у цьому випадку MUI — та дотримання шаблону дизайну. Альтернативою є те, щоб дизайнер створював усе у Figma, а потім розробники перебудовували це у React. Зберігання єдиного джерела інформації у кодовій базі дозволило заощадити місяці часу.
MUI пропонує великий набір налаштовуваних компонентів, які покривають поширені потреби. Усе можна змінити, але стандартні налаштування настільки хороші, що більшість компонентів використовуються з їхньою стандартною поведінкою та виглядом. Крім того, він постачає велику колекцію ікон, які можна використовувати як компоненти React, тож їх додавання є дуже простим.
Існують інші альтернативи:
- shadcn/ui є сучасним та популярним, хоча деякі вважають сумнівною практикою копіювання коду бібліотеки у власну базу коду через CLI.
- Ant Design — це хороший варіант.
- Chakra UI також є фреймворком для інтерфейсу користувача.
- HeroUI, раніше відомий як NextUI, також є гарним вибором.
Деякі люди віддають перевагу styled-components або Tailwind CSS. За допомогою будь-кого з цих інструментів все одно доводиться писати багато CSS, що гірше порівняно з фреймворком для інтерфейсу користувача з точки зору досвіду розробника, особливо коли метою є уникнення створення кожної сторінки з нуля.
Для натхнення допомагають магазини шаблонів. У власному магазині MUI є багато привабливих шаблонів інтерфейсу, а на Dribbble також є шаблони для React. Інший підхід — попросити агента створити кілька прототипів та вибрати найкращий; крім того, наявність навичок UI/UX покращує якість отриманих результатів.
Форми
Форми становлять значну частину роботи з full-stack розробкою. Zod та React Hook Form добре поєднуються та охоплюють майже все необхідне. Zod займається верифікацією схеми, включаючи типи, межі, довжину та переліки значень, а React Hook Form надає гнучкий API для взаємодії з формою. Разом вони дозволяють використовувати вкладені компоненти, які ділять одну форму, складну верифікацію та живе оновлення даних. Форми починають здаватися майже занадто простими.
Оскільки схема верифікації — це звичайний об’єкт, сумісний із TypeScript, одні й ті самі правила можуть описувати, що приймає форма, та що очікує функція на боці сервера. Це усуває цілу категорію неузгоджень між тим, що дозволяє інтерфейс користувача, та тим, що відхиляє сервер, а агенти значно надійніше читають схему, ніж логіку верифікації, розкидану по обробниках.
Бекенд, автентифікація та база даних
Firebase та Supabase пропонують послуги бекенду як сервісу, здатні масштабуватися до мільйонів користувачів, без необхідності утримувати власну інфраструктуру. У цій системі використовується Firebase для автентифікації, зберігання даних, бази даних Firestore та безсерверні функції, які містять власну логіку бекенду.
Автентифікація
Clerk — це потужний інструмент для автентифікації, але стандартна система Firebase також добре підходить. Firebase також постачає пакет під назвою firebaseui-web, який дозволяє налаштувати автентифікацію без необхідності писати код користувацького інтерфейсу. Щоб усе працювало без проблем, додаток Next.js також розгортається на спеціальному піддомені для автентифікації, щоб Firebase міг без проблем обробляти процес входу.
База даних
У традиційній архітектурі, де існує окремий фронтенд та бекенд, який працює з базою даних, фронтенд ініціює багато викликів API, які змінюють записи в базі даних. У багатьох проектах близько 80% цих викликів — це прості операції CRUD, а решта 20% — більш складні, такі як оновлення кількох записів чи об’єднання даних з кількох джерел. Firebase оптимізований для цих 80%, що полегшує маніпуляцію даними з фронтенду без зайвих кінцевих точок.
Для цього використовуються два компоненти.
- Правила Firestore. Контроль доступу та дозволи знаходяться в одному файлі —
firestore.rules. Кінцевим точкам API не потрібно перевіряти дозволи в кожній функції, оскільки Firebase автоматично перевіряє, чи може користувач прочитати дані чи створити, оновити чи видалити їх. Таке розділення усуває багато зайвого коду. - Клієнтське SDK Firestore. Створення, читання, оновлення та видалення даних відбувається через Firebase SDK, який також підтримує слухачів у реальному часі, збільшення лічильників та пакетні оновлення, причому все це автоматично перевіряється за правилами
firestore.rules.
Є один недолік — модель зберігання даних. Firestore оптимізований для читання, яке зазвичай є основним операцією, тому він сприяє використанню денормалізованих даних. Це може здатися неприродним для тих, хто звик до SQL, тож варто подивитися гарну доповідь на конференції про моделювання даних у Firestore.
Загалом Firestore забезпечує високу якість користувацького досвіду, особливо завдяки слухачам змін у реальному часі, а також гарний досвід розробки, що дозволяє додатку швидко адаптуватися до змінюючихся потреб.
Найкраще починати нові проекти в корпоративній версії Firestore у режимі Native. Вона підтримує функції, відсутні у старішій стандартній версії, такі як запити типу pipeline та вбудований пошук повного тексту, що забезпечує гнучкість бази даних, схожої на MongoDB, разом із простотою використання Firestore.
Функції без сервера
Код клієнта навмисно залишається простим, а складні частини ізольовані у коді сервера всередині функцій без сервера. Підхід, при якому фронтенд залишається простим, а сервер — розумним, добре себе показав. Firebase Functions можуть містити будь-який код сервера, і їх можна запустити за допомогою звичайного HTTP-запиту, створенням чи оновленням запису у Firestore або за графіком через Pub/Sub у вигляді завдання cron. Усі функції серверної частини можуть розташовуватися у окремих, самодостатніх функціях.
Інструменти типу BaaS, такі як Firebase, економлять багато часу та переважно працюють без проблем. Виправлення проблем, спричинених нерегулярностями в базі даних чи невдалими міграціями, трапляється рідко.
Функції ШІ
ШІ є важливою частиною сучасних веб-додатків, і багато продуктів включають чат-ботів та агентів. SDK ШІ від Vercel дозволяє інтегруватися з різними постачальниками моделей та створювати власних агентів. Його сила полягає у простоті підключення різних моделей та їх зміни, що забезпечує кращий досвід розробки, ніж у будь-якого SDK, призначеного конкретно для певної моделі.
Тести
Тестування, ймовірно, є найбільш суперечливою темою, особливо для стартапів із постійно змінюваними вимогами. Спочатку тестів не існувало. У міру розвитку продукту зміна існуючого коду з упевненістю, що продукція буде продовжувати працювати, стала майже неможливою, тому було введено тестування для бекенду, зокрема для шару сервісів Firebase Functions. Фронтенд не тестується, оскільки він залишається простим, тоді як розумний бекенд тестується щодо крайніх випадків.
Для тестування бекенду використовується Jest, а також faker.js для генерації фальшивих даних під час тестів. Вони виконуються у окремому проекті Firebase, щоб продукція залишалася недоторканою, що також дозволяє швидко вносити зміни без побоювань щодо впливу на користувачів. Як тільки тести пройдені, нова версія Functions випускається у продакшн.
Причиною тестування лише бекенду є економія коштів. Фронтенд, який лише відображає дані та викликає функції, має мало логіки, яку варто перевіряти, а тести користувацького інтерфейсу зазвичай перестають працювати при зміні дизайну, що у молодому продукті відбувається постійно. Саме в логіці бекенду може статися прихована регресія, яка може пошкодити дані або неправильно нарахувати кошти користувачеві, тому саме сюди спрямовуються зусилля.
Рефакторинг
У міру зростання проекту функції змінюються, вимоги зміщуються, а елементи старіють, тому рефакторинг стає неминучим. Дві речі найбільше сприяють впевненій модифікації коду: TypeScript та якісні тести інтеграції. TypeScript зберігає типи у безпеці після змін, а тести інтеграції підтверджують, що логіка все ще працює належним чином.
Рефакторинг трапляється частіше, ніж очікується. Не було жодного періоду у шість місяців без якогось значного рефакторингу, адже платформа постійно змінюється, а впровадження нових технологій призводить до значних змін у коді. Двома найважливішими етапами були перехід від звичайного React до Next.js, а потім — від маршрутизатора pages у Next.js до маршрутизатора app.
Хостинг
Оскільки бекенд повністю розташований на Firebase (Google Cloud), фронтенд розгортається на Vercel, який пропонує найзручнішу інфраструктуру для роботи з Next.js. Його інтеграція з GitHub добре працює з гілками та не вимагає ручної налаштування:
- Збірка коду у
mainавтоматично розгортається у продакшн. - Збірка коду у будь-яку іншу гілку запускає розгортання у режимі прев’ю з власним посиланням, тож кожну гілку можна переглядати в реальному часі, що полегшує швидку роботу над проектом.
Перегляд змін означає відкриття посилання, а не створення гілки та її запуск локально, що підходить для невеликої команди, де дизайнери, фахівці з продукту та інженери хочуть бачити процес роботи без необхідності налаштовувати свої комп’ютери.
Аналітика та моніторинг
Знання того, хто є користувачами та як вони використовують продукт, має велику цінність. Це може заощадити тижні чи місяці розробки, показуючи, що потрібно пріоритезувати, а ефективний моніторинг покращує користувацький досвід, виявляючи поширені помилки.
PostHog забезпечує загальну аналітику та моніторинг продукту, включаючи відтворення сеансів, фіксацію винятків, журнали та карти джерел у продакшені. Google Analytics для Firebase — це безкоштовна альтернатива, яка вимагає більше налаштувань, а Sentry — дещо дорожча. Усі вони допомагають краще зрозуміти користувачів, але ніщо не замінить прямого спілкування з ними.
Електронна пошта
Електронна пошта залишається одним із найнадійніших способів підтримувати зв’язок із користувачами, надсилати оновлення та зберігати їхню зацікавленість. Нещодавно цей інструментарій було замінено з Sendgrid на react-email разом із Resend.
react-email дозволяє створювати дуже налаштовувані електронні листи, перетворюючи кожен з них на компонент React. Resend добре інтегрується з ним та пропонує вигідні тарифи. Оскільки електронні листи є компонентами React, їх контролюють через систему версійного керування разом із рештою коду, тож кожна зміна фіксується в одному місці.
Попередній перегляд та тестування шаблонів також є простими, адже той самий компонент відображається в браузері під час розробки та генерує HTML, який потрапляє до скриньок користувачів.
Пов’язані матеріали
- Агент QuickBooks Finance, який працює на локальному LLM за допомогою Ollama та LangChain — це агент ReAct на моделі Qwen 3.5 9B та відеокарті RTX 4070, який читає дані QuickBooks в реальному часі без жодних витрат на хмарні сервіси. Дивіться код, результати роботи та відомі обмеження.
- Проектування системи пошуку роботи з кількома агентами: конвеєр обробки даних, HyDE та можливості спостереження — це дев’ятикроковий конвеєр LangGraph для підбору резюме до вакансій, що включає вісім варіантів налаштувань HyDE, маршрутизації моделей, обмежень швидкості та відстеження процесів.