GraphQL resolver
Server-side function для schema field, яка отримує value з application code, database або downstream service. GraphQL не виконує service discovery самостійно.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Migration mapping checklist
Оберіть одну DTO з проєкту.
Для кожного field зафіксуйте source entity/service, mapping rule, nullability, required status, serializer behavior і regression test.
Додайте один gateway header, який має пройти до внутрішнього service.
Mapping table і один перевірений routing contract.
Намалювати test-aware service map
Вибрати один user flow і намалювати client, gateway, services, databases і brokers.
Позначити synchronous і asynchronous contracts, state setup і failure boundaries.
Для кожної boundary записати одну contract check і одну end-to-end check.
Одна діаграма, за якою видно, де готувати data і як локалізувати test failure.
Шари від таблиці до API response
На спрощеній схемі є database table із полями користувача, entity для роботи з нею, service із бізнес-логікою та mapping, controller з endpoints і DTO, яке повертається клієнту. Response не обов’язково є прямою копією одного рядка: service може звертатися до іншої таблиці або зовнішньої системи, наприклад по `taxId` чи додаткові атрибути. Поля на кшталт `createdAt`, `updatedAt` і `deletedAt` можуть зберігатися в базі, але не віддаватися назовні безпосередньо. DTO формує публічний контракт, а service відповідає за перетворення внутрішніх даних у цей контракт.
Keycloak-style flow і token propagation
На іншому прикладі показані session cookie, target URL, user credentials, authorization code і token exchange. Далі access token передається в controller requests або обмінюється на service token згідно з архітектурою. Тести мають перевіряти expired/wrong audience/insufficient scope, а не лише valid token. Окрема test application для auth load зменшує ризик засмітити production client/user data.
OAuth roles і місце в архітектурі
Authorization server видає/validates tokens і може масштабуватися окремо. Client — application, яка просить access; resource owner дає consent; resource server приймає access token і захищає API. Відео розрізняє user authorization і service-to-service access. Токен має представляти конкретного subject/client і не давати більше privileges, ніж потрібно.
Gateway і вкладена архітектура
Gateway може бути зовнішньою обгорткою над одним або кількома services. Тому один квадрат на high-level diagram може приховувати власну базу, декілька внутрішніх services і нові integrations. Кожен із цих components можна «наблизити» і знову побачити нову архітектуру. На новому проєкті варто попросити lead або developer намалювати таку service map, а потім уточнювати data stores і взаємодії. Це безпосередньо впливає на test design: де готувати state, які контракти перевіряти і де локалізувати падіння.
Перейменування полів і похідні значення
Навіть просте перейменування `surname` на `lastName` зачіпає кілька шарів: database/entity, зовнішній service, mapping і DTO. Якщо API має повертати `fullName`, service може формувати його з `name` та `lastName`; отже, механічне копіювання одного поля дасть синтаксично валідний, але семантично неправильний response. Що більше полів і mapping rules, то вищий ризик пропустити зв’язок або зберегти не те значення. Тести мають перевіряти не лише наявність response, а й коректність значень після всіх перетворень.
Мова як спосіб знайти правильний test level
Ширше знання стеків допомагає не дублювати один сценарій на найдорожчому рівні. Mobile behavior іноді краще перевірити XCTest або Kotlin test; business rule — backend integration test; а лише критичний cross-service flow залишити системним E2E. Вибір залежить від архітектури: частина failures виникає не в service, а в API gateway чи infrastructure. Тому «перенести все вниз» так само некоректно, як перевіряти все через UI. Потрібно розуміти, який рівень реально спостерігає ризик.
REST, status codes і централізовані errors
Для API automation потрібно окремо вивчити REST semantics: methods, resources, типові status codes і їхню очікувану поведінку. Public endpoints зазвичай оптимізовані для frontend або зовнішніх clients, private endpoints можуть обслуговувати внутрішню service-to-service communication і мати інший контракт. Самого HTTP status недостатньо. Централізований error handling має повернути consumer стабільний internal error code і зрозуміле пояснення: якого поля бракує або яке значення невалідне. Власні HTTP status codes на кшталт `600` не замінюють нормального error contract.
User flow і server-to-server flow
User flow емулює дії людини і consent, service flow представляє machine client. Якщо test завжди бере admin/service token, він не перевіряє real user authorization boundaries. Потрібні positive/negative checks для scopes, audience, client type і resource access. Token exchange чи внутрішні service tokens не слід вигадувати за Network tab — їх contract має дати backend/security team.
API gateway і внутрішні services
Клієнт звертається до одного зовнішнього API gateway, хоча за ним працюють окремі user/account та appointment services. Gateway перетворює зовнішній route і проксіює request у внутрішню мережу до відповідного service; зовнішнє й внутрішнє найменування ресурсу може відрізнятися. Service, у свою чергу, може читати кілька tables, звертатися до інших services, виконувати filters і mappings, а controller повертає сформовану DTO. Тому response одного endpoint залежить не від одного методу, а від усього ланцюжка.
Routing-регресії та роль API tests
Під час міграції можна правильно перенести service, але помилитися в gateway route: не прокинути authorization header, body або інший обов’язковий параметр. Клієнт передасть credentials, gateway прийме request, а внутрішній service поверне `401`, бо потрібний header загубився між ними. API tests швидко виявляють такі дефекти mapping, schema й routing без довгого пошуку причини через UI. Практична стратегія сесії: окремо перевіряти контракт ресурсу, окремо — ключові business flows, а під час database чи infrastructure migration запускати обидва набори як regression coverage.