Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
GraphQL schema і resolver implementation, а не GraphQL standard сам по собі, визначають, які databases або downstream services викликаються для field.
Це уточнення формулювання, а не зміна специфікації.
Вступ до API-автоматизації →Current GraphQL-over-HTTP draft requires POST support, permits GET for query operations, forbids GET for mutations and defines non-200 status handling. Тому transport contract треба тестувати за media type і operation, а не очікувати 200 для кожної відповіді.
Точну транспортну специфікацію відео не називає; перевірено проти current draft 2026-07-31.
Вступ до API-автоматизації →Server-side function для schema field, яка отримує value з application code, database або downstream service. GraphQL не виконує service discovery самостійно.
Вступ до API-автоматизації →Нормативні definitions для query, mutation, subscription і selection set.
Вступ до API-автоматизації → Першоджерело ↗Query є read-only fetch, mutation — write followed by fetch, subscription — long-lived event-driven request. Selection set визначає fields, які client очікує у response.
Вступ до API-автоматизації →У GraphQL client зазвичай звертається до одного endpoint і в request описує потрібні fields та зв’язки. Queries читають дані, mutations змінюють їх. Якщо екрану потрібні user і всі його pets, GraphQL layer сам визначає, які downstream services викликати і як звести результат. Для тесів важливо знати цей internal mapping. Тоді покриття можна розділити за downstream service і полем, а при падінні однієї частини очікувати точний набір failures, а не безадресне падіння всіх API-тесів.
У REST структура починається з resources та HTTP methods. `Pet`, `Store` або `User` задають назви controllers/clients, а дії на кшталт create, update, delete чи find by ID — назви методів. Request і response models корисно розділяти, бо server response часто містить поля, яких не було у request. У GraphQL треба повторювати назви queries, mutations, inputs і types зі schema. Code generation може дати готові типи, але базове правило те саме: не створювати паралельний словник там, де backend contract уже має точні терміни. Read-only доступ до frontend і backend repositories допомагає швидше зрозуміти систему й підтримувати automation разом зі змінами продукту.
Окрім REST, системи використовують WebSocket, gRPC і GraphQL. Протокол обирається під задачу, тому перед автоматизацією потрібно зрозуміти не лише endpoint, а й модель комунікації. Backend for Frontend — це gateway з контрактом, зручним для конкретного client: web frontend, mobile application або окремого screen. Зовні він відкриває потрібні resources, а всередині може агрегувати кілька services з їхніми базами і queues.
[Дивитися з 24:35](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1475s). Простим можна вважати потік без зовнішніх інтеграцій і складних доменних правил, де запит напряму читає дозволені поля. Але навіть там можуть з'явитися GraphQL-подібні запити, складна authorization-фільтрація або performance-проблеми в database. Головний висновок: тестувальник має намалювати реальний dependency flow, з'ясувати, де виконуються authentication, authorization, billing, caching і error handling, а вже потім обирати рівні тестування та automation. Простота UI чи OpenAPI-контракту не є доказом простоти системи.