<Влад Худяков создал новое обсуждение>

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

В статье расскажу, как наша команда начала закрывать бэк силами фронтов, как мы искали идеальный фреймворк, прошли путь от PHP до Node.js, а потом поняли, что делаем low-code. Теперь мы можем закрывать потребность клиентов на несложный бэкенд, не превращаясь в фуллстек-команду.

В моей прошлой статье React, Angular и Vue оживленно общались между собой. Судя по всему, такой шуточный формат всем зашел, поэтому шалость продолжается и тут!

<Фронтенд присоединился к обсуждению>

<Бэкенд заходит по ссылке-приглашению>

В смысле вы занимаетесь разработкой без бэкенда? Вы решили окончательно обо мне забыть?! Крупные проекты так не делаются, базу данных клиентов вы где хранить будете? Самостоятельные такие стали, а про безопасность кто подумает? Да вы же персональные данные сольете при первой же возможности!

Фронтенд

Вообще-то без тебя команда сделала уже много проектов – интернет-магазины, интерактивные карты, квизы, SPA, сервисы для бизнеса ???? 

Бэкенд

Ага, посмотрю я на вас, когда вы попробуете сделать без меня что-то посерьезнее… К кому потом придут исправлять проект, который вы сделали? Ко мне. Так что без меня вам никак не обойтись! 

С чего все началось

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

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

Бэкенд

Жаль, что вас так сильно втянуло в эти дизайнерские штучки… Так вы совсем потеряете хватку, ни один большой заказ не потянете! Кто вообще станет заказывать продукт у компании, которая не умеет в бэкенд?

Фронтенд

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

Бэкенд

Чего-то сомневаюсь, что есть спрос на аутсорс фронтенда…

Фронтенд

Ну вообще-то компания работает с крупными корпорациями на аутсорсе, оказывает поддержку, обновляет старые внутренние сервисы, разрабатывает с нуля полноценные сайты и сервисы на реактивных фреймворках. Этого мало тебе, бэк?

Бэкенд

И что, с бэкендерами совсем не работают?

Фронтенд

Почему же... при необходимости подключали бэк со стороны клиента.

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

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

Три способа закрывать бэкенд-задачи

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

• Рискованно. Если бэкендеры сделают что-то не то, нам придется объясняться с клиентом, ведь по договору роль исполнителя на нас. Контроля над субподрядчиком у нас нет, а вот ответственности за него – сколько угодно.

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

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

Бэкенд

Ох уж эти проблемы с доверием к подрядчикам...

Фронтенд

Вообще-то с ними реально сложно. Вот представь: ребята сделали фронт, передали подрядчику доработать бэкенд, а там бюджет внезапно вырастает в 2-3 раза.

Бэкенд

С чего бы вдруг?

Фронтенд

Может декомпозицию провели неверно, или сроки изначально оценили слишком оптимистично. Но проблема в том, что мы не знаем об этих проблемах – и заказчику объяснить не можем. А прикинь, если подрядчик поставит на наш проект бэкендера-джуна? 

Бэкенд

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

Собственная бэкенд-команда – это второй очевидный вариант. Когда мы активно взялись за эту историю, я общался с разными СТО и экспертами-разрабами, и они посоветовали не бросаться в найм бэков и вот почему:

• Дорого. Нужно два специалиста как минимум. Сеньор, который будет строить высоконагруженные сервисы, собеседовать новых сотрудников, управлять бэкенд-юнитом. И мидл для основной работы руками: интеграции с фронтом, работы с контроллерами и так далее.

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

Бэкенд

А я тебе подскажу решение все этих проблем – пусть возьмут больше задач, связанных с бэкендом. Так и задачи появятся, и деньги на хороших бэкендеров. Здесь и риски минимальные.

Фронтенд

Смотри, ты предлагаешь перестроить процессы в команде, поменять всю стратегию маркетинга, сменить подход к клиентам и нанять двух дорогих специалистов. Правильно я понимаю? А зачем?

Бэкенд

Ну вы сможете более крутые проекты делать… 

Фронтенд

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

Бэкенд

Надеюсь, со мной кто-нибудь поделится этими тайными знаниями…

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

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

Бэкенд

Ну и придумали же – фронт без бэка… Хотя бы какая-то база данных должна быть у интернет-магазина, любого сервиса или приложения. У CMS – тем более. Откуда ваш хваленый фронтенд берет данные и куда отправляет их?

Фронтенд

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

Как мы стали закрывать бэкенд силами фронта

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

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

• С реализацией бэка руками фронтендеров (каталоги, простые CRM-системы, SPA)

Естественно, никаких готовых решений у нас не было. Поэтому мы принялись искать тот самый фреймворк.

Список требований к фреймворку был небольшой:

• Дружит с экосистемой Vue – потому что мы на нем работаем

• Поддерживает кастомную логику – чтобы удобно масштабировать проекты

• Предоставляет удобную работу с документацией – чтобы не путаться в своем же проекте и передавать доки заказчику в понятном виде

• Помогает быстро запускаться – чтобы не тратить время и ресурсы заказчика на долгую разработку

Дальше мы начали пробовать разные подходы и искать то, что подойдет именно нам.

Попытка №1: Laravel + Inertia.js

Я отказался на время от фронта и углубился в бэкенд-разработку, начал изучать основы и учился писать простые API. 

Первая попытка – это Laravel + Inertia.js, что позволило нам работать на стеке Vue.js/React/Svelte. Выглядело это так:

Задумка была неплохая: на Vue мы уже работаем, добавляем к нему Inertia, которая помогает склеить Vue с бэком на Laravel. Но, к сожалению, такой вариант нам не подошел по двум причинам:

• Присутствие PHP. Во-первых, нужно создавать по два разных шаблона с Vue и PHP. Во-вторых, пришлось настраивать окружение под PHP, устанавливать лишние расширения на VScode, ставить PHP Shtorm. На все эти дополнительные шаги тратится лишнее время, так что мы решили, что нам неудобно работать с двумя языками.

• Нет админки из коробки. Мы собирали бэк, не зная, как им будет управлять клиент. У нас в базе нет той админки, в которой можно будет менять и редактировать контент. Приходилось искать готовые решения для админ-панели. Nova платная.

Бэкенд

Не звучит как фронт без бэка… Или у нас теперь Laravel – это инструмент фронтендера?

Фронтенд

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

При этом скажу, что в некоторых ситуациях Laravel + Inertia.js вполне подойдут. Возможно, вы бэкендер на PHP и вам не хватает реактивного фронта на Vue или React, можно попробовать такой вариант.

После этой попытки в список наших требований к фреймворку добавились новые пункты:

• Дружит с экосистемой Vue, потому что мы на нем работаем

• Поддерживает возможность кастомной логики

• Предоставляет удобную работу с документацией

• Помогает быстро запускаться

• Работает на JavaScript

• Фронт и бэк должен храниться по отдельности, не иметь общих зависимостей

• Это должен быть Headless CMS, что бы мы смогли легко расширять фронт

Объясню, почему мы выбрали Headless CMS. Обычные CMS – это связка фронтенд и бэкенд, а потом уже рендер страницы. 

А есть «безголовые CMS», где бэк не привязывается к фронту:

Мы просто делаем API, а потом уже можем спокойно его расширять под несколько фронтенд-приложений. Headless CMS дает свободу выбора в реализации фронта, позволяет быстро переноситься в новые интерфейсы и, конечно, сокращает время на запуск продукта. 

Бэкенд

Слушай, а ведь и правда неплохая идея – отсоединить бэк от фронта. Один раз с бэком разобрались, а потом любой фронт можно к этому прикрутить.

Фронтенд

Ага, поэтому так и зашла идея с Headless CMS! Клиент попросил веб-сервис – команда сделала. А потом ему внезапно требуется мобильное приложение: ребята быстро собирают новый фронт и обращаются к тому же бэку через тот же API.

Бэкенд

Хм… Звучит любопытно.

В общем, с этими новыми идеями мы продолжили эксперименты.

Попытка №2: Express.js

Потом мы присмотрелись к Express.js – слышали, что это самая гибкая история для бэка. Это кастомное решение, которое по идее должно было решить проблему с интеграцией двух сервисов.

Мы даже успели применить его на одном проекте. Это был Mission: Luna – HR-сайт для сбора вакансий с интеграцией huntflow+webflow.

На Express.js мы собрали некий остров, который ходит на huntflow и проверяет статусы вакансий. Если они поменялись, то он отправляет запрос в webflow и публикует данные на сайте.

В этом подходе мы нашли свои плюсы:

• Express.js очень универсален и подойдет под любой проект. Если ты отлично его знаешь, он похож на пластилин – берешь и лепишь, что хочешь. 

• Более простая разработка за счет одного языка. Можно применить Express.js на стороне сервера, полностью собрать проект на JavaScript-стеке – такой код может поддерживать большинство фронтендеров.

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

Но такая свобода влечет за собой и недостатки:

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

• Из-за высокой гибкости может вырасти порог вхождения в проект – за счет разных конфигураций и настроек кода разработчикам нужно больше времени на внедрение. Чтобы справиться с этой проблемой, можно взять фреймворк Nest, который дает высокий уровень абстракции и предоставляет готовую архитектуру на старте.

Бэкенд

Так, вы своего добились – избавились от PHP, начали писать только на JavaScript, нашли гибкие инструменты. Осталось только найти штуку с интерфейсом? 

Фронтенд

Как минимум. А вообще команде хотелось бы все тех же широких возможностей, гибкости и простоты в запуске продуктов.

Бэкенд

Сомневаюсь, что вы найдете настолько идеальный вариант.

Попытка №3: Strapi

Что делать с этими недостатками? Понятного ответа на этот вопрос у нас не было, пока мы удачно не наткнулись на Strapi – бесплатный open-source фреймворк на Node.js, который помогает управлять контентом. Выглядит он так:

Из коробки есть админка, которая позволяет хранить и изменять данные, а еще имеет полный CRUD – возможность создавать, читать, редактировать и удалять записи в базах данных. Рендер основной версии сайта происходит за счет Nuxt – то есть все на фронте. 

Здесь мы создаем модель заметок и связанное поле с моделью пользователя. Мы настраиваем связи так, что у юзера есть несколько заметок, но не наоборот. Там же создаются заметки и редактируются. Дальше обращаемся по API с запросом и получаем ответ. Еще можно подключить к Strapi:

• Встроенный GraphQL, чтобы запрашивать только необходимые данные.

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

• Визуальный редактор Editor.js, чтобы работать с контентом было удобнее.

• Swagger, чтобы автоматизировано документировать код.

Strapi подкупает широким выбором плагинов под любые задачи, мультипользовательской авторизацией с JWT-токенами, кастомной логикой, возможностью работать с Nuxt и другими реактивными фреймворками.

UPD. Спасибо большое за комменты! Раскрываю тему Strapi:

• В Strapi есть многопользовательский функционал из коробки. Можно регистрироваться, авторизовываться и получать JWT-токен. Так же можно управлять доступами к API, отдельными роутами, запрещать или разрешать определенные методы, допустим findOne.

• Есть роли, так же из коробки, где мы можем обозначать права и возможности аккаунтов.

• Базу можно хранить как SQLite, либо же подцепить PostgreSQL или другие базы данных и работать с env.

• Миграции происходят автоматически, как только мы изменяем модель через UI, там же редактируем поля, типы и прочее.

  В работе со Strapi написание кода минимальное, все решается путем взаимодействия с UI. Код придется писать там, где нужно кастомизировать логику, перезаписать, к примеру, контроллер или сервис.

Мы освоили Strapi на практике, перезапуская проект «Помощь». Перевели сайт на стек Vue + Strapi. За основу взяли фреймворк Nuxt.js, для хранения данных использовали стейт-менеджер Vuex, который по API получает данные из Strapi.

Бэкенд

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

Фронтенд

Как здорово, что ты наконец признаешь мои возможности! Кстати, команде тоже нравится так работать – реализация бэка фронтом дает кучу возможностей для роста и развития навыков.

Да и клиенты рассуждают из бизнес-логики. В конце концов, они мыслят финальными продуктами: приложение для поиска работы, сайт магазина или благотворительного фонда. Со Strapi можно быстро и дешево проверить гипотезы и запустить MVP. Если все работает стабильно, просто в поддержке и дешево, тогда какая разница, какие технологии под капотом?

Бэкенд

Окей, ты меня убедил, в этом случае и правда лучше без меня. Но иногда бэкенд все-таки нужен…

Фронтенд

Конечно! Погоди, скоро Влад как раз про это расскажет!

Бэкенд не нужен? Не совсем

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

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

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

Заключение

Так о чем все это было-то? Собрал важные мысли из статьи:

• Есть три способа работать с бэкендом:

  • Субподрядчики. Это рискованно, ведь мы не можем влиять на результат, но несем ответственность за него. Еще с подрядчиками сложно общаться, на это уходит время и деньги клиентов. 

  • Штатные сотрудники. Это довольно дорого и связано с рисками слить данные клиентов. Еще проверьте, есть ли у вас стабильный поток задач для бэкендеров. Если нет, команда бэкенда будет простаивать.

  • Реализация бэкенда инструментами фронтенда. Это дешево, быстро и удобно, но подходит далеко не для каждого проекта.

• Если вы решили делать фронт без бэка, можно выбрать такие технологии:

  • Laravel + Inertia.js. Они позволяют работать на стеке Vue.js/React/Svelte. Но есть и минусы: придется осваивать и использовать PHP, плюс придумывать решение по админке (из коробки ее нет).

  • Express.js и Nest.js. Это самая гибкая и универсальная история для бэка, которая подойдет под любой проект. Еще с этим стеком можно работать только на JavaScript и интегрировать разные сервисы (например, huntflow+webflow). Из минусов: нет интерфейса и не всегда низкий порог вхождения.

  • Strapi – это бесплатный open-source фреймворк на Node.js, который помогает управлять контентом. К нему можно подключить кучу разных плагинов, можно работать с Nuxt и другими реактивными фреймворками, писать кастомную логику и многое другое. Подходит для быстрых запусков, но сложные проекты этот стек не потянет.

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

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

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