С растущим количеством сервисов, создаваемых на нашем бэкэнде, на разработку нашего внешнего интерфейса начало влиять то, сколько репозиториев и серверов вам нужно установить локально, чтобы запустить внешний интерфейс. И если мы также примем во внимание нашу переработку архитектуры интерфейса, мы знали, что должны принять меры, чтобы обеспечить быструю и плавную разработку. Вот тут-то и появляется наш фиктивный сервер монорепозитория.
Немного о LumApps
Если вы не знаете о LumApps, мы являемся глобальной технологической компанией с отделами исследований и разработок во Франции, которая предоставляет нашим клиентам решение SaaS Digital Workplace, которое создает целостное рабочее пространство, интегрированное с несколькими комплектами и инструментами для совместной работы. Хотите узнать о нас немного больше? Зайдите на LumApps.com и посмотрите!
Что нам нужно
Еще пару лет назад наше внешнее приложение было довольно просто запустить в вашей собственной среде разработки, чтобы начать кодирование. Вы выполнили интерфейс и серверную часть, и все! Но поскольку компания и приложение выросли в геометрической прогрессии за последние пару лет, были созданы новые сервисы и пришли новые разработчики для разработки продукт, локальная загрузка приложения была не такой простой, как раньше.
Эти новые сервисы означали, что вам нужно будет настраивать их на своем компьютере, что требует не только времени на настройку, но и много ресурсов ЦП, что создает действительно сложную комбинацию для наших сред разработки. Нам нужна была система, которая позволяла бы:
- Удалите зависимости этих служб для локальной разработки и используйте один сервер, который обслуживал бы данные, необходимые внешнему интерфейсу для локальной разработки, и, таким образом, увеличивая время локальной разработки 🚀
- Создайте набор данных, который все команды могли бы повторно использовать для разработки своих функций. Это означало обмен этими данными между командами и разрешение этим командам создавать свои собственные наборы данных, чтобы удалять/добавлять конфигурацию для каждой конкретной конфигурации команды 🛠
- иметь непротиворечивый набор данных, который можно повторно использовать для модульных и интеграционных тестов ✅
Как мы это сделали
После некоторых исследований мы нашли отличный модуль npm под названием json-server, который позволил нам создать полный поддельный REST API без особых усилий. вообще конфигурация. Это действительно потрясающий инструмент, поскольку он не только позволяет имитировать данные и создавать сервер, но и предоставляет множество базовых функций API из коробки, что делает этот инструмент действительно лучшим следующий уровень, когда дело доходит до насмешек. С его помощью мы могли бы, например, выполнить POST для создания ресурса, и в следующий раз, когда мы выполним GET для получения списка ресурсов, недавно созданный ресурс будет там! Это также позволяет нам создавать промежуточное программное обеспечение Express js, которое можно использовать для настройки запросов и ответов, что дает нам полный доступ для изменения всего, что мы хотим!
Кроме того, мы создали небольшой файл js узла, который позволил нам легко управлять этими фиктивными файлами в монорепозитории. По сути, json-server нуждается в точке входа json, где находятся фиктивные данные, но, поскольку мы используем архитектуру монорепозитория, мы хотели, чтобы каждый пакет имел собственные фиктивные данные, чтобы они являются владельцами этих данных, и, кроме того, это позволяет нам четко видеть конечные точки, которые потребляет пакет. Этот файл узла js представляет собой сценарий, выполняемый перед json-сервером, и он:
- Просматривает каждый из пакетов в нашей рабочей области и ищет файлы с именем api.json в папке _mocks и объединяет их все в один файл со всеми данными из каждого пакета. Он также принимает во внимание другие конфигурации json-сервера, такие как маршруты или промежуточное ПО, и помещает их все вместе в одном месте
- Записывает в предопределенную папку эти объединенные файлы и выполняет json-server с этими файлами в качестве входных данных.
- Все это выполняется с помощью одной команды yarn mocks, которая создает файлы и затем запускает json-сервер.
- Мы также разрешили каждому модулю создавать разные сценарии для своих ответов API, которые мы называем переопределениями. Каждый пакет может создавать любое количество переопределений, которые представляют собой подмножество данных, возвращаемых API, с различными значениями, которые переопределяются и изменяются, чтобы API возвращал другой сценарий. Так, например, наш ответ API для нашей службы уведомлений выглядит так:
Но что, если мы хотим легко запустить фронтенд, где у пользователя вообще нет никаких уведомлений? В этом случае мы создаем переопределение no-notifications.api.json, которое переопределяет этот файл:
На уровне папки наш пакет уведомлений выглядит так:
А для того, чтобы применить эти переопределения, мы просто запускаем yarn mocks -override no-notifications, и наш файл node js будет искать различные переопределения, созданные для каждого пакета с именем no-notifications и глубоко объединить их значения с исходными значениями каждого ответа API. Это также означает, что если есть другие пакеты, которые хотят создать переопределение для сценария без уведомлений, они также могут это сделать! Им просто нужно создать файл с именем no-notifications.api.json в своей папке _mocks.
Наконец, вы также можете применить несколько переопределений одновременно, выполнив моки пряжи -override no-notifications,admin,no-posts. Эти переопределения будут применяться одно за другим, переопределяя каждый ключ в ответах API в указанном порядке.
Что следующее
Нам все еще нужно пройти еще пару сценариев, которые мы хотим решить, чтобы наши разработчики могли иметь более плавный опыт разработки:
- Автоматически создавать макеты из удаленной серверной службы.
- Периодически проверяйте эти макеты на удаленной серверной службе, чтобы убедиться, что ответ API не изменился.
- Откройте исходный код этого небольшого узла js, чтобы те из вас, кто использует монорепозитории и хотят повторно использовать этот код, могли это сделать! Следите за дальнейшими разработками по этой теме!
