Я работаю над проектом, использующим одну схему GraphQL для предоставления данных из API REST различным клиентам.Дизайн схемы «принадлежит» внешним командам и имеет форму представления юниверса таким, каким они его видят.Это аккуратно отделяет пользовательский интерфейс от уровня API и работает довольно хорошо.Некоторые (плохо разработанные, но необходимые) API-интерфейсы являются относительно сложными и требуют знания предметной области (иначе говоря, бизнес-логики), чтобы объединить данные в форму, которая сопоставляется со схемой пользовательского интерфейса, но эта бизнес-логика меняется, так как унаследованные API разобраны и переписаны- поэтому проблема состоит из двух частей:
- У нас есть нежелательная бизнес-логика в средствах разрешения, которые заполняют ответы на запросы GraphQL
- Когда команда API создает новую версию своего сервиса и хочет ееЧтобы быть вызванным, команда пользовательского интерфейса не обязательно готова обновить свои средства распознавания, чтобы вызывать его
. Я рассматриваю возможность представить второй экземпляр GraphQL, который действует как модель предметной области, которая будет принадлежать командам API.и абстрагирует детали того, как вызывать каждый API, и составляет необработанные данные, которые будут использоваться схемой пользовательского интерфейса.Это приводит к небольшому снижению производительности, но, с другой стороны, отделяет Схему от деталей реализации API.
При исследовании этого подхода я не нашел примеров того, как в других местах предпринимались попытки, поэтому задавался вопросом, пропустил ли ялюбой, или если это представляет анти-образец, которого следует избегать?