Днес е първият ден от седмицата на стартиране на WunderGraph, всъщност това е първата ни седмица на стартиране. Имаме много неща, които да споделим с вас, като Open Federation, Cosmo и други...

Това, което най-много ме вълнува е, че днес бележи началото на нова ера за GraphQL. От много дълго време екосистемата на GraphQL е доминирана от една компания. Това обаче е на път да се промени чрез две инициативи и екосистемата, която ще се появи около тях.

Първата стъпка е „Отворена федерация“, лицензирана от MIT спецификация за изграждане на обединени GraphQL API. Целта на Open Federation е да даде възможност на екосистемата GraphQL да изгради обединени GraphQL API, без да се налага да разчита на патентованата технология на Apollo. Това е незаменим заместител на Apollo Federation, той е с отворен код и е безплатен за използване от всички.

Най-важното е, че не обявяваме Open Federation сами. Open Federation е съвместно усилие на WunderGraph, Grafbase, Escape Tech, Neo4j, TailorTech, Sibipro, Soundtrack Your Brand, Travelpasses и много други.

Втората стъпка е GraphQL Fusion, спецификация за съставени GraphQL API, която надхвърля това, което Apollo Federation предлага, като поддръжка за композиране не само на GraphQL API, но също и за REST(OpenAPI), gRPC, AsyncAPI и др. GraphQL Fusion ще живее под GraphQL Foundation. Целта на Fusion е да даде възможност за съставяне на GraphQL API с разнообразен набор от доставчици и технологии. 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 Gateways и други инструменти на GraphQL. Работя по тази библиотека вече повече от 5 години и тя постигна голям успех. Преди почти 3 години започнах да добавям поддръжка за Apollo Federation към graphql-go-tools. Колкото и да бях развълнуван от идеята за Федерация, общността все още не беше готова за нея. Добавих поддръжка за абонаменти преди години, но търсенето беше много ниско, така че фокусът ми се измести към решаването на други проблеми.

Бързо напред до 2023 г., изведнъж нещата се промениха фундаментално. Екосистемата на GraphQL нарасна много и търсенето на Federation се увеличи значително. В същото време Apollo започна да затваря своята екосистема с отворен код с промени в лиценза, увеличения на цените и др.

Всичко това доведе до това, че много хора се обърнаха към нас и поискаха помощ. Някои от тях, като TailorTech, дори бяха готови да спонсорират разработването на федерация v2 съвместим Gateway и инструменти за съставяне на graphql-go-tools. Големите предприятия ни помогнаха много с тестването или предоставянето на GraphQL схеми на техните обединени графики, за да тестваме нашата реализация.

Но имаше проблем, който първо трябваше да преодолеем. Какво всъщност е Apollo Federation?

„Какво всъщност е федерация Аполо?“

Това може да звучи като глупав въпрос, но всъщност не е. На този етап всички трябва да имаме разбиране на високо ниво за това какво е Федерация. Но гледали ли сте някога детайлите, като спецификацията?

Ето „Спецификация“ на Apollo Federation v2. Това са девет директиви и един скалар, това е. Без коментари, без обяснения, без примери, нищо. Това е всичко, но не и спецификация и всъщност оставя всички важни въпроси без отговор.

Например, как всъщност внедрявате федерален шлюз? Какво трябва да прави Gateway? Какви са правилата за валидиране на обединена GraphQL схема? Как всъщност съставяте обединени GraphQL API? Какви са правилата за проверка дали два или повече подграфа са съвместими?

За сравнение спецификацията на GraphQL описва много подробно как трябва да се държи GraphQL сървър. Той съдържа множество примери за валидиране и правила за изпълнение, както и описания на основни алгоритми, като например как да обедините набори за избор или как да изпълните GraphQL заявка.

Ако искате да разберете Apollo Federation в детайли, трябва да прочетете много документация на различни места и дори тогава пак ще имате много въпроси. Може да успеете да проектирате обратно поведението на шлюза и маршрутизатора Apollo, но дори и да го направите, все още има някои поведения, които изглеждат случайни и не са документирани никъде.

Затова се запитахме как можем да изградим инструменти за съставяне на подграфи и рутер/шлюз за разрешаване на обединени GraphQL заявки, без да имаме подходящо описание на „нашето разбиране“ за федерацията?

„Раждането на Open Federation“

Тогава решихме да започнем да записваме собственото си разбиране за Федерацията. Като записвате цялото си знание, можете да го критикувате и да ни помогнете да го подобрим. Ако намерите пропуски или грешки, можем да си сътрудничим, за да намерим общо разбиране за това какво е федерация, как работи композицията и как трябва да се държи Gateway.

От този момент нататък множество доставчици могат да прилагат една и съща спецификация, така че вие ​​сте свободни да изберете най-доброто решение за вашия случай на употреба. Вече не сте заключени към един доставчик, можете да превключите към друг доставчик по всяко време. Можете дори да изградите свой собствен Gateway, ако желаете. Освен това можете да предложите подобрения на спецификацията и действително да окажете влияние върху бъдещето на обединените GraphQL API.

Целите на Open Federation

Не вярваме, че има бъдеще за патентовани решения за съставяне на API. Много малко вероятно е един доставчик с решение със затворен код да е в състояние да обслужва пазара с възможно най-доброто решение.

Виждали сме обратното в миналото с OpenAPI. Преди OpenAPI имаше много патентовани персонализирани решения за описание и управление на REST API. Въпреки това, OpenAPI се превърна в де факто стандарт за REST API и се поддържа от много доставчици и инструменти. Това е страхотна история на успеха и доведе до много иновации в пространството на REST API.

Вярваме, че Open Federation може да има подобно въздействие върху екосистемата на GraphQL. Една отворена спецификация ще направи обединения GraphQL много по-достъпен и привлекателен за много компании и следователно ще доведе до по-голямо приемане на GraphQL като цяло. Това от своя страна ще привлече повече доставчици към екосистемата на GraphQL, което ще доведе до повече иновации и здравословна конкуренция.

В крайна сметка в най-добрия интерес на екосистемата на GraphQL е да има разнообразен набор от доставчици и технологии. Чрез стандартизиране на състава на API на GraphQL доставчиците могат да се съсредоточат върху силните си страни и да си сътрудничат с допълващи се решения.

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

В този момент може би се чудите каква е разликата между Open Federation и Apollo Federation?

„Каква е разликата между Open Federation и Apollo Federation?“

Apollo Federation не е пълна спецификация. Това е набор от директиви, които, ако се използват правилно на подграф, ще го направят съвместим с Apollo Gateway и Router.

Open Federation се основава на същите директиви, за да уточни подграфи. Това е спецификация, която описва подробно правилата за съставяне на подграфи, как трябва да се планират и изпълняват обединени GraphQL заявки.

Open Federation може да се разглежда като незаменим заместител на Apollo Federation, само че е много по-специфичен, с отворен код и безплатен за използване от всички.

„Каква е връзката между Open Federation и GraphQL Fusion?“

За много случаи на употреба обединените GraphQL API ще бъдат повече от достатъчни и няма причина да не приемете или използвате Open Federation.

Въпреки това ще има случаи на употреба, при които искате да съставите не само обединени GraphQL API, но и REST API, gRPC API, AsyncAPI и др. Това е мястото, където GraphQL Fusion влиза в действие.

Заключение

Federated GraphQL е зряла технология и се използва в производството от години. GraphQL Fusion все още е в начален етап и ще отнеме известно време, за да достигне същото ниво на зрялост.

Залагаме и на двете технологии и вярваме, че ще се допълват много добре. Времето ще покаже дали и двете технологии ще живеят една до друга или едната в крайна сметка ще доминира другата. Най-важното за нас е, че стандартизираме състава на API, за да изградим по-добра GraphQL екосистема.

Ако все още не сте го направили, не забравяйте да разгледате Open Federation и да разгледате спецификацията. Очакваме вашите отзиви и приноси.