Технологии в основе TechEnvolved

Каждый технологический выбор является компромиссом. Выбирать инструмент только потому, что он популярен или использовался в каком-то туториале, это прямой путь к накоплению ненужной сложности в кодовой базе. Наш стек намеренно небольшой: каждый компонент занимает своё место, потому что хорошо решает конкретную задачу.

// Core_Engine: Next.js 16

Платформа работает на Next.js 16. Мы выбрали его из-за Server Components и App Router, а не потому что это самый рекомендуемый фреймворк.

Логика проста. Большая часть того, что отдаёт контентный сайт, статична: текст статей, навигация, метаданные. Отправлять JavaScript в браузер только для того, чтобы браузер сам отрендерил этот контент на клиенте, это потеря времени и трафика. С Server Components вычисления остаются на сервере. Браузер получает готовый HTML. JavaScript отправляется только для тех частей страницы, которым он действительно нужен.

Практический результат: быстрая первая загрузка и хорошие показатели Core Web Vitals без ручной оптимизации. Поисковые роботы видят весь контент сразу, что упрощает SEO. Архитектура также делает кодовую базу понятнее: получение данных происходит там, где данные используются, без сложных цепочек props или глобального состояния для того, что могло бы быть просто серверным запросом.

Мы не используем Pages Router, getStaticProps или getServerSideProps. App Router с async Server Components покрывает всё, что нам нужно, чище и проще.

// Visual_Framework: Tailwind CSS

Наш визуальный дизайн следует одному правилу: интерфейс не должен конкурировать с контентом. Тёмный фон, контрастная типографика, минимум декора. Цель: чтение статьи здесь должно ощущаться как чтение в текстовом редакторе, а не как просмотр маркетингового сайта.

Tailwind CSS подходит для этого, потому что генерирует только тот CSS, который реально используется. Нет глобальных стилей, которые нужно проверять, нет конфликтов специфичности, нет мёртвых правил, накапливающихся со временем. Добавление нового компонента не требует открытия отдельного CSS-файла. Его удаление не оставляет осиротевших стилей.

В нашей дизайн-системе несколько устойчивых решений. Границы тонкие и с низкой прозрачностью, используются для структуры, а не для украшения. Цвет фона близок к чёрному, но не чисто чёрный: это снижает усталость глаз при долгом чтении. Акцентный цвет: насыщенный сине-зелёный, используется редко, для активных состояний и выносок. Типографика: Geist, хорошо читается на любых размерах.

Эффект размытого стекла (glassmorphism) в шапке и некоторых карточках применяется осознанно. Он передаёт ощущение глубины, не добавляя визуального шума. Мы используем его только там, где UI должен visually float над контентом, а не как общий декоративный паттерн.

// Deployment_Node: Vercel Edge Network

Сайт развёртывается на Vercel. Причина не в удобстве, хотя это действительно удобно. Причина: edge-инфраструктура.

Сервер в одном дата-центре отвечает медленно пользователям с другого конца света. Edge-сеть Vercel запускает код приложения в дата-центрах, распределённых по всему миру. Пользователь в Бангкоке получает ответ от ближайшего к Бангкоку узла. Пользователь в Лондоне получает ответ от узла рядом с Лондоном. Физическое расстояние между пользователем и сервером напрямую влияет на задержку, и эта архитектура минимизирует её.

Для сайта с аудиторией в разных регионах это важно. Среди наших пользователей есть люди из Юго-Восточной Азии, России, Японии и Европы. Одноregионное развёртывание означало бы заметно более медленную загрузку для большинства из них.

Развёртывание автоматизировано: push в основную ветку запускает сборку и публикацию. Для каждого pull request создаётся preview-сборка. Нет скрипта деплоя для ручного запуска, нет сервера, к которому нужно подключаться по SSH.

// Data_Layer: Supabase

Динамический контент (статьи, опубликованные через интерфейс администратора, комментарии, пользовательские данные) хранится в Supabase: это PostgreSQL с REST API и подпиской на события в реальном времени поверх него.

Мы его выбрали, потому что хотели хостируемый PostgreSQL без управления инфраструктурой, а JavaScript-клиент прямолинеен в использовании. Система безопасности на уровне строк (row-level security) обрабатывает авторизацию на уровне базы данных, что делает код приложения чище. Мы не пишем middleware для проверки прав на записи.

Статический контент (статьи на этом сайте, структурированные страницы) хранится в кодовой базе, а не в базе данных. Этот контент деплоится вместе с сайтом, загружается мгновенно с сервера и не требует запросов к базе. База данных зарезервирована для контента, который действительно изменяется во время работы.

От чего мы отказались

Мы оценили и отклонили несколько инструментов на этапе планирования.

CMS вроде Contentful или Sanity. Мы рассматривали headless CMS, но нашли абстракцию излишней для нашей структуры контента. Статьи хранятся в коде, что даёт полный контроль над рендерингом без внешней зависимости.

CSS-in-JS библиотека. Мы пробовали styled-components в более ранней версии и обнаружили, что затраты на рантайм и сложность сборки не оправдывают себя. Tailwind быстрее в работе и даёт меньший размер бандла.

Библиотека управления состоянием. У нас нет Redux, Zustand или Jotai. Server Components берут на себя получение данных. Состояние на клиенте управляется через useState и useContext там, где оно существует, а это небольшое количество мест. Глобальное состояние в контентном сайте обычно признак неправильной архитектуры, а не требования.

Этот материал отражает стек по состоянию на июнь 2026 года. Технологические решения меняются по мере изменения требований. Мы обновляем его при значимых изменениях.