Телеграм канал «M3 | WebDev»

В таких случаях поднимаю отдельные серверы.

Для контейнеризации использую Podman, а балансировку и маршрутизацию трафика закрываю через HAProxy.

Дальше всё зависит от сложности сервиса. Если задача относительно простая, пишу на Bun. Если речь о высоконагруженных TCP-серверах, сложной конкурентной обработке или критичных требованиях к производительности, выбираю Rust.

При этом инфраструктура не ограничивается запуском контейнеров. Развёртывание и конфигурацию серверов автоматизирую через Ansible, за CI/CD отвечает Semaphore, а мониторинг строю на Prometheus и Grafana.

Самими сервисами управляю напрямую через Podman. Мне нравится сохранять полный контроль над тем, что и где запущено, без дополнительного слоя оркестрации.

Это не попытка заменить Kubernetes одной командой. Просто для моей архитектуры такой подход даёт нужный уровень автоматизации, наблюдаемости и контроля без необходимости поддерживать отдельный кластер.

💭 К чему я в итоге пришёл?
Мне всё меньше нравится подход, когда для запуска проекта приходится собирать инфраструктуру из множества независимых сервисов и провайдеров.

Поэтому основную часть приложений стараюсь держать внутри Cloudflare, а собственные серверы использую для специализированных задач и критически важных компонентов.

При этом я не хочу, чтобы зависимость от одного провайдера превращалась в единую точку отказа.

Риск vendor lock-in снижаю за счёт Fastly и дублирования критических модулей на собственных серверах. Это позволяет не завязывать всю отказоустойчивость исключительно на Cloudflare и сохранять возможность переключения части нагрузки при проблемах у провайдера.

Разумеется, такая архитектура тоже требует усилий: синхронизации данных, продуманного переключения трафика и контроля за состоянием резервных компонентов.

Но для меня это разумный компромисс между удобством managed-сервисов и контролем над собственной инфраструктурой.

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

Где-то достаточно Cloudflare Workers, где-то нужен Bun, а где-то без Rust и собственных серверов не обойтись.

И мне гораздо интереснее заниматься такими архитектурными решениями, чем усложнять инфраструктуру ради самой инфраструктуры.

#JavaScript #TypeScript #Bun #Cloudflare #Rust #Architecture

🚀 Как я сейчас запускаю проекты с нуля
За последнее время у меня сформировался довольно стабильный подход к запуску новых проектов. Стараюсь использовать меньше зависимостей, не усложнять инфраструктуру без необходимости и при этом сразу закладывать возможность масштабирования под высокий RPS.

🎨 Что на фронтенде?
Bun полностью заменил мне Node.js. Для сборки использую Rsbuild, а если нужен SSR, подключаю Astro. Основным фреймворком для интерфейсов сейчас стал Vue.

Для UI обычно беру shadcn-vue. Нравится, что компоненты находятся непосредственно в проекте и их можно спокойно менять под себя. Tailwind настраивается при установке, а наличие MCP в экосистеме shadcn отдельный плюс. Особенно сейчас, когда значительную часть рутинной работы можно делегировать AI-агентам.

Для клиентского состояния использую Pinia, а работу с серверными данными закрываю через Pinia Colada. Запросы, кеширование, инвалидация, всё уже реализовано, нет необходимости писать собственные решения.

Весь фронтенд деплою исключительно в Cloudflare Pages. Для меня это уже стандарт, а не один из возможных вариантов. Если нужен SSR, использую интеграцию Astro с Cloudflare Workers.

⚙️ Что на бэкенде?
Здесь я полностью перешёл на Bun и Elysia. Нравится, насколько быстро можно поднять API, не обрастая кучей зависимостей и конфигураций.

У Elysia, кстати, есть официальные skills для AI-агентов. С ними агенты лучше понимают особенности фреймворка и реже пытаются писать Elysia так, будто это Express.

Но самое интересное здесь для меня это Eden. Он позволяет использовать типы API прямо на фронтенде, без генерации клиентов и ручного дублирования контрактов. Изменил что-то на бэкенде, TypeScript сразу подсветил проблемы на фронте. Для меня это одна из главных причин выбирать Elysia.

Авторизацию обычно закрываю через Better Auth, документацию делаю на Scalar, а за форматирование и линтинг отвечает Biome.

Кстати, очень жду, когда Biome наконец нормально подружится с Vue. Хочется использовать один инструмент на всём проекте и окончательно забыть про ESLint и Prettier.

Бэкенд деплою в Cloudflare Workers.

☁️ А что с инфраструктурой?
Здесь я стараюсь максимально оставаться внутри экосистемы Cloudflare. Причём речь уже давно не только о хостинге фронтенда и запуске API.

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

Для задач, где нужно координировать состояние или обеспечить последовательную обработку операций, использую Durable Objects. Особенно удобно, когда несколько запросов должны работать с одним состоянием без постоянной борьбы за синхронизацию.

R2 тоже давно перестал быть для меня просто файловым хранилищем. Всё чаще использую его как основу для Lakehouse, куда складываю события, исторические данные и аналитику. Это позволяет отделить аналитическую нагрузку от основных баз.

Фоновые задачи и асинхронную обработку событий перенёс на Cloudflare Queues. Благодаря этому удалось полностью отказаться от NATS и необходимости поддерживать отдельную инфраструктуру для брокера сообщений.

Для моих текущих сценариев возможностей Queues вполне хватает, а отсутствие ещё одного сервиса, за которым нужно следить, только радует.

KV использую там, где нужен быстрый доступ к распределённым данным и не требуется строгая консистентность.

Даже почту постепенно перенёс в Cloudflare. Раньше использовал AWS, теперь стараюсь закрывать эти задачи через возможности Cloudflare Email.

В итоге получается, что практически вся инфраструктура проекта живёт внутри одной экосистемы. И мне нравится, что вместо настройки и поддержки множества отдельных сервисов можно больше времени уделять архитектуре самого приложения.

🖥 А если Cloudflare не подходит?
Конечно, далеко не всё имеет смысл запускать в serverless.

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