Потому что процветающая экосистема GraphQL не может быть построена на закрытых проприетарных решениях от одного поставщика.
GraphQL хорош тем, что он действительно отделяет интерфейс от серверной части, позволяя разработчикам сосредоточиться на потребностях данных, не привязываясь к специфике базовых API… или необходимости быть всезнающими в отношении того, какой микросервис необходимо использовать для какой части данные.
Весь этот подход «единый, унифицированный уровень API для получения данных из всех ваших микросервисов» идеально подходит для предприятий, которые не только хотят получить операционные преимущества независимых команд с общим контрактом, но и создать корпоративный «пул данных», который всекоманды могут создавать новые функции и адаптироваться к изменениям в бизнесе и изменяющимся требованиям клиентов.
Но такая распределенная настройка GraphQL сопряжена со сложностями. Сшивка схем имеет низкий входной барьер, но требует большого количества ручной работы по объединению различных графиков. С другой стороны, Federation — это более масштабируемый и компонуемый подход, который способствует лучшему сотрудничеству между сервисными командами… но это закрытое проприетарное решение, принадлежащее Apollo (Federation V2 начиналась как MIT, затем перешла на лицензию Elastic V2, которая OSI не считает open-source).
Это подводит нас к тому, о чем я хочу поговорить сегодня. Как построить бизнес на основе распределенного GraphQL, если вы постоянно привязаны к экосистеме одного поставщика?
Пришло время Открытой федерации — совместной работы WunderGraph и The Guild по созданию надлежащей спецификации для федеративного GraphQL, которая действительно бесплатна и имеет открытый исходный код под лицензией MIT.
Как мы сюда попали: Краткая история Федерации
С появлением архитектур на основе микросервисов компании начали разбивать большие монолитные приложения на более мелкие, независимо развертываемые сервисы, каждый из которых ориентирован на конкретные бизнес-возможности и раскрывает свою собственную схему GraphQL. Чтобы преуспеть в этой среде, GraphQL должен был выйти за рамки простогибкости и эффективности; ему пришлось решать проблемы управления распределенными данными и схемами.
TL;DR: Нам нужно было объединить типы и запросы из различных сервисов GraphQL в единую схему — и поэтому сшивание схем органично развилось как массовое решение этой конкретной проблемы композиции. С его помощью разработчики могли создать сервер шлюза, объединяющий несколько схем GraphQL — каждая из которых является службой, и каждая полностью независима и не знает о сшивке.
Это имело свои ограничения. Если в двух схемах определялись типы с одинаковым именем, это приводило к конфликтам, которые разработчикам приходилось исправлять вручную, либо путем присвоения псевдонимов типам, либо с помощью пользовательских преобразователей. Что еще более важно, сшивка не имела стандартизированного способа для служб объявить, как они могут быть составлены вместе, и не предлагала встроенной поддержки для разделения одной входящей операции на одну или несколько операций (и упорядочивания их выполнение), каждое из которых разрешимо с помощью одного подграфа. Всю эту работу вам пришлось проделать вручную на уровне шлюза.
Признавая эти недостатки, Apollo работал над Apollo Federation, открыв исходный код в 2019 году. Целью проекта было предоставление более надежного и стандартизированного решения проблемы создания федеративных API-интерфейсов GraphQL.
Федерация представила процесс планирования запросов, который позволил серверу шлюза (маршрутизатору) разложить запрос и направить его части в соответствующие службы, повышая эффективность запросов и уменьшая избыточную выборку. Также существует осведомленность о сервисах — каждый сервис может объявлять свои возможности и отношения с другими сервисами, используя специальный синтаксис SDL (язык определения схемы). Это облегчило понимание того, как сервисы сочетаются друг с другом в федеративном графе.
Он также представил концепцию типов сущностей, представляющих основные бизнес-сущности — ресурсы, если хотите, — которые могут быть разделены между службами. Это позволило сервисам самим объявлять, на какие типы они могут ссылаться или даже расширять… и если бы эти ресурсы могли иметь совместное владение, это означало бы лучшее сотрудничество между командами, в отличие от строго разделенного характера сшивания схем.
Федерация была новой революционной технологией, полностью отличавшейся от всего, что у нас было до сих пор. Он предлагал стандартизированный подход к составлению схемы, планированию запросов и осведомленности об услугах. Федерация, как ничто до нее, позволяет организациям уверенно создавать, масштабировать и поддерживать сложные, составные API, которые легко интегрируют данные из нескольких источников, что позволяет им адаптироваться, развиваться и расти.
Но затем она перешла на лицензию Elastic V2.
Это подводит нас к сегодняшнему дню, когда ландшафт GraphQL находится в идеальном переломном моменте. Спрос на интегрированные архитектуры GraphQL постоянно высок — все больше и больше компаний хотят иметь унифицированный интерфейс для своих разнородных бэкэндов (REST, GraphQL, gRPC, Kafka/AsyncAPI и т. д.) для создания общекорпоративных пулов данных для органического роста и адаптивность — но Apollo Federation недостаточно для удовлетворения этих потребностей из-за сочетания технической двусмысленности ее спецификации и, что особенно важно, ее лицензирования.
Очевидно, что сообществу GraphQL нужно альтернативное решение. Тот, который не принадлежит ни одному поставщику.
Откройте для себя Open Federation — по-настоящему бесплатный подход с открытым исходным кодом, который не только устраняет эти ограничения, но и отстаивает принципы открытости, доступности, расширяемости и сотрудничества. Давайте посмотрим на Open Federation и на то, как она изменит будущее федеративного GraphQL.
Представляем Открытую Федерацию
Это замена Apollo Federation, которая позволяет любому поставщику реализовать (или расширить) ее для собственных федеративных решений GraphQL и внести свой вклад в создание более здоровой и разнообразной экосистемы GraphQL. Walmart, SAP, Tripadvisor, Neo4j, Tailor.tech и многие другие компании заявили о своей поддержке.
Цель Open Federation — стандартизировать сам процесс федерации — все, от основных концепций подграфов и объединенных графов до директив, которые их определяют, до алгоритмов, необходимых для планирования и выполнения запросов, и в целом всего, что связано с объединение (и проверка) подграфов в составной объединенный граф — и лицензирование всего этого в рамках MIT.
Он призван заложить глубокое, каноническое понимание федеративного GraphQL и служить источником истины и основой для совместной работы для всех, кто хочет реализовать федеративные API — или расширить спецификацию по своему усмотрению.
Идея состоит в том, чтобы способствовать открытости, облегчая компаниям внедрение федеративного GraphQL, работу над ним и добавление своих знаний в базу — все это в конечном итоге приводит к инновациям в экосистеме GraphQL, которых до сих пор не было с помощью Apollo. экосистема одного поставщика.
Три принципа открытой федерации
1. Настоящая техническая спецификация
Одна из самых больших технических проблем со спецификацией Apollo’s Federation V2 заключается в том, что она слишком расплывчата. Все, что там говорится, это то, что в ваши схемы подграфов необходимо внести ряд дополнений, чтобы они были совместимы со шлюзом федерации.
Чтобы быть частью интегрированного графа, реализующий сервис должен соответствовать спецификации Apollo Federation, которая предоставляет возможности сервиса шлюзу, а также таким инструментам, как Apollo Studio.
# ⚠️ This definition must be created dynamically! The union
# must include every object type in the schema that uses
# the @key directive (i.e., all federated entities).
union _Entity
scalar _Any
scalar FieldSet
scalar link__Import
scalar federation__Scope
enum link__Purpose {
"""
`SECURITY` features provide metadata necessary to securely resolve fields.
"""
SECURITY
"""
`EXECUTION` features provide metadata necessary for operation execution.
"""
EXECUTION
}
type _Service {
sdl: String!
}
extend type Query {
_entities(representations: [_Any!]!): [_Entity]!
_service: _Service!
}
directive @external on FIELD_DEFINITION | OBJECT
directive @requires(fields: FieldSet!) on FIELD_DEFINITION
directive @provides(fields: FieldSet!) on FIELD_DEFINITION
directive @key(fields: FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE
directive @link(url: String!, as: String, for: link__Purpose, import: [link__Import]) repeatable on SCHEMA
directive @shareable repeatable on OBJECT | FIELD_DEFINITION
directive @inaccessible on FIELD_DEFINITION | OBJECT | INTERFACE | UNION | ARGUMENT_DEFINITION | SCALAR | ENUM | ENUM_VALUE | INPUT_OBJECT | INPUT_FIELD_DEFINITION
directive @tag(name: String!) repeatable on FIELD_DEFINITION | INTERFACE | OBJECT | UNION | ARGUMENT_DEFINITION | SCALAR | ENUM | ENUM_VALUE | INPUT_OBJECT | INPUT_FIELD_DEFINITION
directive @override(from: String!) on FIELD_DEFINITION
directive @composeDirective(name: String!) repeatable on SCHEMA
directive @interfaceObject on OBJECT
directive @authenticated on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM
directive @requiresScopes(scopes: [[federation__Scope!]!]!) on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM
# This definition is required only for libraries that don't support
# GraphQL's built-in `extend` keyword
directive @extends on OBJECT | INTERFACE
Все это прекрасно, но… это всего лишь список скаляров и директив, который не дает полной спецификации Federated GraphQL, как это делает традиционный GraphQL для реализации серверов и клиентов GraphQL. Вместо этого это свод правил о том, как структурировать схемы подграфов для совместимости с инструментами Apollo, и ничего больше.
Что, если ваш сервис GraphQL не поддерживает типы, начинающиеся с «_»? Что, если он не поддерживает объединения и/или пользовательские директивы? Ну тогда вам просто не повезло. Официальная спецификация Apollo Federation направлена на облегчение составления схемы с помощью собственного решения (Apollo), а не на предоставление фактического понимания того, что представляют собой отдельные элементы Federation и как они должны работать вместе, чтобы вы могли создавать свои собственные решения или обходные пути.
Open Federation стремится исправить это, определяя и документируя новый стандартизированный подход к федеративному GraphQL. Это означает создание четкой, недвусмысленной, хорошо документированной спецификации (и, что особенно важно, открытие ее для тщательного изучения и проверки сообществом), которая определяет каждую директиву, определяющую подграф или объединенный граф, то, как различные сервисы GraphQL могут сотрудничать и объединять свои схемы, что такое «Шлюз» в интегрированном контексте GraphQL должен означать то, что он должен делать, как он должен маршрутизировать запросы и разлагать один клиентский запрос на подзапросы, каждый из которых может быть разрешен с помощью одного подграфа, как шлюз должен объединять и организовывать данные подзапросов из различные службы в связный ответ и отправку его обратно клиенту, правила проверки составленных графов и многое другое.
Создание этой части канонической базы знаний помогает разработчикам различных проектов и организаций создавать интегрированные API с четко определенным набором правил и практик или их собственную реализацию — шлюзы/маршрутизаторы или собственную расширенную спецификацию в целом — и оптимизировать их для их вариант использования по ходу дела.
2. Взаимодействие с существующей экосистемой
Для роста Open Federation ее реализации должны не только сохранять перекрестную совместимость друг с другом, но и взаимодействовать с существующей экосистемой разработки. Часто это означает поддержку того способа, которым организации де-факто реализовали федеративный GraphQL — Apollo Federation — и все существующие инструменты вокруг него (которые включают в себя потоки CI/CD, реестры схем, утилиты композиции, такие как rover, и совместимые с Федерацией библиотеки подграфов и шлюзы.)
Open Federation признает важность этой экосистемы и стремится улучшить ее, добавив специфичности и устранив двусмысленность, но гарантируя совместимость с уже существующими федеративными архитектурами GraphQL и инструментами разработки.
Это означает, что существующие пользователи Apollo Federation могут использовать Open Federation в качестве полной замены без значительных сбоев или серьезных переписываний. Фактически, любойподграф Федерации Аполлона может быть составлен в граф Открытой Федерации, поскольку последний строится на основе существующих директив, специфичных для федерации, что дополнительно поясняет их.
Внедрение Open Federation предоставляет организациям возможность перейти на решение с полностью открытым исходным кодом, сохранив при этом свои инвестиции в инструменты, рабочие процессы и базы знаний, разработанные на базе Apollo Federation.
3. Расширяемость в будущем
Спецификация Open Federation — это прочная база, которую любой поставщик может расширить для создания новых реализаций интегрированного GraphQL или вообще новых спецификаций.
Например, если вы являетесь платформой электронной коммерции, вам понадобится федеративный шлюз для обработки больших объемов одновременных запросов даже во время пикового трафика. Rust — это язык, который обеспечивает безопасность памяти и низкоуровневый контроль, поэтому ваш шлюз может использовать его для реализации спецификации Open Federation, модифицированной и оптимизированной для вашего конкретного случая использования.
Что, если вашим подграфам нужна библиотека аутентификации, состоящая только из NodeJS? Нет проблем, ваш шлюз может быть написан на NodeJS и при этом соответствовать спецификации Open Federation. Теперь ваша реализация специально создана для совместимости с более широкой экосистемой JS.
Интегрированная спецификация GraphQL никогда не должна мешать вам работать с самим GraphQL.
Прекрасным примером открытой экосистемы, которую продвигает Open Federation, является GraphQL Fusion — совместная работа ChilliCream, The Guild, Hasura, IBM, Solo.io, AWS AppSync и WunderGraph — которая была создана для решения проблем организаций. опираясь на множество внутренних и внешних служб данных, которые не являются толькоGraphQL. Он выходит за рамки возможностей традиционного интегрированного GraphQL и охватывает разнообразные реальные сценарии корпоративного использования, позволяя им создавать унифицированные API для всех своих данных, одновременно защищая клиента от деталей реализации, которые скрываются. за воротами.
Общие знания порождают инновации
Apollo проделала огромную работу по улучшению экосистемы GraphQL с помощью многочисленных проектов GraphQL с открытым исходным кодом, таких как серверные и клиентские библиотеки Apollo, но нельзя отрицать, что лицензия Elastic в сочетании с присущей спецификации Federation двусмысленностью и отсутствием Надлежащая документация сдерживает широкое распространение интегрированных архитектур GraphQL и препятствует развитию здоровой экосистемы GraphQL для всех.
А здоровая экосистема GraphQL — это именно то, для чего была создана Open Federation. Открытая, общая спецификация, которая не принадлежит и не закрыта какой-либо отдельной компанией, которая приглашает к сотрудничеству и служит основой для нескольких поставщиков для создания услуг, решений и инструментов, что ведет к усилению конкуренции и большему количеству инноваций.
