С тех пор многое поменялось - и не по мелочи, а по сути.

Почему

В прошлой статье я рассказывал про Vue 3, Pinia + PiniaColada, Axios, UnoCSS, Naive UI, Zod, Lodash и Appwrite.
Это был отличный набор для старта, но когда ты начинаешь думать не только о MVP, но и о будущем масштаба, поддержки, стабильности и понятности - появляется желание пересмотреть фундамент.

Переезд на Nuxt 4

Я полностью перешёл на Nuxt 4.

Nuxt дал мне всё:

• понятную файловую архитектуру
• встроенную работу с данными и API
• нормальные SSR-дружелюбные механизмы
• меньше ручных костылей

Удалил PiniaColada и Axios

Раньше PiniaColada помогал кешировать запросы и делать декларативное состояние. Но в Nuxt мне это уже встроено через useFetch. Оно делает почти всё, что раньше делалось ручками.

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

Стили и компоненты

Я отказался от UnoCSS и Naive UI:

• стили теперь на Tailwind CSS
• компоненты на Nuxt UI - меньше сторонних “обёрток”, меньше конфликтов дизайна

Remeda вместо Lodash

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

Теперь везде Remeda - меньше импортов, лучше типы, чище код.

Supabase заменил Appwrite

Это был, пожалуй, самый большой сдвиг.

Я ушёл от Appwrite (в ходе работы наловил много проблем, которые не просто мешали, а не позволяли воплотить свои задумки), к Supabase:

• SQL-модель намного более предсказуема для сложных связей данных
• RLS и безопасность на уровне базы - это спокойнее
• весь API открытый
• нормальные серверные функции
• комьюнити больше больше чем в половину

Инфраструктура

Проект теперь живёт на новом VPS с 16 ГБ RAM.
Новый провайдер - REG.RU.

И отдельно отмечу - подключил Dokploy и стало сильно проще жить.

Что по продукту сейчас

Если раньше статья была про стек, то сейчас всё внимание сместилось на конкретный функционал:

Список гостей и управление гостями - именно этим я сейчас занимаюсь:

• добавление и редактирование гостей
• создание и редактирование групп из гостей (семья, друзья, коллеги)
• назначение главного гостя в группе
• хранение данных гостей в структуре, удобной для аналитики
• подготовку к логике рекомендаций (еда, напитки, формат мероприятия)

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

Frontend

С самого начала решил, что UI и взаимодействие — это ключевое в моём проекте. А значит, нужен фреймворк, который позволит быстро и понятно строить интерактивный интерфейс.

• Vue 3 + Composition API (TS) — потому что читаемо, масштабируемо и приятно писать. Я получаю гибкость и контроль без перегруза.
• Pinia + PiniaColada + Axios — для лёгкого и декларативного управления состоянием. PiniaColada помогает кешировать запросы и хорошо ложится в архитектуру Composition API.
• VueUse — удобнейший набор полезных хуков, без которого я уже не представляю себе разработку.
• UnoCSS — Я отказался от Tailwind в пользу Uno — он быстрее, легче и даёт больше контроля. Классы применяются моментально, без генерации огромных CSS-файлов; поддерживает кастомные токены, пресеты, темизацию. Отлично сочетается с Vue и даёт свободу в дизайне без ощущения «бойся трогать CSS».
• Iconify — универсальный способ подключения иконок. Можно легко использовать любую коллекцию (Material, Tabler, Fluent и др.) и на лету менять стиль, цвет, отлично дружит с UnoCSS.
• Naive UI — кастомизируемая компонентная библиотека, легко стилизуется под нужный стиль.
• Zod — использую для строгой валидации данных: форм, API-ответов и схем. Удобно типизируется, работает отлично в связке с TypeScript, и позволяет быстро ловить ошибки ещё до рендера.
• Lodash — потому что удобные утилиты для работы с массивами и объектами — это всегда +10 к чистоте кода.
• Vite — быстрый сборщик с хорошей интеграцией с Vue 3.

Backend

Вместо того, чтобы писать свой бэкенд с нуля, я выбрал Appwrite как backend-as-a-service:

• Удобная работа с коллекциями, документами и файлами.
• Готовая авторизация и безопасность из коробки.
• Быстрый старт — REST API (планирую переезд на GraphQL пока это еще не сильно напряжно) без лишнего, всё по делу.

Мне важно было быстро запустить прототип, и Appwrite дал возможность не застревать на инфраструктуре.

Инфраструктура

Проект развернут на VPS (на данный момент 4 x 3.3 ГГц CPU • 8 ГБ RAM • 80 ГБ NVMe), где крутится всё: фронт, Appwrite, GitLab.

• Свой GitLab CE с CI/CD пайплайнами и репозиториями.
• Фронтенд разбит на три контейнера:
• prod — продакшен-сборка.
• dev — основная ветка разработки.
• dev-2 — для экспериментов, обкатки фичей, работы с UI.
• В скором времени планирую запустить alpha - сборка с MVP проекта, которым уже можно будет пользоваться по назначению.
• Бэкапы всех сервисов автоматизированы и регулярно выгружаются.

Почему не Nuxt / Tailwind / Firebase?

• Nuxt — пока не нужен SSR и не хочется лишней магии.
• Tailwind — слишком тяжёлый для проекта, сложности в сборке и кастомизации.
• Firebase — мощный, но избыточный, а мне хотелось SelfHosted + REST/GraphQL, а не SDK с обвязками.

На что делаю упор в архитектуре

• Чистый код и логическая разделённость слоёв.
• Компоненты — маленькие и переиспользуемые.
• Сторы — изолированы и читаемы, храню в них только вспомогательную информацию, никаких данных.
• Работа с API — через универсальные обёртки, чтобы не размазывать логику по компонентам.

Без вайб-кодинга

В Invaiti я стараюсь избегать «вайб-кодинга» — когда решения принимаются по наитию, без чёткого плана, архитектуры или обоснований, когда ты полагаешься на AI или генераторы настолько, что перестаёшь принимать решения осознанно и развивать себя как разработчика. Такой подход может быть забавным на пет-проектах, но в реальном продукте он быстро приводит к хаосу.

Зато я за:

• предсказуемую структуру кода, чтобы и я, и любой новый разработчик могли быстро разобраться;
• разделение ответственности: компоненты, сторы, API, утилиты — всё отдельно;
• логичные имена, минимальный кросс-импорт и максимум читаемости.

Если пишу компонент — то стараюсь сразу представить, как его протестировать, переиспользовать и изменить через месяц.

Проект должен быть живым и читаемым через полгода, а не только вечером в пятницу

Здесь я буду делиться этапами создания проекта: от идей и прототипов до реальных технических решений, фич и сложностей, с которыми сталкиваюсь на пути. Это не просто дневник — это история создания сервиса, которым я сам горжусь и который хочу сделать действительно полезным.

Идея проекта

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

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

Так родилась идея Invaiti* — сервиса для создания цифровых приглашений, которые не только выглядят стильно, но и реально помогают организаторам. Я хотел создать инструмент, который избавит людей от лишнего стресса и сделает организацию приятной частью подготовки, а не источником головной боли.

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

Цели проекта

💡 Сделать организацию событий проще
Чтобы каждый мог без опыта и лишнего стресса оформить приглашение и собрать всю нужную информацию от гостей.

🎨 Дать людям инструмент, с которым приятно работать
Уделить внимание дизайну, удобству, деталям — чтобы даже мелочи радовали.

🤝 Помочь создавать атмосферу
Событие начинается не с дня “Х”, а с приглашения. Я хочу, чтобы оно задавало правильное настроение.

📊 Добавить аналитику и автоматизацию
Показывать, сколько людей точно придёт, кто ещё не ответил, какие есть пожелания — и при этом не перегружать интерфейс.

🌍 Расширить аудиторию
Со временем — добавить мультиязычность, поддержку разных культурных сценариев и типов событий: от свадьбы до бизнес-ивента.