Статья из серии "2х минутные заметки разработчика".  Очень часто перед запуском нового веб-проекта все разработчики начинают писать код одновременно, а это значит, что готового API для фронтенда нет. В данном случае разработчики выходят из этой ситуации, создавая свой фейковый API, чтобы не сидеть сложа руки. И конечно, для этих нужд существует огромное количество инструментов. Одним из самых удобных является json-server. Основная концепция этого пакета очень проста. Мы должны создать файл JSON со структурой всех сущностей, которые необходимы в нашем приложении. Затем мы просто запускаем следующий код и получаем REST API в одну строку кода. Мы можем фетчить данные с помощью GET-запросов (или видеть их просто в браузере, открыв соответствующий урл) и записывать новые элементы напрямую в JSON с помощью POST-запросов. Но есть один недостаток. Если над проектом работает более одного разработчика, то, скорее всего, каждый захочет использовать такой JSON по-своему. Поэтому содержимое такого JSON будет постоянно меняться, что будет приводить к постоянным конфликтам, что в свою очередь потребует времени на их разрешение. Никто не хочет резолвить конфликты в файлах, которые потом вообще не понадобятся. Поэтому есть смысл добавить такой файл в .gitignore. Чтобы каждый разработчик работал со своей версией БД. Избавляясь от одной проблемы, мы натыкаемся на другую. Что теперь делать, если придет новый разработчик? ему нужно самому пополнять базу данных; ему необходимо знать набор полей для каждой сущности, чтобы приложение могло адекватно их обрабатывать. Все это опять приводит к трате времени на общение и пересылку файлов в мессенджерах. Поэтому нам нужен посредник, который сделает все это за нас. Сразу приходит на ум какой-нибудь аналог faker.js. Мы один раз напишем скрипт, который создаст для нас базу данных и потом каждый разработчик сможет ее использовать. Этот способ будет работать, но это еще один элемент, который нужно поддерживать. Нам нужно будет поддерживать его в актуальном состоянии.  А если настраиваемые поля не требуются или бэкенд-часть почти готова, то можно делегировать создание этой БД другому сервису. Например, FakeStoreAPI. Я нахожу этот подход очень удобным: разработчики не тратят время на создание и обслуживание своей базы данных; разработчики по-прежнему могут изменять и добавлять новые объекты через фейковый API; ни одно из этих изменений не влияет на других разработчиков, нет необходимости разрешать конфликты. Но тогда вы спросите «как модифицировать данные на удаленном сервере без прав на запись?». Все просто, нам не нужно. У нас все еще работает наш локальный JSON сервер, который позволяет нам записывать объекты в наш локальный файл JSON. Нам просто нужно перенаправить запросы на чтение. Для этого есть механизм middleware из документации JSON сервера. Мы можем использовать для таких целей пакет http-proxy-middleware, а затем просто создать файл proxy.js. Перезапустить сервер со следующими аргументами: И вуаля. Удаленная база данных нам сразу доступна, а если нам потребуется создать новую сущность, то она будет создана локально. Например, мы можем получать товары из удаленной базы данных, но мы также можем создать корзину или заказ локально. Оригинальная заметка из блога здесь.  Frontend Engineer