Мы — фронтенд-разработчики — постоянно страдаем при работе с АПИ для наших веб-приложений: прежде чем приступить к работе, мы ждем, пока бэкендеры сделают первую версию АПИ, а когда его получаем, оказывается, что половины методов нет, а сама тестовая апишка постоянно критует и отваливается. Кроме этого, при дальнейшем развитии нашего приложения апишка меняется, модель данных получает изменения, давно написанный код внезапно ломается, и мы далеко не сразу узнаем об этих изменениях (иногда уже сильно потом — на продакшене).

Знакомая ситуация?

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

Мы с вами поговорим о том, как организовать разработку фронтед-приложения параллельно с разработкой АПИ, как абстрагироваться от поставщика данных и организовать мокирование, какие принципы позволят быть более дружелюбными к изменениям АПИ, как не переделывать всю бизнес-логику приложения при выпуске новых версий АПИ и как ускорить написание кода, работающего с сетью.

И самое главное — не испортить при этом жизнь вашим бэкендерам =)