Как подружить бэкенд- и фронтенд-разработчиков в вашей команде

На каком языке должны разговаривать бэкенд- и фронтенд-разработчики в команде? С чего начать разработку, когда дизайн вашего приложения готов? Кто должен проектировать API и модель данных: бэкенд или фронтенд?

Данная статья — это презентация идеи и прототипа решения для проектирования API — API Projector с элементами дискуссии — из серии, «а надо ли?», «очередной велосипед?» и т.д.

Дизайнер нарисовал макеты будущего продукта и сделал прототип. Заказчик сказал — погнали! Что происходит дальше? Самое лучшее — спросить у тех, кто профессионально занимается разработкой IT-систем.

Для первого «кастдева» я поехал к друзьям из студии Гарпикс.

В ходе обсуждения определили:

Боль 1: эффективно передать требования к API от фронтенд на бекенд.

Как фронтенд разработчикам сказать бекенд разработчикам, какие API и данные им нужны, чтобы реализовать дизайн интерфейса?

Боль 2: совместное проектирование API фронтенд и бекенд разработчиками с проверкой архитектором системы.

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

Боль 3: узнавать об изменениях API на работающей системе.

Бывают проекты, где у клиента уже есть API, и задача написать только мобильный или WEB фронтенд. Клиент может менять API в любое время без уведомлений, как результат — приложение функционирует неправильно и фронтенд разработчики тратят много времени на поиски причины багов.

Боль 4: соединить существующий API с новым дизайном.

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

Боль 5: управление изменениями в требованиях к API.

API уже реализовано, но пришли новые требования. Как понять что нужно добавить в API? И как потом это передать в виде задач на бекенд?

Как решаются эти проблемы сейчас?

Полностью — никак, лишь частично👇

Фронтенд и бекенд разработчики садятся рядом и накидывают код API в блокноте, wiki или JIRA тикете в тексте или JSON → потом поддерживать это нереально.

Фронтенд разработчики пишут Swagger и передают его на бэкэнд → очень трудоемко и по мере того как разрастается API поддерживать его все сложнее.

Бекенд разработчики сами накидывают API как его видят → часть API и данных пропускается.

После обсуждений мы попробовали набросать интерфейс будущего решения. Логичнее всего было взять уже что-то знакомое и распространенное — Swagger и улучшить это.

В результате получилось решение под названием — API Projector.

Фронтенд разработчики загружают экраны дизайна из Figma

Далее для каждого экрана разработчики могут выделить области, которым требуется вызов API. Они понимают, какие данные им нужно отобразить в данной части интерфейса: из какой модели и какие поля.

И, собственно, далее можно либо выбрать уже готовые API из библиотеки или создать новые API в «swagger подобном» редакторе.

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

Какие еще фичи можно получить в итоге, если всё проектирование и будущая поддержка требований к API ведется в API Projector:

• Ревью API перед реализацией архитектором системы.
• Совместная работа над проектированием API множеством разработчиков.
• Версионность изменений: кто и когда что-то менял.
• Валидация API: забираем swagger с работающей системы и сравниваем со спецификацией. Бам 🤛: такого-то поля не хватает, оно не такого типа, и т.д.

Можно вас «покастдевить»? Что скажете? «Велосипед» или реально решающий боль продукт?

Мы быстро накидали лендинг и Figma-прототип. Будем очень признательны за Вашу обратную связь. Спасибо 🙌