GraphQL е навсякъде в наши дни. От първоначалното използване на Facebook до някои по-фънки употреби като „бази данни“, GraphQL е обичан от толкова много разработчици, че започваме да го използваме в области, за които никой не би се сетил първоначално.

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

Наскоро прекарах известно време в мислене къде GraphQL блести най-много. Можем да го наречем GraphQL „Sweet Spot“.

Всичко, което е близо до средата, е мястото, където според мен GraphQL пасва идеално. Отивайки към външната част на кръга, това е мястото, където смятам, че GraphQL може да се използва, но може би няма да се възползва от същите предимства. Може би можем да мислим за това като за различни „нива“.

Преди да проучим тези нива, позволете ми да направя нещо по-ясно: дори определени употреби на GraphQL да са извън така нареченото „Sweet Spot“, това не означава, че са напълно невалидни. Това означава най-вече, че може получавате по-малко от предимствата му или трябва да инвестирате повече инструменти, за да го направите по-подходящ. Може също да означава, че съм изостанал с времето ;).

Първо ниво

Случаите на използване на ниво едно за GraphQL го използват като вътрешен API за поддръжка на множество клиенти. Това е оригиналният случай на използване на Facebook и можем да очакваме GraphQL да бъде оптимизиран за него. И така, какъв точно е този случай на употреба?

Бяхме разочаровани от разликите между данните, които искахме да използваме в нашите приложения, и заявките към сървъра, които изискваха. [Източник]

Преди GraphQL подобни опасения бяха подчертани от Daniel Jacobson. Статиите на Даниел все още са едни от любимите ми:

REST API са отлични при обработката на заявки по общ начин, установявайки набор от правила, които позволяват на голям брой познати и неизвестни разработчици лесно да използват услугите, предлагани от API.

В този модел всеки знае как да се държи и той може да бъде невероятно мощен. Доставчиците на API установяват набор от правила и потребителите на API трябва да се придържат към тези правила, за да получат това, което искат от API. Идеално е, нали? В много случаи отговорът очевидно е да. Но в други случаи, тъй като нашият свят се мащабира и броят на начините за хората да консумират цифрово съдържание и услуги продължава да се разширява, този универсален модел вероятно няма да успее. [Източник]

И в двата случая GraphQL може да се разглежда като решение за нарастващите проблеми, които доставчиците и клиентите на API изпитват, когато случаите на използване се захранват от универсален API и се опитват да бъдат консумирани от SSKD (малък набор от известни разработчици , по думите на Даниел).

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

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

Ако имаме работа с удостоверени API с непостоянни данни и множество устройства/клиенти/ПИ ги консумират по различни начини, мисля, че GraphQL е страхотен начин за справяне с проблема OSFA в мащаб на компанията. Да преминем към второ ниво.

Второ ниво

Второ ниво е това, което считаме за много разумно и добро използване на GraphQL, но може би не по причини, които са много специфични за GraphQL.

Първият пример е един клиент за интерфейс, който говори с GraphQL чрез API. Още по-популярни в наши дни с приложенията в стил JAMStack.

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

  • Удивителна екосистема от инструменти и библиотеки.
  • Типизирана схема и изричен договор между API и клиента.
  • Предоставяне на повече власт в ръцете на клиентите.
  • Една заявка за изпълнение на всички нужди на клиента

Всичко това са страхотни неща. Причините, поради които включвам този контекст на използване във второ ниво, а не първо ниво, са, че тъй като в случай на използване на един клиент, режийните разходи на пълна платформа GraphQL може или не могат да бъдат необходими.

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

С това казано, това, което прави GraphQL все още страхотен избор, е, че той обединява много от тези предимства като страхотен, готов за използване пакет и всичко това е специфицирано. Много по-лесно е да правите GraphQL по правилния начин в сравнение с някои други API стилове, които изискват отделните разработчици да изберат най-добрите инструменти, спецификации и най-добри практики. Наличието на един клиент сега също не означава, че не очаквате да имате проблемите, свързани с поддръжката на множество вътрешни клиенти по-късно, което би направило приемането на GraphQL добър начин за предпазване от бъдещето (Трудно е да знаете тези неща преди време все пак).

Друг случай на употреба, който считам за второ ниво, е публичен GraphQL API. Отново в условията на Даниел Джейкъбсън, API, работещ с LSUD (Голям набор от неизвестни разработчици). От една страна, GraphQL изглежда идеално подходящ за този случай на употреба. Това прави много по-лесно боравенето с множество различни клиентски случаи на използване отколкото да се налага да създавате персонализирани ресурси или персонализирани RPC извиквания за всички тях. Всъщност можем да мислим за това като за позволяване на всеки клиент да създава свои собствени ресурси от страната на сървъра въз основа на схема. От друга страна, GraphQL блести, когато дефинира своите възможности с мисъл за конкретни клиенти. Много публични API трябва да поддържат нещата по-общи, за да позволят на толкова много непознати клиенти да намерят това, от което се нуждаят, и да измислят неща, за които не сме се сетили на първо място.

Както Фил Калкадо казва прекрасно в статия за BFF Pattern:

За да дадете възможност на разработчиците на трети страни да изградят интересни интеграции, трябва да проектирате API, който не прави предположения за това как ще се използват данните. Източник

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

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

Ниво три

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

Една от тях е комуникацията услуга-услуга. Както разгледах в „„GraphQL чудесен избор ли е за комуникации на услуги изток-запад?“, извикванията на услугата често трябва да бъдат доста оптимизирани за единичен случай на употреба и режийните разходи на машината за заявки рядко са нещо, което си заслужава. Когато съществуват неща като gRPC, Twirp и Thrift, струва ми се, че ще имате нужда от много добра причина да не използвате тези доказани инструменти и да изберете GraphQL.

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

Отново, това не означава, че тези случаи на употреба са напълно невалидни. Дори на трето ниво можем да вземем изрично решение да използваме GraphQL. Добри примери за причини да го направите може да са последователност (използване на GraphQL вече в други области), вътрешна експертиза (Екипът е експерт в GraphQL) или дори щастието на разработчиците. Неща, които са по-трудни за измерване и ще зависят много от конкретни сценарии.

Заключение

И така, какъв е смисълът от всичко това? Мисля, че колкото по-отдалечен е нашият проблем от GraphQL Sweet Spot, толкова повече трябва да мислим защо искаме да го изберем като инструмент по избор. GraphQL, макар и наистина мощна идея, носи известна сложност. В идеалния случай искаме тази сложност да бъде компромис, който изрично правим, защото знаем, че GraphQL решава проблема по страхотен начин.

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

наздраве,

Марк

*** първоначално публикувано на https://productionreadygraphql.com ***