Как стать автором
Обновить

Эмуляция бэкенда: как разрабатывать изолированный фронтенд с помощью Mock Service Worker

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров11K
Всего голосов 4: ↑4 и ↓0+4
Комментарии17

Комментарии 17

А в чём преимущества использования Service Worker в данном случае? Не проще ли просто подменить реализацию fetch?

Service Worker эмулирует сетевое поведение и абстрагируется от особенностей приложения — библиотек для запросов, среды исполнения и т.д. Каждый перехваченный запрос отображается во вкладке Network как обычный запрос к бэкенду. MSW можно использовать на ноде и мокать, к примеру, SSR-приложения. С решениями, в которых подменяется fetch такой гибкости нет, и вся работа по мокингу остаётся на слое с приложением, что по сути полноценной эмуляцией серверного поведения не является.

Использую Mockoon уже несколько лет. У меня практически на всех проектах нет доступа к серверу с локального компа. Особо нравится, что можно использовать "faker.js" и использовать шаблоны для быстрого создания ответов json. Также можно заранее задать, чтобы иногда появлялись разные ошибки - 404, 500, задержки для проверки спиннеров, и т.д. Ну вообщем настроек там много.

Вот только отдельные мок сервисы ко всему прочему умеют проксировать, записывать ответ и потом уже его использовать. Тут, увы, этого нет.

Не совсем понял, что вы имеете в виду под "записывать ответ"?

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

Так этот Service Worker и применяется когда нет ещё бэка (или до него нельзя из сообралений безопасности достучаться)! А json уже есть (описаны).

Да и чтобы ручками не писать множество json при разработки, можно на "отдельном мок сервисе" получить json какие требуются (там много шаблонов есть, поди) и вставить их в данный Service Worker. - но в данном случае, вести разработку независимо от разработки (сроков) бэкенда- это супер!

Можно ещё дополнительно использовать генераторы фейковых json, например https://fakerjs.dev/. Там много встроенных типов, которые можно дополнительно настроить, чтобы нагенерить то, что нужно. Ну или всегда можно написать самому генерацию под ваши модели данных.

Так и мок сервер может без бэка работать точно так же . Но собрать снапшот с реальными данными без набивки или генерации билеберды сервисворкер уже не может. Менее гибкое получается решение.

Service Worker обеспечивает минимальное вмешательство в код.

Пример. У вас проект. Все стартанули работать и API с бэкендом появляется вовремя. - но часто ли это бывает? Нет.

Обычно стартует к примеру фронтенд, API готов наполовину и меняется каждую неделю. При этом бекенд ещё вовсе не стартовал. Что делать? Можно быстро создать на бекенде тестовые ответы и потом постоянно их править. Что обычно и делают. Но тогда разработка фронтенд зависит от разработки бекенд.

А если вообще у разработчиков фронтенда нет доступа к бакенду?

Service Worker вполне рабочий и удобный инструмент для этого.

А вот при разработке своего pet-проекта, наверняка можно поискать и что-то иное. Как я понял тогда, когда в этом проекте вы хотите показать обработку десятков, а то и сотен близких к реальности json ответов.

Service Worker обеспечивает минимальное вмешательство в код.

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

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

Отдельный моксервер вообще не вносит в проект никаких вмешательств

Не понял. В вашем же коде будет урл на этот тестовый моксервер. Вам надо будет как-то переключаться между тестовым сервером и настоящим же при деплое на продакшен!

Нет никакой прямой зависимости от бэкаэнда.

Да само наличие тестового бэкаэнда и есть зависимость от него. Его надо обслуживать, собирать, развёртывать. Зачем это делать на тестах то? Какая причина то существования тестового бэкаэнда?

А чем плох вариант писать простую реализацию бека используя express и настроить возможность запуска разных вариантов dev сервера. Хочешь на разные стенды, хочешь на локальный бекенд на node js. И возможностей там больше чем просто одать нужный json.

вот плюсую
использовал и MSW и Mirage, но простой сервер на Express/Koa оказался вообще ничем не сложнее в использовании, но при этом гораздо функциональнее. Настроил его как себе нужно, не надо ни в документациях всех этих MSW ковыряться, что-то надо, взял и написал сам.

А чем плох вариант писать простую реализацию бека используя express и настроить возможность запуска разных вариантов dev сервера

А тем что его нужно писать, деплоить, поддерживать, менять - а зачем? - Если фронтенду нужен только урл и данные в json и именно это и обеспечивает Mock Service Worker.

а деплоить зачем? в основном все используют для локальной разработки. Кода писать получилось меньше чем на том же MSW, точно так же ендпоинт описываешь и отдаёшь на клиент. Дополнительно в пару строк добавил проксю на рабочий апи, если по урлу не нашлось замоканных данных. Функционал расширяешь как хочешь по желанию, насколько фантазии хватит. И все это без ковыряний в документациях, так как в основном все фронты от миддлов с экспресс/коа знакомы.

Еще у отдельного сервера плюс, что он как раз-таки не зависимость твоего фронтового приложения, а отдельно собирается и в билде клиентского приложения не участвует. Потому что с MSW мне однажды от безопасников отбивка пришла, что мол он в себе зависимости небезопасные использует, и соответственно все приложение становится небезопасным. Тогда как в своем сервере ты сам зависимости выбираешь.

А еще стоит уточнить, что проект блокирует работу в России как минимум, хотя на сайте нигде это не заявляет. Настроил в своем проекте все как нужно, запустил, получаю ошибку 451, смотрю в ответ, а там "Country not allowed", вот и думайте.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории