Пару секунд и готово, как апи перестало быть рутиной
Работа с API во многих проектах быстро превращается из простой рутины в сложный процесс. Хотя по идее API-слой должен быть обычным shared-модулем: подключил, импортировал функцию и используешь.Но чтобы к этому прийти, важно не начинать сразу с кода.
Контракт важнее хаоса - если у вас REST API, я крайне рекомендую подход contract first. Намного проще работать, когда есть артефакт — например, OpenAPI-схема. Если бэкенд по какой-то причине ее не делает, лучше составить схему самим и работать от нее. Так вы лучше понимаете API, быстрее находите проблемы и помогаете не только себе, но и серверной стороне.
API не должен быть ядерным коллайдером - плохой признак — когда для добавления одного нового запроса нужно изменить код в 5–10 местах, чтобы всё “завязалось”. API-слой должен ощущаться как библиотека: поставил, вызвал нужный метод, получил типы, обработал результат. Это низкий и рутинный уровень абстракции, а значит его нужно автоматизировать.
В итоге мы с командой пришли к своему решению — apicraft. Раньше мы использовали orval и heyapi, но со временем уперлись в ограничения масштабируемости и гибкости. Нам хотелось полноценно использовать наши инструменты: fetches, axios, ofetch, tanstack query, faker и другие.
Теперь мы просто описываем или берем готовую схему, запускаем генерацию и за пару секунд получаем весь необходимый код. Это уже сэкономило нам десятки часов на рутинных вещах, а сам проект продолжает развиваться. Надеюсь, совсем скоро сможем показать новые плагины и больше реальных кейсов.
Работа с API во многих проектах быстро превращается из простой рутины в сложный процесс. Хотя по идее API-слой должен быть обычным shared-модулем: подключил, импортировал функцию и используешь.Но чтобы к этому прийти, важно не начинать сразу с кода.
Контракт важнее хаоса - если у вас REST API, я крайне рекомендую подход contract first. Намного проще работать, когда есть артефакт — например, OpenAPI-схема. Если бэкенд по какой-то причине ее не делает, лучше составить схему самим и работать от нее. Так вы лучше понимаете API, быстрее находите проблемы и помогаете не только себе, но и серверной стороне.
API не должен быть ядерным коллайдером - плохой признак — когда для добавления одного нового запроса нужно изменить код в 5–10 местах, чтобы всё “завязалось”. API-слой должен ощущаться как библиотека: поставил, вызвал нужный метод, получил типы, обработал результат. Это низкий и рутинный уровень абстракции, а значит его нужно автоматизировать.
В итоге мы с командой пришли к своему решению — apicraft. Раньше мы использовали orval и heyapi, но со временем уперлись в ограничения масштабируемости и гибкости. Нам хотелось полноценно использовать наши инструменты: fetches, axios, ofetch, tanstack query, faker и другие.
Теперь мы просто описываем или берем готовую схему, запускаем генерацию и за пару секунд получаем весь необходимый код. Это уже сэкономило нам десятки часов на рутинных вещах, а сам проект продолжает развиваться. Надеюсь, совсем скоро сможем показать новые плагины и больше реальных кейсов.
