Как я выбрал технологический стек для проекта и пожалел

Несколько лет назад в одной компании, где я работал, от отдела маркетинга пришел запрос разместить в углу сайта видеоприветствие в стиле сторис. Посидев-подумав, я решил обернуть такой функционал в мини-сервис. А что бывает после того, как решили что-то запустить? Конечно! Выбор стека 🙂.

В тот момент я начал все чаще использовать NodeJs и Angular в своих проектах. Однажды я “курил” тему js-фреймворков и наткнулся на небезызвестный NestJs.

Такой весь Angular-подобный он мне сразу зашёл. А то, что там работает валидация и TypeORM, казалось мне просто тихой гаванью.

Спустя пару недель я уже имел простенький бэк с приемом платежей и фронт с возможностью регистрации, создания виджета, оплаты тарифа и получения js-кода для вставки на сайт.

Далее настала пора заняться небольшим пиаром. Написал статью с обзором Обзор видеовиджетов для сайта и запустил рекламу с весьма скромным бюджетом. Пошёл небольшой трафик и регистрации.

Пользователи начали писать в чат поддержки вопросы: как настроить Яндекс Метрика, как спрятать определенный функционал и т.д. После нескольких ответом по e-mail, я решил что пора добавить разделы "Документация" и“Блог”, начать заниматься SEO.

Тут я и столкнулся с первой неопределенностью. Мне же нужно было, чтобы страницы рендерились на стороне сервера, а фронт у меня на Angular. Возиться с Universal не было желания, да и все равно нужна какая-то админка для создания документации и блога. В итоге я взял Drupal — одно время работал с ним.

И вот я имею бэк для сервиса на NestJs, клиентский фронт на Angular, главная страница сайта, дока и блог на Drupal. Уже начало напрягать 🙂.

Спустя какое время я захотел иметь возможность видеть всех клиентов: у кого какой тариф, функционал открытия и продления тарифа. Ну что же, настала пора поднимать админку."Внедрять ее во фронт на Angular и разграничивать по ролям?" подумал я. Для этого нужно клиентский API дополнять методами для админа. А если админка разрастется? Да и не хочется на каждую фигню свой метод писать. Тут я для себя определенно решил, админка будет только классическая (MPA). Реализовать ее можно было в двух местах, в Drupal или NestJs.

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

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

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

Если проект находится на стадии MVP, с неизвестным будущим или с вероятностью совершить в скором времени пивот, то стоит взять максимально простой и универсальный, с классическим подходом фулстек-инструмент. Я говорю про такие PHP/NodeJs фреймворки, как Yii2, Laravel, Symfony, Express, NestJs и им подобные. Мы их прекрасно знаем. Да это может быть даже любая CMS. Главное взять именно тот инструмент, на котором можно быстро слепить решение с быстрой и дешевой поддержкой.

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

P.S. Админку я так и не сделал…

⬇⬇⬇