Как мы используем стабы “прямо на фронте”

У многих разработчиков на проектах возникает ситуация, когда фронтенд и бекенд разрабатывается параллельно. На бекенде в таком случае проблем с разработкой и тестированием возникает меньше, так как существует curl. Фронтенд разработчики же используют различные mock сервисы.

Аналогичная задача была и у нас, тогда мы оценили несколько вариантов и пришли к решению, что можно использовать стабы прямо на фронтенде, без реальных ajax запросов. Об этом я кратко рассказывал на SPA meetup в Avito, который проходил 8 апреля:

После блиц-доклада, я пообщался с разработчиками и решил написать немного подробнее, как реализовать данный подход.

Решение “стабить на фронте” успешно применяется у нас в течение года. Прежде чем перейти к реализации подобного сервиса, я немного опишу наш проект. Он доступен по адресу https://test.hh.ru, и представляет собой SPA, написанное на React-Redux на фронте и Java на бекенде. Первый ответ Java приложения — это html пустой страницы, содержащий тег script, который определяет данные на этой странице в формате JSON. Данные загружаем вместе с html, потому что не хотим делать дополнительный лишний запрос с фронта. После первой загрузки все общение происходит по Ajax запросам. Данные клиент получает в JSON. Более подробно о том, как работает наш сервис, я описывал в лонгриде на хабре https://habrahabr.ru/company/hh/blog/310524/ (с тех пор мы переехали на axios).

Как это работает

На текущий момент мы используем redux-thunk middleware (но планируем отказаться от него в пользу ajax запросов на middleware уровне). Типичный action creator выглядит следующим образом:

Предположим, что мы только пишем возможность загрузки вакансий, и нам нужно застабить это поведение.

Для начала, мы не используем напрямую axios, а инкапсулируем его в свой класс, тем самым мы можем декорировать методы axios (здесь и далее буду приводить упрощенные примеры кода, для понимания идеи):

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

Теперь наш типичный action creator выглядит следующим образом:

Как устроен стаб внутри?

Сам стаб — это функция, которая реквайрит json файл с данными. Эти функции подключаются в конфиге стабов, представляющем собой обычный массив. В нем мы включаем-отключаем нужные стабы. Чтобы эмулировать ответ, аналогичный серверу, мы создали функцию, которая оборачивает ответ в window.Response объект. Упрощенно, это выглядит следующим образом:

Написание подобного модуля не занимает много времени, а добавление и работа с конфигом максимально проста.

Что дают стабы для фронта?

1. Легко изменять конфиг, стабить новые урлы, обрабатывать входящие параметры. Изменения доступны по обновлению страницы.
2. Посредством конфига можно проверять любые edge кейсы, быстро исследовать поведение приложения при некорректных или покарапченных данных.
3. Не нужно перезапускать сервис для применения стабов.
4. Не нужно усложнять архитектуру взаимодействия на бекенде (если создавать мок сервис, то нужно, чтобы запрос вначале шел на этот мок сервис, если нет нужного стаба, то проксировать запрос на бекенд, что делать не хочется).

За год использования данное решение хорошо зарекомендовало себя в наших задачах и не претерпело радикальных изменений, что говорит об удобстве такого подхода.