Сегодня первый день недели запуска WunderGraph, фактически это наша первая неделя запуска. У нас есть чем поделиться с вами, например Open Federation, Cosmo и многое другое…

Что меня больше всего волнует, так это то, что сегодняшний день знаменует собой начало новой эры для GraphQL. В течение очень долгого времени в экосистеме GraphQL доминировала одна компания. Однако ситуация скоро изменится благодаря двум инициативам и экосистеме, которая возникнет вокруг них.

Первым шагом является Open Federation, спецификация под лицензией MIT для создания федеративных API-интерфейсов GraphQL. Цель Open Federation — дать возможность экосистеме GraphQL создавать интегрированные API-интерфейсы GraphQL без необходимости полагаться на запатентованную технологию Apollo. Это полная замена Apollo Federation, она имеет открытый исходный код и может использоваться всеми бесплатно.

Самое главное, мы анонсируем не только Открытую Федерацию. Open Federation — это совместная работа WunderGraph, Grafbase, Escape Tech, Neo4j, TailorTech, Sibipro, Soundtrack Your Brand, Travelpasses и многих других.

Вторым шагом является GraphQL Fusion, спецификация составных API GraphQL, которая выходит далеко за рамки того, что предлагает Apollo Federation, например, поддержка создания не только API GraphQL, но также REST (OpenAPI), gRPC, AsyncAPI и т. д. GraphQL Fusion будет жить под управлением GraphQL Foundation. Цель Fusion — обеспечить возможность объединения API-интерфейсов GraphQL с разнообразным набором поставщиков и технологий. Fusion — это совместная работа ChilliCream, The Guild, Hasura, IBM, Solo.io, AWS AppSync и WunderGraph. Вместо того, чтобы каждый поставщик создавал свою собственную запатентованную технологию композиции, мы создаем единую спецификацию с открытым исходным кодом, которую может реализовать каждый, чтобы мы все могли работать вместе над созданием лучшей экосистемы GraphQL.

На сегодняшний день мы сосредоточены на Open Federation, но следите за обновлениями, чтобы получить дополнительную информацию о GraphQL Fusion. Подробнее об этом вы обязательно услышите во время GraphQL Conference by the GraphQL Foundation. Мы тоже там будем, так что обязательно поздоровайтесь на нашем стенде.

История Открытой Федерации

Я создатель GraphQL-Go-Tools, библиотеки GraphQL для Go, которую используют многие компании для создания шлюзов GraphQL и других инструментов GraphQL. Я работаю над этой библиотекой уже более 5 лет, и она имела большой успех. Почти 3 года назад я начал добавлять поддержку Apollo Federation в графические инструменты. Как бы я ни был воодушевлен идеей Федерации, сообщество еще не было к ней готово. Я добавил поддержку подписок много лет назад, но спрос на нее был очень низким, поэтому мое внимание сместилось на решение других задач.

Перенесемся в 2023 год, и вдруг все кардинально изменилось. Экосистема GraphQL значительно выросла, и спрос на Federation значительно увеличился. В то же время Apollo начала закрывать свою экосистему с открытым исходным кодом, меняя лицензии, повышая цены и многое другое.

Все это привело к тому, что к нам обратилось множество людей и попросило о помощи. Некоторые из них, такие как TailorTech, даже были готовы спонсировать разработку шлюза, совместимого с Federation v2, и инструментов композиции для графических инструментов. Крупные предприятия очень помогли нам с тестированием или предоставлением схем GraphQL своих объединенных графов для проверки нашей реализации.

Но была проблема, которую нам нужно было решить в первую очередь. Что на самом деле такое Федерация Аполлона?

Что такое на самом деле Федерация Аполлона?

Это может показаться глупым вопросом, но на самом деле это не так. На этом этапе мы все должны иметь некоторое представление о том, что такое Федерация. Но смотрели ли вы когда-нибудь на детали, например на спецификацию?

Вот Спецификация Apollo Federation v2. Это девять Директив и одна Скалярная, вот и все. Никаких комментариев, никаких объяснений, никаких примеров, ничего. Это не что иное, как спецификация, и она фактически оставляет все важные вопросы без ответа.

Например, как на самом деле реализовать шлюз федерации? Что должен делать шлюз? Каковы правила проверки федеративной схемы GraphQL? Как вы на самом деле составляете интегрированные API-интерфейсы GraphQL? Каковы правила проверки совместимости двух или более подграфов?

Для сравнения, спецификация GraphQL очень подробно описывает, как должен вести себя сервер GraphQL. Он содержит многочисленные примеры правил проверки и выполнения, а также описания основных алгоритмов, таких как объединение наборов выбора или выполнение запроса GraphQL.

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

Поэтому мы спросили себя, как мы можем создавать инструменты для составления подграфов и маршрутизатор/шлюз для разрешения федеративных запросов GraphQL, не имея надлежащего описания «нашего понимания» федерации?

Рождение Открытой Федерации

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

С этого момента несколько поставщиков могут реализовать одну и ту же спецификацию, поэтому вы можете выбрать лучшее решение для своего варианта использования. Вы больше не привязаны к одному поставщику, вы можете переключиться на другого поставщика в любое время. Вы даже можете построить свои собственные Врата, если захотите. Кроме того, вы можете предложить улучшения спецификации и реально повлиять на будущее интегрированных API-интерфейсов GraphQL.

Цели Открытой Федерации

Мы не верим, что у проприетарных решений API Composition есть будущее. Очень маловероятно, что один-единственный поставщик решения с закрытым исходным кодом способен предложить рынку наилучшее решение.

В прошлом мы видели обратное с OpenAPI. До появления OpenAPI существовало множество проприетарных решений для описания и управления REST API. Однако OpenAPI стал де-факто стандартом для REST API и поддерживается многими поставщиками и инструментами. Это история большого успеха, которая привела к множеству инноваций в области REST API.

Мы считаем, что Open Federation может оказать аналогичное влияние на экосистему GraphQL. Открытая спецификация сделает интегрированный GraphQL гораздо более доступным и привлекательным для многих компаний и, следовательно, приведет к более широкому внедрению GraphQL в целом. Это, в свою очередь, привлечет больше поставщиков к экосистеме GraphQL, что приведет к большему количеству инноваций и здоровой конкуренции.

В конце концов, в интересах экосистемы GraphQL иметь разнообразный набор поставщиков и технологий. Стандартизируя состав API-интерфейсов GraphQL, поставщики могут сосредоточиться на своих сильных сторонах и совместно разрабатывать дополняющие решения.

Ключом является составная архитектура и совместимость. Различные реализации спецификации могут фокусироваться на разных вариантах использования и технологиях. Один поставщик может сосредоточиться на шлюзе, оптимизированном для производительности с использованием Rust или Go, в то время как другой поставщик может оптимизировать расширяемость, например. написав шлюз в NodeJS.

На этом этапе вам может быть интересно, в чем разница между Открытой федерацией и Федерацией Аполлона?

В чем разница между Открытой Федерацией и Федерацией Аполлона?

Apollo Federation не является полной спецификацией. Это набор директив, которые при правильном использовании в подграфе сделают его совместимым со шлюзом и маршрутизатором Apollo.

Open Federation основывается на тех же директивах для указания подграфов. Это спецификация, подробно описывающая правила составления подграфов, то, как следует планировать и выполнять федеративные запросы GraphQL.

Open Federation можно рассматривать как замену Apollo Federation, просто она более конкретна, имеет открытый исходный код и бесплатна для использования всеми.

Какая связь между Open Federation и GraphQL Fusion?

Для многих случаев использования интегрированных API-интерфейсов GraphQL будет более чем достаточно, и нет причин не принимать или не использовать Open Federation.

Однако будут случаи использования, когда вы захотите создать не только интегрированные API-интерфейсы GraphQL, но также API-интерфейсы REST, API-интерфейсы gRPC, AsyncAPI и т. д. Именно здесь в игру вступает GraphQL Fusion.

"Заключение"

Federated GraphQL — это зрелая технология, которая уже много лет используется в производстве. GraphQL Fusion все еще находится на ранней стадии разработки, и потребуется некоторое время, чтобы достичь того же уровня зрелости.

Мы делаем ставку на обе технологии и считаем, что они будут очень хорошо дополнять друг друга. Время покажет, будут ли обе технологии сосуществовать бок о бок или одна в конечном итоге будет доминировать над другой. Для нас важнее всего то, что мы стандартизируем состав API для создания лучшей экосистемы GraphQL.

Если вы еще этого не сделали, обязательно загляните в раздел Открытая федерация и ознакомьтесь со спецификацией. Мы с нетерпением ждем ваших отзывов и вкладов.