На каком языке должны разговаривать бэкенд- и фронтенд-разработчики в команде? С чего начать разработку, когда дизайн вашего приложения готов? Кто должен проектировать API и модель данных: бэкенд или фронтенд?
Данная статья — это презентация идеи и прототипа решения для проектирования API — API Projector с элементами дискуссии — из серии, «а надо ли?», «очередной велосипед?» и т.д.
Как подружить бэкенд- и фронтенд-разработчиков в вашей команде
На каком языке должны разговаривать бэкенд- и фронтенд-разработчики в команде? С чего начать разработку, когда дизайн вашего приложения готов? Кто должен проектировать API и модель данных: бэкенд или фронтенд?
Данная статья — это презентация идеи и прототипа решения для проектирования API — API Projector с элементами дискуссии — из серии, «а надо ли?», «очередной велосипед?» и т.д.
Фронтенду нужен API
Дизайнер нарисовал макеты будущего продукта и сделал прототип. Заказчик сказал — погнали! Что происходит дальше? Самое лучшее — спросить у тех, кто профессионально занимается разработкой 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.
API Projector
Фронтенд разработчики загружают экраны дизайна из Figma
Далее для каждого экрана разработчики могут выделить области, которым требуется вызов API. Они понимают, какие данные им нужно отобразить в данной части интерфейса: из какой модели и какие поля.
И, собственно, далее можно либо выбрать уже готовые API из библиотеки или создать новые API в «swagger подобном» редакторе.
Основная киллер-фича 😎 нашего решения: связь дизайна и API. Мы всегда знаем, какие API и модели в каких частях интерфейса используются.
На выходе мы получаем всеми знакомый Swagger, на основе которого уже можем генерировать наброски кода на бекенд.
Какие еще фичи можно получить в итоге, если всё проектирование и будущая поддержка требований к API ведется в API Projector:
Ревью API перед реализацией архитектором системы.
Совместная работа над проектированием API множеством разработчиков.
Версионность изменений: кто и когда что-то менял.
Валидация API: забираем swagger с работающей системы и сравниваем со спецификацией. Бам 🤛: такого-то поля не хватает, оно не такого типа, и т.д.
Можно вас «покастдевить»? Что скажете? «Велосипед» или реально решающий боль продукт?
Мы быстро накидали лендинг и Figma-прототип. Будем очень признательны за Вашу обратную связь. Спасибо 🙌