Comments 16
Долгое основательное вступление, к нему ожидались поучительные примеры из жизни, но нет, опять в другой раз. Сама то идея понятна и привлекательна. Хочется узнать реальный опыт, вот собрали OpenAPI схему, утвердили, положили в репозиторий, таким-то инструментом нагенерили моки, оживили их, фронтэндеры пользуются. Потом прилетела правка, обновили схему. Что-то ещё надо сделать? Насколько гладко и безболезненно проходят правки? В моей практике есть задачи, где такие правки неоднократные, хотя и мелкие.
Долгое основательное вступление, к нему ожидались поучительные примеры из жизни, но нет, опять в другой раз. Сама то идея понятна и привлекательна. Хочется узнать реальный опыт
Понимаю, данную публикацию изначально планировал на "entry" уровне, просто как призыв к действию и краткий обзор имеющихся инструментов. Про опыт конкретных реализаций наверное в следующих публикациях расскажу, благо он есть.
собрали OpenAPI схему, утвердили, положили в репозиторий, таким-то инструментом нагенерили моки, оживили их, фронтэндеры пользуются. Потом прилетела правка, обновили схему. Что-то ещё надо сделать? Насколько гладко и безболезненно проходят правки?
Если правки не меняют логику работы клиентского приложения, а только касаются формата API, то изменения гладко проходят. Используем что-то типа паттерна "Адаптер", который на вход принимает схему данных приходящую из api, а на выходе отдаёт схему данных необходимую для построения UI (её можно даже просто видя макет определить). Соответственно, если макеты не менялись то на выходе адаптер отдаёт всегда одно и тоже, и при небольших правках в api, мы просто учим адаптер работать с новыми входящими данными. Выглядит это обычно как правки в пару строк в одном файле, то есть безболезненно. Особенно если у вас моки автоматом генерятся.
Postman в нынешнее время - незаменимый инструмент, и не только для бэкенд разработчиков с тестировщиками.
Postman это ненасытный монстр, который нас всех проглотит;) Так ли уж незаменим? Если не секрет, как вы коллекции храните и распространяете? Возможно, есть платная подписка. Меня смущает привязка к облаку и возможность блокировки. Больше нравится примеры запросов хранить текстом в репозитории, в виде файлов, как это делают httpYac или Bruno.
А мок сервер наверняка можно отдельно поднять, из OpenAPI-схемы. Такой подход видится более гибким и надёжным.
Меня смущает привязка к облаку и возможность блокировки
А кто Вам мешает в Postman сохранять коллекции у себя локально на компьютере?
У него есть такая возможность.
В таком варианте Вы не зависите ни от каких подписок и никто Вам ничего не сможет заблокировать.
В статье речь о командной работе. Как вы предлагаете синхронизировать коллекции, ведь правки наверняка будет вносить не только лишь один избранный?
Насчёт блокировки и нормальной работы без облачной учётки - у вас наверное какой-то особый Постман.
Под Линуксом даже коллекцию открыть нельзя без входа
У меня обычный Postman, скачанный с сайта производителя.
Замечательно работает в локальном режиме без всяких облаков. Единственный момент - я использую версию 9.31, т.к. начиная с 10-й стали просить деньги за запуск коллекции по Run больше чем 25 раз, а мне по работе эта возможность постоянно требуется.
Возможно, что в новых версиях еще добавили разных ограничений.
Можно на картинке увидеть доказательство: "Working locally" :)
А чем плоха просто папка с json файлами ответов, которые возвращаются в апи методах вместо fetch к серверу, с задержкой, и которую можно использовать в тестах, не поднимая никаких серверов?
Использую на работе MSW, с всеми задачами справляется, все покрывает. Но было интересно почитать про другие инструменты, спасибо
Мы с msw перелезли на Mockoon. Очень удобно, все с gui и интуитивно понятно. Не нужно читать доку. Локальные данные можно хранить прямо в проекте в Гите. Есть образ для запуска на стенде. Как вариант есть ещё Charles, но это по хардкору и больше для тестировщиков.
Для себя я понял следующее:
Каждый из подобных инструментов требует изучения его документации перед началом работы. Это занимает время...
Каждый из подобных инструментов имеет ограничения, с которыми неминуемо сталкиваешься, если ваш проект имеет хоть какую-то сложность. Преодоление этих ограничений выливается в тот ещё геморрой. Это занимает время...
Как и писалось в статье, иногда это дополнительные зависимости в проекте.
А что если не замусоривать проект лишними зависимости и всё сэкономленное время потратить на разработку своего мини-сервера на каком-то языке, который имеет все нужные инструменты в стандартной библиотеке, плюс очень простой, плюс весь сервер компилируется только лишь в один бинарник, не требующий никаких внешних рантаймов типа ноды или питона?
Таким решением является Go. За полчаса можно собрать вебсервер, отвечающий нужными джесончиками, скомпилировать его, и запускать этот бинарник откуда угодно
Обычно когда сталкиваемся с такой проблемой, то имея на руках понятное ТЗ и хотя бы примерное описание API - начинаем заранее закладывать тест кейсы по тому как пошагово будут работать различные сценарии по фиче. А по тест кейсам начинаем писать автотесты (естественно на моках) одновременно с написанием реализации задач.
С таким подходом можно практически весь фронтенд писать наперед без зависимости от бэкенда. НО! Тут важно понимать, что в 99% случаев что-то в API может поменяться после фактической реализации бэкендом и правильно это все планировать. Условно если рабочий API появляется тогда, когда уже больше половины фронта готово - то нужно закладывать еще какой-то процент человекочасов на потенциальные проблемы.
Так что писать фронтенд без API однозначно можно, но дороже.
То, что после появления рабочего API зачастую необходимо выполнить пару правок на фронте - это частая история, да. Хотя и можно это дело минимизировать при желании. Однако "дороже" это только в тех случаях когда: а) есть уверенность что разработка после выкатки рабочего API будет вестись не в спех, и время на фронтовую задачу будет выделено достаточно. Так как фронтовая часть работ чаще всего выполняется последняя, то любые сдвиги по срокам на предыдущих этапах отражаются на ней; б) нет ситуации что возникает "простой" и разработчикам есть чем себя занять;
Вам не нужно готовое API чтобы начать писать фронтенд или краткий обзор готовых решений для мокинга данных