<Влад Худяков создал новое обсуждение>
Всем привет! Я Влад Худяков, вот уже 7 лет занимаюсь фронтенд-разработкой сайтов и приложений. Сейчас я техлид и партнер Прагматики, развиваю собственную команду разработки. Мы делаем упор на реактивные фреймворки, используем Vue.js и всю его экосистему.
Сегодня я поделюсь инструментами, с помощью которых мы строим отдел разработки без бэкенда. Однажды я уже выступал на эту тему, и после выступления меня завалили уточняющими вопросами. Так что я решил отдать основные поинты выступления на суд аудитории Хабра.
В моей прошлой статье React, Angular и Vue оживленно общались между собой. Судя по всему, такой шуточный формат всем зашел, поэтому шалость продолжается и тут!
<Фронтенд присоединился к обсуждению>
<Бэкенд заходит по ссылке-приглашению>
В смысле вы занимаетесь разработкой без бэкенда? Вы решили окончательно обо мне забыть?! Крупные проекты так не делаются, базу данных клиентов вы где хранить будете? Самостоятельные такие стали, а про безопасность кто подумает? Да вы же персональные данные сольете при первой же возможности!
Фронтенд
Вообще-то без тебя команда сделала уже много проектов – интернет-магазины, интерактивные карты, квизы, SPA, сервисы для бизнеса 😉
Бэкенд
Ага, посмотрю я на вас, когда вы попробуете сделать без меня что-то посерьезнее… К кому потом придут исправлять проект, который вы сделали? Ко мне. Так что без меня вам никак не обойтись!
С чего все началось
Сейчас мы занимаемся только фронтенд-разработкой и версткой, много работаем с Vue.js. Штатных бэкенд-разрабов у нас нет, причем по историческим причинам. Мы всегда работали в студии дизайна: верстали макеты, пилили сервисы, делали анимацию, качали креативы. Набрались опыта везде: в бизнес-логике и в креативах, научились анимировать и экспериментировать с чувством прекрасного.
Так дизайн заложился в культурный код нашего юнита. На рабочих процессах это тоже отражалось. Например, наши фронты помогали разрабатывать дизайн-макеты, консультировали и отсекали слишком дорогие дизайн-решения, которые увеличивали стоимость разработки. В общем, наша команда совсем отчалила от разработки и уплыла в дизайн.
Бэкенд
Жаль, что вас так сильно втянуло в эти дизайнерские штучки… Так вы совсем потеряете хватку, ни один большой заказ не потянете! Кто вообще станет заказывать продукт у компании, которая не умеет в бэкенд?
Фронтенд
Да нет же, с клиентами все как раз окей! Команда вышла из дизайн-студии, стала самостоятельно заниматься фронтенд-разработкой, уже полгода находят клиентов вне дизайн-контекста. Не все клиенты такие ворчливые, как ты.
Бэкенд
Чего-то сомневаюсь, что есть спрос на аутсорс фронтенда…
Фронтенд
Ну вообще-то компания работает с крупными корпорациями на аутсорсе, оказывает поддержку, обновляет старые внутренние сервисы, разрабатывает с нуля полноценные сайты и сервисы на реактивных фреймворках. Этого мало тебе, бэк?
Бэкенд
И что, с бэкендерами совсем не работают?
Фронтенд
Почему же... при необходимости подключают бэк со стороны клиента.
В итоге мы вышли в свободное плавание: компании приходили с заказами, мы делали фронт, но со временем поняли, что многое упускаем. Мы старались над фронтом, но дальше никакого влияния на продукт не имели. Бывали случаи, когда к нашему фронту добавляли не самый качественный бэкенд – и заказчик в итоге получал низкий результат, несмотря на наши усилия.
С другой стороны, все идет неплохо, спрос на аутсорс фронтенда есть. Так что со временем мы решились брать на себя больше ответственности и начали думать, как нам покрывать запрос клиентов на бэк.
Три способа закрывать бэкенд-задачи
Первое и очевидное – субподрядчики. Мы уже с ними работали, но хотели отойти от такого сценария. Для нас минусы были очевидны:
Рискованно. Если бэкендеры сделают что-то не то, нам придется объясняться с клиентом, ведь по договору роль исполнителя на нас. Контроля над субподрядчиком у нас нет, а вот ответственности за него – сколько угодно.
Сложно в общении. В работе с субподрядчиками постоянно происходят какие-то глухие телефоны, все общение происходит медленно и печально. Больше разговоров, чем работы над продуктом.
Нет влияния на результат. Всегда есть риски нарваться на некомпетентных подрядчиков. Вот мы сделали крутой дизайн, отверстали, отдали на разработку бэкенда. Если подрядчик реализует проект некачественно, наша работа становится сливом времени и денег заказчика. Согласитесь, такое себе?
Бэкенд
Ох уж эти проблемы с доверием к подрядчикам...
Фронтенд
Вообще-то с ними реально сложно. Вот представь: ребята сделали фронт, передали подрядчику доработать бэкенд, а там бюджет внезапно вырастает в 2-3 раза.
Бэкенд
С чего бы вдруг?
Фронтенд
Может декомпозицию провели неверно, или сроки изначально оценили слишком оптимистично. Но проблема в том, что мы не знаем об этих проблемах – и заказчику объяснить не можем. А прикинь, если подрядчик поставит на наш проект бэкендера-джуна?
Бэкенд
Понимаю, он напишет бэкенд, который не держит нагрузку. Тогда надо все под свой контроль брать! Почему бы не взять парочку штатных бэкенд-специалистов?
Собственная бэкенд-команда – это второй очевидный вариант. Когда мы активно взялись за эту историю, я общался с разными СТО и экспертами-разрабами, и они посоветовали не бросаться в найм бэков. Я изучил этот вопрос подробнее и понял, что перспективы найма бэков в штат для нас вообще не радужные:
Дорого. Нужно два специалиста как минимум. Сеньор, который будет строить высоконагруженные сервисы, собеседовать новых сотрудников, управлять бэкенд-юнитом. И мидл для основной работы руками: интеграции с фронтом, работы с контроллерами и так далее.
Снова рискованно. Бэкенд работает с данными, в том числе – с чувствительными. Если бы мы вдруг слили персональные данные клиентов, всей команде пришлось бы несладко. Такие репутационные риски нам не нужны.
Не хватает задач. Мы всегда сосредотачивались на фронтенде и закономерно получали меньше запросов на полноценный бэк. Проще говоря, у нас нет стабильного потока задач для двух бэков.
Бэкенд
А я тебе подскажу решение все этих проблем – пусть возьмут больше задач, связанных с бэкендом. Так и задачи появятся, и деньги на хороших бэкендеров. Здесь и риски минимальные.
Фронтенд
Смотри, ты предлагаешь перестроить процессы в команде, поменять всю стратегию маркетинга, сменить подход к клиентам и нанять двух дорогих специалистов. Правильно я понимаю? А зачем?
Бэкенд
Ну вы сможете более крутые проекты делать…
Фронтенд
У нас нашлось решение получше. Я тоже умею делать все эти твои мудреные штуки, полноценный проект можно реализовать и без тебя!
Бэкенд
Надеюсь, со мной кто-нибудь поделится этими тайными знаниями…
В итоге мы пошли другим путем и реализовали бэкенд через фронтенд. Минус здесь видим один – этот вариант не подходит для больших проектов. На масштабе есть нюансы с разработкой – точнее, с настройкой сервера под сложные продукты, и без субподрядчика никак. Но с большинством других задач мы справляемся сами.
В остальном сплошные плюсы: не приходится контролировать подрядчика, стыковаться при интеграции, учить PHP и настраивать окружение под него. Для нас так удобнее, дешевле, быстрее и проще во всех аспектах.
Бэкенд
Ну и придумали же – фронт без бэка… Хотя бы какая-то база данных должна быть у интернет-магазина, любого сервиса или приложения. У CMS – тем более. Откуда ваш хваленый фронтенд берет данные и куда отправляет их?
Фронтенд
Представляешь, и CMS можно сделать руками фронтендера, и с базами данных работать по полной программе. Ты присядь, попей еще чая с плюшками, эта тема будет чуть позже.
Как мы стали закрывать бэкенд силами фронта
Сейчас с проектами среднего масштаба история простая – есть все инструменты для реализации сайтов и сервисов одними руками и без отдельных спецов по бэкенду. Блоги, SPA, многопользовательские сервисы, многостраничники можно реализовать двумя способами:
Совсем без бэкендеров
С реализацией бэка руками фронтендеров
Естественно, никаких готовых решений у нас не было. Поэтому мы принялись искать тот самый фреймворк.
Список требований к фреймворку был небольшой:
Дружит с экосистемой Vue – потому что мы на нем работаем
Поддерживает кастомную логику – чтобы удобно масштабировать проекты
Предоставляет удобную работу с документацией – чтобы не путаться в своем же проекте и передавать доки заказчику в понятном виде
Помогает быстро запускаться – чтобы не тратить время и ресурсы заказчика на долгую разработку
Дальше мы начали пробовать разные подходы и искать то, что подойдет именно нам.
Попытка №1: Laravel + Inertia.js
Все началось с того, что мне пришлось отказаться на время от фронтенда. Я углубился в бэкенд-разработку, начал изучать основы и учился писать простые API.
Первая попытка – это Laravel + Inertia.js, что позволило нам работать на стеке Vue.js/React/Svelte. Выглядело это так:
Задумка была неплохая: на Vue мы уже работаем, добавляем к нему Inertia, которая помогает склеить Vue с бэком на Laravel. Но, к сожалению, такой вариант нам не подошел по двум причинам:
PHP. Во-первых, нужно создавать по два разных шаблона с Vue-темплейтами и php-файлами. Во-вторых, пришлось настраивать окружение под PHP, устанавливать лишние расширения текстового редактора. На все эти дополнительные шаги тратится лишнее время, так что мы решили, что нам неудобно работать с двумя языками.
Нет админки из коробки. Мы писали бэк, не зная, как им будет управлять клиент. У нас в базе нет той админки, в которой можно будет менять и редактировать контент. Приходилось искать готовые решения, которые добавят админ-панель.
Бэкенд
Не звучит как фронт без бэка… Или у нас теперь Laravel – это инструмент фронтендера?
Фронтенд
Ну да, это бэк с фронтом – именно тот вариант, от которого команда хотела уйти. Они решили разделить фронт и бэк, чтобы между нами не было общих зависимостей. Просто с клиентами часто происходит такая история – делают сначала веб-сервис, а потом его же хотят завернуть в мобильное приложение. В таких ситуациях фронт и бэк точно надо делить.
Спасибо, фронтенд. При этом скажу, что в некоторых ситуациях Laravel + Inertia.js вполне подойдут. Если вы уже работаете с бэком на PHP, но вам не хватает реактивного фронта на Vue или React – можно попробовать такой вариант.
После этой попытки в список наших требований к фреймворку добавились новые пункты:
Дружит с экосистемой Vue, потому что мы на нем работаем
Поддерживает возможность кастомной логики
Предоставляет удобную работу с документацией
Помогает быстро запускаться
Работает на JavaScript, потому что это удобно и нам, и клиенту
Позволяет работать с фронтом и бэком по отдельности, потому что нам так удобнее
Желательно на Headless CMS, потому что такой подход позволяет четко разделить фронт и бэк
Объясню, зачем мы добавили последний пункт. Обычные CMS – это связка фронтенд и бэкенд, а потом уже рендер страницы.
А есть «безголовые CMS», где бэк не привязывается к фронту:
Мы просто делаем API, а потом уже можем спокойно его расширять под несколько фронтенд-приложений. Headless CMS дает свободу выбора в реализации фронта, позволяет быстро переноситься в новые интерфейсы и, конечно, сокращает время на запуск продукта.
Бэкенд
Слушай, а ведь и правда это неплохая идея – отсоединить бэк от фронта. Один раз с бэком разобрались, а потом любой фронт можно к этому прикрутить.
Фронтенд
Ага, поэтому так и зашла идея с Headless CMS! Клиент попросил веб-сервис – команда сделала. А потом ему внезапно требуется мобильное приложение: ребята быстро собирают новый фронт и обращаются к тому же бэку через тот же API.
Бэкенд
Хм… Звучит любопытно.
В общем, с этими новыми идеями мы продолжили эксперименты.
Попытка №2: Express.js и Nest.js
Потом мы присмотрелись к Express.js и Nest.js – слышали, что это самая гибкая история для бэка. Это кастомное решение, которое по идее должно было решить проблему с интеграцией двух сервисов.
Мы даже успели применить его на одном проекте. Это был Mission: Luna – HR-сайт для сбора вакансий с интеграцией huntflow+webflow.
На Express.js и Nest.js мы собрали некий остров, который ходит на huntflow и проверяет статусы вакансий. Если они поменялись, то он отправляет запрос в webflow и публикует данные на сайте.
В этом подходе мы нашли свои плюсы:
Express.js очень универсален и подойдет под любой проект. Если ты отлично его знаешь, он похож на пластилин – берешь и лепишь, что хочешь.
Более простая разработка за счет одного языка. Можно применить Express.js на стороне сервера, полностью собрать проект на JavaScript-стеке – такой код может поддерживать большинство фронтендеров.
За счет этого стека можно тонко настроить приложение под задачу, добавляя и удаляя компоненты по необходимости. В теории так можно создавать всё: от микросервисов и API до полномасштабных MVC-фреймворков.
Но такая свобода влечет за собой и недостатки:
Все обработчики приходится создавать вручную, тестировать каждый по отдельности.
Из-за высокой гибкости может вырасти порог вхождения в проект – за счет разных конфигураций и настроек кода разработчикам нужно больше времени на внедрение. Чтобы справиться с этой проблемой, можно взять фреймворк Nest, который дает высокий уровень абстракции и предоставляет готовую архитектуру на старте.
Фреймворк Nest нам не подошел – у него нет интерфейса. Вся команда мыслит визуалом, и работать без интерфейса было не просто.
Бэкенд
Так, вы своего добились – избавились от PHP, начали писать только на JavaScript, нашли гибкие инструменты. Осталось только найти штуку с интерфейсом?
Фронтенд
Как минимум. А вообще команде хотелось бы все тех же широких возможностей, гибкости и простоты в запуске продуктов.
Бэкенд
Сомневаюсь, что вы найдете настолько идеальный вариант.
Попытка №3: Strapi
Что делать с этими недостатками? Понятного ответа на этот вопрос у нас не было, пока мы удачно не наткнулись на Strapi – это бесплатный open-source фреймворк на Node.js, который помогает управлять контентом. Выглядит он так:
Из коробки есть админка, которая позволяет хранить и изменять данные, а еще имеет полный CRUD – возможность создавать, читать, редактировать и удалять записи в базах данных. Рендер основной версии сайта происходит за счет Nuxt – то есть все на фронте.
Здесь мы создаем модель заметок и связанное поле с моделью пользователя. Мы настраиваем связи так, что у юзера есть несколько заметок, но не наоборот. Там же создаются заметки и редактируются. Дальше обращаемся по API с запросом и получаем ответ. Еще можно подключить к Strapi:
Встроенный GraphQL, чтобы запрашивать только необходимые данные.
Плагин Strapi i18n, чтобы продукт поддерживал мультиязычность.
Визуальный редактор Editor.js, чтобы работать с контентом было удобнее.
Swagger, чтобы автоматизировано документировать код.
Strapi подкупает широким выбором плагинов под любые задачи, мультипользовательской авторизацией с JWT-токенами, кастомной логикой, возможностью работать с Nuxt и другими реактивными фреймворками. Продолжать можно долго.
Мы освоили Strapi на практике, перезапуская проект «Помощь». Это приложение благотворительной организации, которая обеспечивает прозрачную помощь пожилым людям.
Мы участвовали как фронтенд-команда – перевели сайт на стек Vue + Strapi. За основу взяли фреймворк Nuxt.js, для хранения данных использовали стейт-менеджер Vuex, который по API получает данные из Strapi.
Бэкенд
Хорошо, что здесь не стали заморачиваться. С первого взгляда вижу, что нагруженный бэкенд здесь не нужен. Если у вас все проекты такие, то задач на полноценную загрузку бекэндеров не будет. Так и быть, соглашусь, что такое решение норм.
Фронтенд
Как здорово, что ты наконец признаешь мои возможности! Кстати, команде тоже нравится так работать – замена бэка фронтом дает кучу возможностей для прокачки навыков.
Да и клиенты рассуждают из бизнес-логики. В конце концов, они заказывают не крутой стек фреймворков или навороченный бэкенд. Они мыслят финальными продуктами: приложение для поиска работы, сайт магазина или благотворительного фонда. На наших технологиях все работает стабильно, все просто в поддержке и дешево. Тогда какая разница, какие технологии под капотом?
Бэкенд
Окей, ты меня убедил, в этом случае и правда лучше без меня. Но иногда бэкенд все-таки нужен…
Фронтенд
Конечно! Погоди, скоро Влад как раз про это расскажет!
Бэкенд не нужен? Не совсем
Из нашего опыта мы сделали такой вывод: если масштаб компании не позволяет растить штатных бэкендеров, можно временно обойтись и без них. Важно подобрать правильные инструменты.
Сейчас мы выстраиваем процессы, ищем клиентов, увеличиваем фронтенд-команду, подбираем новые решения, щупаем спрос на рынке, занимаемся маркетингом. Все идет к тому, что мы станем мультистек-командой – пока не можем себе этого позволить, но хотим.
При этом я не утверждаю, что бэкенд не нужен. Мы небольшая команда разработчиков, которая пока не готова строить внутри себя юнит бэкенда – пришлось научиться закрывать этот этап своими силами. Так мы снизили риски и уровень стресса, научились экономить время и деньги заказчика.
Но есть и ситуации, когда такой подход не сработает. Например, так не построить сложную систему – масштаб не тот. Да и в корпоративных решениях с данными пользователей я бы так делать не советовал. Если вы работаете с огромными объемами чувствительных данных, все таки лучше обратиться к бэкенд-команде – риск слить данные пользователей слишком велик.
Заключение
Чтобы вам было проще применять наш опыт у себя в компании, собрал самые важные мысли из статьи:
Есть три способа работать с бэкендом:
Субподрядчики. Это рискованно, ведь мы не можем влиять на результат, но несем ответственность за него. Еще с подрядчиками сложно общаться, на это уходит время и деньги клиентов.
Штатные сотрудники. Это довольно дорого и связано с рисками слить данные клиентов. Еще проверьте, есть ли у вас стабильный поток задач для бэкендеров. Если нет, команда бэкенда будет простаивать.
Реализация бэкенда инструментами фронтенда. Это дешево, быстро и удобно, но подходит далеко не для каждого проекта.
Если вы решили делать фронт без бэка, можно выбрать такие технологии:
Laravel + Inertia.js. Они позволяют работать на стеке Vue.js/React/Svelte. Но есть и минусы: придется осваивать и использовать PHP, плюс придумывать решение по админке (из коробки ее нет).
Express.js и Nest.js. Это самая гибкая и универсальная история для бэка, которая подойдет под любой проект. Еще с этим стеком можно работать только на JavaScript и интегрировать разные сервисы (например, huntflow+webflow). Из минусов: нет интерфейса и не всегда низкий порог вхождения.
Strapi – это бесплатный open-source фреймворк на Node.js, который помогает управлять контентом. К нему можно подключить кучу разных плагинов, можно работать с Nuxt и другими реактивными фреймворками, писать кастомную логику и многое другое. Подходит для быстрых запусков, но сложные проекты этот стек не потянет.
Эти технологии подходят для многих проектов, но точно не стоит делать на них сложные системы с большими объемами чувствительных данных, чтобы не слить персональную информацию пользователей.
На этом я заканчиваю разговор по душам с фронтендом, бэкендом и вами! Я поделился нашим опытом и надеюсь, что мой рассказ поможет вам преисполниться в понимании возможностей фронтендеров и, возможно, решиться на расширение стека.
Знаю, что разные команды подобные задачи закрывают по-разному. Так что если хочется поделиться своими наблюдениями и подискутировать, тру это или не тру – жду вас в своем телеграме или пишите свои мысли здесь, всем отвечу.
