Это было интересное приключение.

Сразу оговорюсь: FlexMock не нужен всем подряд. Он вырос из моих собственных задач — когда нужно откуда-то получать разнообразные данные для собеседований, когда фронтенд уже в работе, а бэкенд ещё не готов, или когда нужно быстро собрать демо/прототип и не тратить вечер на мок-сервер.

Это мой первый публичный проект в формате “сделал сам и показываю миру”, без команды и заказа. Ниже расскажу, почему мне захотелось написать такой сервис, как он устроен на уровне идеи и в каких сценариях реально экономит время.

Буду благодарен за конструктивную критику — особенно за идеи, которые помогут сделать инструмент полезнее.

Всё начинается с проблем

Первая мысль о таком проекте пришла ко мне, когда я проводил собеседования. Обычно мы использовали jsonplaceholder.typicode.com или набор статичных JSON-файлов, которые лежали в отдельных репозиториях под конкретные задания. Это работало, но каждый раз хотелось чего-то ближе к реальности: более интересных, связанных между собой данных, которые можно получать по нескольким URL — как в настоящем продукте.

Например, чтобы у кандидата было не просто “список пользователей”, а небольшой живой мир:

GET /users — пользователи

GET /users/{id} — профиль конкретного пользователя

GET /users/{id}/orders — заказы пользователя

GET /orders/{id} — детали заказа

GET /orders/{id}/items — позиции в заказе

GET /products — каталог товаров, на которые ссылаются позиции заказа

С такими данными гораздо проще оценивать навыки, которые реально нужны в работе: нормальная работа с API, пагинация, состояния загрузки, реалистичная задержка обработка ошибок и аккуратная работа со связанными сущностями, а не просто “отрендерить JSON на экран”. Всё это приводит к тому, что оценка становится чеснее.

Решение: визуальный редактор вместо ручных моков

Я хотел, чтобы мок-данные перестали быть отдельной “мини-разработкой” с файлами, репозиториями и вечными правками. Поэтому в FlexMock всё строится вокруг визуального редактора модели: вы собираете структуру ответа мышкой (типы полей, вложенность, обязательность), сразу видите предпросмотр — и за пару минут получаете то, хотели.

В редакторе вы добавляете поля, выбираете типы и настраиваете генерацию реалистичных значений. Главное — не нужно держать в голове формат JSON и следить, чтобы “где-то ещё” не сломалась структура: всё редактируется в одном месте и сразу видно результат.

Дальше вы создаёте “запрос” на основе модели: задаёте, сколько элементов возвращать, при необходимости включаете задержку ответа и пагинацию через limit/offset. После сохранения FlexMock выдаёт публичный URL, который можно сразу подключать в приложение, тесты или выдавать кандидатам на интервью.

Пример того, как это выглядит:

https://reistline.flexmock.com/api/companies?limit=2

https://reistline.flexmock.com/api/companies/bd6fc999-f813-41b6-9c41-da329b922490

В реальных продуктах большинство API-запросов выполняются не “анонимно”: клиент сначала проходит аутентификацию, а затем ходит в эндпоинты с учётными данными (например, токеном). Поэтому в FlexMock можно включить аутентификацию для эндпоинта, чтобы интеграция выглядела и ощущалась как настоящая: клиенту нужно правильно передавать данные для доступа и корректно обрабатывать ситуации, когда он не прошёл проверку.

Планы на будущее

FlexMock уже закрывает мои базовые сценарии для прототипов и интервью, но я хочу довести его до состояния, когда им удобно пользоваться в команде на ежедневной основе. Если у вас есть опыт или идеи — буду рад подсказкам.