Англійська для GraphQL Federation

Розділення однієї гігантської схеми GraphQL між командами звучить просто, поки хтось не запитає «яка служба насправді володіє цим полем», і словник федерації — підграфи, сутності, шлюз — це саме та мова, яка відповідає на це питання точно, а не нечітко.

Ключовий словник

** Subgraph ** — окрема служба GraphQL, яка належить одній команді, що показує частину загальної схеми, яку складається з інших підграфів у єдиний об’ єднаний граф. “Подграф замовлень повністю володіє типом Order, в той час як підграф доставки тільки розширює його полем trackingStatus.”

** Надграф ** — єдина складена схема, створена за допомогою поєднання всіх підграфів, що представляє те, що клієнти фактично шукають, навіть якщо жодна служба не реалізує всіх цих параметрів. “Клієнти бачать тільки суперграф — вони не мають жодного уявлення, що запит торкається чотирьох різних підграфів за кадром.”

** Шлюз ** — маршрутизатор, який отримує вхідні запити GraphQL щодо суперграфа, розбиває їх на підзапити для відповідних підграфів і з’ єднує результати у одну відповідь. “Шлюз розділив цей один запит на три запити — один до підграфа користувачів, один до замовлень, і один до запасів — потім об’єднав результати перед поверненням їх.”

** Сутність ** — тип, що об’ єднує декілька підграфів, де один підграф визначає основні поля типу, а інші підграфи надають додаткові поля, посилаючись на нього за допомогою ключа. ” Product є сутністю — підграф каталогу володіє основними полями, такими як назва та ціна, а підграф оглядів розширює його полем averageRating, що має ключ за ідентифікатором продукту.”

** Key directive ** — анотація схеми ( @key(fields: "id") ), яка повідомляє шлюзові, як унікальним чином ідентифікувати об’ єкт у підграфах, щоб він міг об’ єднувати дані, отримані з різних служб. “Ми додали директиву @key(fields: "id") на Product в підграфі оглядів, щоб шлюз знав, як порівняти огляди з правим продуктом з підграфа каталогу.”

Звичайні фрази

• «Який підграф насправді володіє цим полем?»
• Чи є цей тип сутністю, чи існує він тільки в одному підграфі?»
• «Шлюз затримується — це один повільний підграф, чи проблема з композицією?»
• Чи додали ми директиву ключа, щоб шлюз міг розв’язати цю сутність через сервіси?»
• Чи є в цій системі спільні риси, чи є в ній протилежності?

Приклади висловлювань

Пояснення меж власництва у документації з проектування: “Ми розділяємо монолітну схему на підграфи вздовж меж команди — команда замовлень володіє основними полями сутності Order, і будь-яка команда, якій потрібно розширити її, додає поля у свій власний підграф за допомогою директиви ключів.”

Зневадження повільного федеративного запиту:
“Шлюз розширює цей запит до п’ яти підграфів, коли йому потрібно лише два — композиція включає розширення сутності, яке насправді не запитується.”

Перегляд помилки складання схеми: “Суперграф не зміг скласти, тому що два підграфи оголосили не- нульове поле status на одній сутності з різними типами — один з них повинен змінитися, перш ніж це може бути розгорнуто.”

Професійні поради

• Назвіть конкретний ** підграф **, який є власником поля, коли обговорюється право власності або зневадження — « хто є власником цього » є одним з найпоширеніших питань у федеративній архітектурі і заслуговує на точну відповідь.
• Відрізняти ** сутність ** від звичайного типу явно — лише сутності потребують директиви ключа, і розгляд кожного типу як одного додає непотрібної складності.
• Пояснити поведінку ** gateway ** fan- out, коли федеративний запит є повільним — кількість підграфів, які торкаються, а не складність запиту, часто пояснює затримку.
• Позначати помилки ** складання ** як помилки рівня схеми, а не часу виконання, проблеми у записах подій — пошкоджений складання суперграфа блокує розгортання до того, як буде виконано запит.

Практичні вправи

1. Напишіть речення, у якому пояснюється різниця між підграфом і суперграфом.
2. Пояснити, що робить директива ключа для сутності.
3. Описує дії, які виконує шлюз під час отримання запиту, який охоплює декілька підграфів.

Розвиток ринку: ринок цінних паперів в умовах ринкової економіки

Погляньмо правді в очі — коли ви працюєте зі складними системами, такими як GraphQL Federation, термінологія може здатися приголомшливою. Це не просто розуміння * того, що * ви робите; це розуміння, яке ви чітко і чітко висловлюєте вашій команді, чи це під час перегляду коду, обговорення Slack, чи написання опису запитів на витяг. Для розробників, які будують свої професійні навички англійської мови разом з технічною експертизою, це може бути особливо складним. Нюанси опису розподілених систем — відносини між підграфами, роль шлюзів і складності розв’язання сутностей — вимагають точності і словника, що виходить за рамки простих визначень.

Ключова область, в якій нерідні носії часто борються, це обговорення потенційних проблем або запропонованих рішень. Замість того, щоб просто сказати «Це не працює», вам потрібно передати * чому * це не працює і запропонувати шлях вперед таким чином, щоб це відгукнулося на ваших колег. Наприклад, уявіть, що ви отримуєте коментар на запит pull: « Поле « orderTotal » відсутнє у підграфі. Вивчіть розв’ язання сутності. » Менш лаконічною відповіддю може бути « Виправте це. » Але більш ефективною відповіддю — яка демонструє, що ви розумієте суть проблеми — буде « Я виявив, що orderTotal не повертається підграфом « Замовлення ». Це, ймовірно, виникає через невідповідності у тому, як обчислюються загальні суми замовлень у різних системах, що вимагає від нас вдосконалення нашої стратегії розв’ язання об’ єктів, щоб забезпечити синхронізацію даних. ” Зауважте зміну: вона визнає потенційну кореневу причину і пропонує більш цілеспрямований підхід.

Крім того, при документуванні вашої роботи - особливо в описах PR - використання точної термінології має вирішальне значення для підтримки і співпраці. Розглянемо цей приклад: « Реалізовано нову кінцеву точку шлюзу для агрегування даних з підграфів « Продукти » і « Інвентар ». Шлюз використовує нетипову функцію розв’ язання (див. нижче) для розв’ язання сутностей на основі ідентифікацій продуктів, забезпечуючи послідовність правил назв у обох джерелах. ” Цей опис не просто описує те, що ви зробили; це пояснює * як * ви це зробили і підкреслює критичний елемент розв’ язання сутностей — щось, що легко може бути неправильно зрозуміло, якщо не чітко сформулювати. Сфокусування на « чому » за вашими рішеннями, поряд з « чим », є надзвичайно важливим для ефективного спілкування у федеративному середовищі.

Нарешті, пам’ ятайте, що активне слухання і запитання прояснюючих питань так само важливі, як і ефективне самовираження. Не вагайтеся ввічливо запитати про подальші пояснення, якщо ви не впевнені в чомусь - такі фрази, як “Чи можете ви розібратися, як розв’язання сутностей обробляється в цьому контексті?” або “Чи можемо ми обговорити потенційний вплив цих змін на продуктивність шлюзу?” демонструють залучення і прихильність до розуміння більшої картини. Зростання впевненості у своїх здібностях у англійській мові, у поєднанні з активним підходом до спілкування, безсумнівно, прискорить ваш успіх у навігації за складностями GraphQL Federation.

# Example: Using `graphql-cli` to query an entity resolution issue
graphql --schema https://example.com/schema.graphql \
       --query '{ subscription(id: "your_subscription_id") {  order { orderTotal } } }'