В „част първа“ разгледахме как стигнахме до тук, така че какво ще кажете за малко код?

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

Така че започваме с библиотеките, които ще използваме. encoding/json, защото ще преобразуваме REST крайните точки в GraphQL за този пример. github.com/graphql-go/* е библиотеката, която използваме тук. net/http за нашия сървър, а останалите са само за различните ни фиктивни отговори.

Сега GraphQL има вградени типове и потребителски типове (които в крайна сметка са съставени от вградените типове точно в долната част). Така че нека дефинираме някои от нашите типове, които съставят нашата схема.

Тук сме дефинирали три типа. Потребител, който съдържа име и списък с акаунти. Типът акаунт, който се използва от потребителя. И тип адрес.

Както можете да видите, те в крайна сметка се оказват куп Низове, Ints и Floats.

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

Така че нека разбием това малко. Лесните части са секциите „последна публикация“, „произволни“ и „двойни“. Всеки от тях има тип (String, Int и Int съответно), Описание (за нашата автоматична документация ) и функция Resolve, която върши действителната работа. Като дефинираме нашите връщани типове като „NewNonNull“, винаги можем да гарантираме, че те ще бъдат дефинирани. За да ги направите nullable, ще нарушите схемата в бъдещи ревизии, така че се уверете, че те никога няма да бъдат nullable. Грешка от страна на предпазливост тук и ги направете nullable (след това проверете в кода от страна на клиента).

Освен това нашият раздел “double” може да приема аргументи. Още веднъж, Non-nullable (т.е. задължително поле). Красотата на GraphQL е, че ако се опитаме да извикаме това без аргумент, ще бъде върната грешка. Освен това, ако се опитаме да извикаме това с String вместо Int, също ще бъде върната грешка. Самодокументиращият се код е прекрасен.

Секциите “user” и “address” са практически едни и същи и са просто бърз и мръсен метод за вземане на JSON от REST крайна точка и предаването му. Посочването на полета във вашата заявка за GraphQL прави цялата магия само на връщането на необходимите данни. В производствена система реалността е, че вероятно ще искате да направите малко повече проверка на отговора тук.

Накрая задаваме нашата заявка за схема да бъде този тип (по-късно тук добавяме тип мутация). След това стартираме сървъра.

За пълния проект поставих основно „репо в github“. Mocks.sh е за добавяне на мокове към работещ сървър на Mountebank.

Така че сега имаме основен сървър, всъщност можем да играем с него, без дори да пишем клиент. Стартирайте сървъра (обикновено „go get && go run main.go“), след което прегледайте http://localhost:8090/graphql. Ще бъдете посрещнати със следния екран.

Така че един доста прост интерфейс. Въведете заявката си отляво, натиснете play и ще получите резултат отдясно. Красотата е, че имате документация (раздел най-вдясно) И автоматично попълване.

Да започнем с нещо основно.

Въведете го, щракнете върху възпроизвеждане и трябва да видите следното (като числото вероятно е различно).

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

Чакай малко, къде са запетаите и какво е това тестово нещо отдолу? Е, за да отговоря на първия, ние сме само JSON-подобни, а не действителен JSON. Чувствайте се свободни да добавите запетаите, ако желаете, но те не са задължителни.

Сега към втората част, „тестът“ в долната част е псевдоним на поле. Красотата на това е, че означава, че можете да поискате едни и същи данни няколко пъти, просто като им дадете различен псевдоним (помислете за SQL заявка, при която присъединявате таблица към самата нея, трябва да направите псевдоним на поне една от тези таблици, за да се обърнете към нея правилно).

Чувствайте се свободни да си поиграете малко с това. Опитайте да въведете низ в “val” на double. Поискайте поле, което не съществува и т.н.

Сега да станем малко по-сложни. Нека направим запитване към един от тези по-сложни типове.

Не е ли много по-трудно? Просто трябва да посочите полетата, които търсите, в рамките на типовете. Тук типът потребител също има допълнителни данни, но ние не ги изискваме, така че не се връща. Това е ОГРОМНО. Можете да спестите доста честотна лента и ненужна обработка тук. Тези от нас с ограничения за данни ще ви харесат за това.

Едно от последните неща, които ще ви покажа в това въведение, е именуване на заявки.

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

Така че заявките за данни са добре, как да променяме данните? Това е мястото, където идват мутациите. Подобно на REST, няма нищо, което физически да ви спре да го правите в нормалните си заявки (или GET с REST), но като всички добри програмисти, вие обичате кода да е правилен, нали?

Така че нека разширим нашия малък Go сървър (или проверете mutate клона, ако използвате кода от моя github).

Трябва да добавим променлива, в която да съхраняваме нашите мутиращи данни. Да, не е добра практика да имате глобална променлива, но това е само примерен код. Добавете реда latestPost (допълнителен код наоколо за контекст).

Намерете къде връщаме latestPost в заявката и го актуализирайте, за да върне вместо това новата променлива.

Актуализирайте функцията main, за да съхранявате стойност по подразбиране за latestPost.

Накрая ще създадем нашата мутация и ще я добавим към нашата схема

Както можете да видите, това е доста просто. Взимаме аргумент за новата стойност и просто го задаваме, след което връщаме тази стойност на latestPost, както обикновено бихме направили в заявка (това е стандартна практика за улесняване на актуализациите от страна на клиента).

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

Всички същите правила от заявките все още се прилагат като именуването на вашите заявки, но това е всичко.

В последната част от тази поредица ще проучим създаването на основен клиент, който да чете това с помощта на Apollo в JavaScript.