Вправа з GraphQL у n8n: дозволяйте мутацію лише після отримання повних результатів запиту
Попрактикуйте перевірку відповідей GraphQL у n8n, курсорну пагінацію та єдине рішення про готовність, що блокує тестову мутацію за неповних або некоректних даних.
Перевірено за наведеними джерелами .
Ваша вправа з GraphQL у n8n
У цій редакційній вправі вам потрібно спроєктувати процес n8n для GraphQL, який збирає повну колекцію типу connection, перевіряє її записи й дозволяє одну нешкідливу мутацію в тестовому середовищі лише після виконання всіх передумов. GraphQL.org зазначає, що відповіді можуть містити одночасно data й errors, тому самої успішної HTTP-відповіді недостатньо для підтвердження готовності. Рекомендації щодо HTTP спираються на проєкт специфікації, а поведінка кодів стану залежить від медіатипу відповіді та реалізації. Перевіряйте тіло відповіді незалежно від успішності HTTP.
Результат роботи — ваш процес і свідчення його виконання для коректного та навмисно помилкових сценаріїв тестового стенда. Це запропонована вправа з проєктування, а не готовий до імпорту процес чи виконана й перевірена інтеграція. Надана документація не підтверджує сумісність з усіма версіями або редакціями n8n.
На нашу думку, корисна навчальна мета — пояснити, чому запис було дозволено або заблоковано, а не просто забезпечити виконання успішного сценарію.
Sources: Serving over HTTP | GraphQL, Response | GraphQL
Підготуйте контрольований тестовий стенд і явні вхідні дані
Почніть із наявного середовища n8n і підготовленого, доступного тестового стенда GraphQL. Встановлення та розгортання не входять до цієї вправи. Apollo описує резолвери як функції, що заповнюють поля схеми; отже, навмисно підібрані відповіді резолверів можуть стати основою запропонованого стенда. Наведений нижче контракт є редакційною пропозицією: перед побудовою попросіть власника стенда надати відповідні операції схеми та сценарії, які можна вибирати.
Використайте ці запропоновані вхідні дані. До фінальної тестової гілки процес має лише читати дані. Обмежте пагінацію однією колекцією connection; вкладені колекції, змінні набори даних, авторизація у робочому середовищі, повторні спроби та ідемпотентність мутацій не входять до цієї вправи.
| Вхідні дані | Пропонований контракт |
|---|---|
| Параметри підключення | Кінцева точка, метод автентифікації та облікові дані тестового середовища |
| Сигнатура запиту | records(first: Int!, after: String): RecordConnection! |
| Структура connection | nodes { id name }; pageInfo { hasNextPage endCursor } |
| Очікувані записи | Ідентифікатори A, B і C, кожен із непорожнім ім’ям |
| Сигнатура мутації | markReviewed(recordIds: [ID!]!): ReviewResult! |
| Результат мутації | accepted: Boolean! і recordIds: [ID!]! |
| Засоби керування | Вибір сценарію, журнал мутацій і процедура скидання |
| Сценарії | Коректні дані, часткові помилки, відсутнє ім’я та повторений курсор |
Sources: Resolvers, GraphQL, Pagination | GraphQL
Побудуйте запит і збережіть його відповідь
У цьому прикладі GraphQL у n8n використайте вузол HTTP Request, щоб надіслати JSON POST із query та variables. Документація n8n описує параметри пагінації в тілі POST і вирази для динамічних значень. Конкретні поля нижче належать запропонованому стенду, а не кожному API GraphQL.
Використайте текст запиту query ReadRecords($first: Int!, $after: String) { records(first: $first, after: $after) { nodes { id name } pageInfo { hasNextPage endCursor } } }. Почніть зі значень змінних first = 2 та after = null. Зберігайте повну структуру відповіді, зокрема data й errors.
GraphQL.org розрізняє помилки запиту, за яких data відсутнє, і помилки виконання, які можуть супроводжувати часткові дані. Рекомендації з усунення несправностей радять перевіряти масив errors у тілі відповіді та сумісність зі схемою. У цій вправі фіксуйте будь-який непорожній масив errors як збій, навіть якщо відповідь містить корисні записи.
Якщо ви планували використати вузол GraphQL у n8n, у цій вправі зосередьтеся на HTTP Request, щоб повна структура відповіді та змінні продовження залишалися явними.
Sources: Response | GraphQL, n8n-docs/docs/build/code-in-n8n/cookbook/http-request-node/pagination.md at main · n8n-io/n8n-docs · GitHub, Common HTTP Errors and How to Debug Them | GraphQL
Реалізуйте пагінацію GraphQL у n8n із фіксацією збоїв
GraphQL.org описує непрозорі курсори та метадані connection як одну з моделей пагінації; стенд має явно підтримувати саме її. Документація GraphQL від GitHub описує продовження за допомогою endCursor, доки hasNextPage не стане false для відповідних колекцій. Сприймайте курсори як непрозорі значення, а не номери сторінок.
Документація n8n описує значення пагінації, отримані з відповіді, власні вирази завершення та явні цикли з вузлом IF. Тут оберіть явний цикл, щоб перевіряти кожну сторінку. Передавайте один керувальний елемент із поточним курсором, уже використаними курсорами, зібраними записами, лічильником сторінок, прапорцем завершення та накопиченими причинами збоїв. Дотримуйтеся запропонованої послідовності.
- Запитайте сторінку з поточним курсором і збільште лічильник сторінок.
- Фіксуйте транспортні збої, помилки в тілі відповіді та некоректну структуру даних, не очищаючи попередніх збоїв.
- Додавайте отримані записи, зберігаючи їхні ідентифікатори для порівняння.
- Позначайте завершення лише тоді, коли коректне pageInfo явно містить hasNextPage=false.
- Якщо потрібна наступна сторінка, відхиліть відсутній або вже використаний endCursor; інакше збережіть його та повторіть цикл.
- Використайте запропонований запобіжний ліміт у три запити; якщо він зупиняє обхід до підтвердження останньої сторінки, зафіксуйте неповноту.
На нашу думку, зафіксований збій має зберігатися до кінця цього запуску вправи; наступна коректна сторінка ніколи не повинна стирати попередню причину блокування запису.
Sources: Using pagination in the GraphQL API - GitHub Docs, Pagination | GraphQL, skills/skills/n8n-loops-official/references/HTTP_PAGINATION.md at main · n8n-io/skills · GitHub, n8n-docs/docs/build/flow-logic/loop.md at main · n8n-io/n8n-docs · GitHub
Ухваліть одне рішення про готовність і продемонструйте результат
Після обходу оцініть один керувальний елемент. Запропонована перевірка допуску вимагає явного завершення, відсутності зафіксованих збоїв, непорожніх обов’язкових полів і точної відповідності очікуваним ідентифікаторам без дублікатів. Документація схем Apollo пояснює, що поля, які допускають null, можуть повертати null, а списки з обмеженням non-null усе одно можуть бути порожніми; отже, готовність за бізнес-вимогами потребує власних правил.
Редакційний розбір із гіпотетичними результатами: перша сторінка повертає A і B з непорожніми іменами, hasNextPage=true та непрозорим endCursor. Накопичений стан: records=[A,B], complete=false і failures=[]. Залиште мутацію заблокованою та запитайте другу сторінку з цим курсором. Припустімо, друга сторінка повертає C з непорожнім ім’ям і hasNextPage=false. За відсутності транспортних збоїв і помилок GraphQL накопичений стан стає records=[A,B,C], complete=true і failures=[]. Ідентифікатори точно відповідають очікуваним і не мають дублікатів, тож єдине рішення про готовність дозволяє одну мутацію в тестовому середовищі.
Для гіпотетичного сценарію зі збоєм припустімо, що одна зі сторінок також містить непорожній масив errors. Негайно зафіксуйте цей збій. Навіть якщо обхід в іншому дає A, B і C з коректними іменами та підтвердженням останньої сторінки, failures залишається непорожнім, і перевірка допуску блокує мутацію.
Спрямуйте результат цього єдиного рішення або до однієї тестової мутації, або до результату блокування з переліком невиконаних передумов. Передайте зібрані ідентифікатори через markReviewed, а потім перевірте також errors і очікувані поля відповіді. Використайте цей контрольний список приймання як перелік свідчень, які потрібно надати.
Запропоноване питання для осмислення: поясніть, чому ані коректних часткових записів, ані прапорця останньої сторінки окремо недостатньо. Специфікація GraphQL за вересень 2025 року розрізняє запити лише для читання та мутації, які записують і отримують дані; ця перевірка на боці клієнта не гарантує, що дані сервера залишаться незмінними між цими операціями.
Sources: GraphQL Schema Basics, GraphQL, Common HTTP Errors and How to Debug Them | GraphQL
