Англійська мова для постійних запитів GraphQL

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

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

** Постійний запит ** Перманентний запит — це запит GraphQL, який було збережено на сервері заздалегідь і до якого можна звертатися за допомогою унікального ідентифікатора, замість надсилання повного тексту запиту з кожним запитом. Клієнт надсилає лише ідентифікатор запиту, а не рядок запиту.

• Приклад: « Ми реалізували постійні запити, щоб зменшити розмір наших запитів GraphQL з декількох кілобайт до декількох десятків байтів. » *

** Запитувати список дозволених** Список дозволених запитів (іноді його називають списком безпечних запитів або списком схвалених запитів) є заходом безпеки, який обмежує сервер на прийняття лише попередньо схвалених постійних запитів. Це запобігає клієнтам від надсилання довільних запитів, значно зменшуючи поверхню атаки.

• Приклад: « Якщо буде встановлено список дозволених запитів, будь- який запит, який не був зареєстрований заздалегідь, буде відхилено — це захищає нас від атак інтроспекції і витоку даних. »*

** Автоматичні тривалі запити (APQ) ** Автоматичні тривалі запити (APQ) — це протокол, за якого клієнт спочатку намагається надіслати запит за допомогою свого гешу. Якщо сервер не розпізнає геш, він відповідає помилкою, і клієнт знову надсилає повний запит. Потім сервер кешує його для майбутніх запитів.

• Приклад: « Ми використовуємо автоматичну функцію постійних запитів Apollo — при першому запиті, повний запит надсилається і кешується. На наступні запити, тільки геш надсилається.”*

** Хешування запиту ** Хешування запитів — це процес створення криптографічного гешування (зазвичай SHA-256) рядка запиту для створення стабільного ідентифікатора фіксованої довжини. Хеш є детермінованим — один і той же запит завжди виробляє один і той же геш. Приклад: «Ми гешуємо наші запити під час збирання за допомогою SHA-256 і реєструємо їх на сервері як частину процесу розгортання.»

** Кешування CDN ** Однією з переваг постійних запитів є те, що запити GET (з ідентифікаторами запитів як параметрами URL) можна кешувати на рівні CDN, оскільки запит ідентифікується за допомогою стабільного гешу в URL, а не за допомогою змінного тіла запиту.

• Приклад: « Перехід на постійні запити дозволив нам кешувати наші найпоширеніші запити на рівні CDN, що зменшило навантаження на джерело на 60% ». *

Поширені сценарії, де використовується ця мова

** У обговоренні оптимізації продуктивності: ** «Наші GraphQL запити великі, тому що ми надсилаємо повні рядки запитів. Якщо ми реалізуємо постійні запити, ми можемо замінити ці рядки короткими гешами і увімкнути кешування CDN для запитів з великим обсягом читання. Я оцінюю, що це може зменшити наш API розмір вантажу на 80%. ”

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

В обзоре кода: “Я бачу, що ми використовуємо автоматичні постійні запити. Чи можете ви переконатися, що геш запиту буде створено під час збирання, а не під час виконання? Таким чином, ми можемо зареєструвати всі запити як частину CI конвеєра і ловити будь-які незареєстровані запити, перш ніж вони досягнуть виробництва. “

Корисні фрази для обговорення тривалих запитів

• «Постійні запити значно зменшують корисну нагрузку запитів — замість повного рядка запиту, ми надсилаємо тільки геш.»
• «Запит allowlist забезпечує, що тільки наші попередньо схвалені запити можуть бути виконані проти API.»
• «Ми реєструємо нові запити як частину процесу збирання, тому сервер завжди має найновіші версії.»
• APQ працює прозоро — клієнт автоматично обробляє резервне копіювання, якщо сервер не розпізнає геш
• «З персистентними запитами, ми можемо використовувати запити GET замість POST, що дозволяє кешування CDN»
• «Хеш обчислюється з нормалізованого рядка запиту, тому відмінності між пробілами і коментарями не впливають на нього.»
• Якщо запит змінюється, генерується новий хеш, а старий стає недійсним
• «Ми використовуємо цей додаток Apollo для створення постійного манифесту запиту під час збирання.»
• «Сервер перевіряє вхідний хеш проти зареєстрованого сховища запитів і повертає помилку для невідомих запитів.»
• «Постійні запити особливо цінні для мобільних клієнтів, де пропускна здатність обмежена»

Порівняння персистентних стратегій запитів

Існує два основних підходи до постійних запитів, і знати, як порівняти їх англійською, допоможе вам у обговоренні проектування:

** Попередньо зареєстровано (під час компіляції): ** Запити гешуються і реєструються на сервері під час процесу збирання. Це забезпечує найвищий рівень безпеки — жоден незареєстрований запит не зможе дістатися до сервера — але вимагає скоординованого розгортання.

** Автоматично зберігати запиту (під час виконання): ** Записи запиту кешуються під час першого використання. Це простіше реалізувати і не вимагає координації між розгортаннями, але не надає переваги безпеки, яку надає строгий список дозволених.

Використовуйте цю рамку: « Попередньо зареєстровані тривалі запити забезпечують більшу безпеку, але вимагають більшої координації між розгортанням клієнта і сервера. APQ є більш гнучким і легше приймати поступово, але не дає нам забезпечення allowlist. “

Практичні рекомендації

Напишіть коротку технічну пропозицію (200- 250 слів) англійською мовою, у якій рекомендується впровадження постійних запитів для вигаданого API GraphQL, який використовується мобільною програмою. Поясніть проблему, яку ви вирішуєте, ваш запропонований підхід (передреєстрований або APQ), очікувані переваги, а також будь- які компроміси або кроки переходу. Використовуйте принаймні чотири слова з цього повідомлення і зосередьтеся на тому, щоб зробити вашу пропозицію переконливою і конкретною.

На практиці: Навігація Nuance в командному спілкуванні

Для тих, хто не є рідною мовою, оволодіння тонкими нюансами професійної англійської мови може бути значною перешкодою при співпраці з міжнародними командами над складними проектами, такими як реалізація GraphQL. Це не просто переклад слів; це розуміння як ці слова використовуються в конкретних контекстах - особливо при обговоренні технічних рішень, що включають постійні запити. Розглянемо типовий сценарій: ви переглядаєте запит на витягнення (PR) колеги, який вводить новий постійний запит для отримання профілів користувачів з більш докладною інформацією, зокрема, посиланнями на соціальні мережі і параметрами сповіщень. Опис PR простий: « Додана постійна функція запиту для розширених даних профілю користувача ». Проте, під час перегляду ваш колега отримує коментар від іншого розробника, Сари, у якому йдеться: « Цей запит здається трохи агресивним. Чи справді нам потрібні всі ці дані у фоні? Розглянемо потенційний вплив на продуктивність і завантаження бази даних»

Ключ тут не в тому, щоб просто зрозуміти, що Сара вказує на проблему. Це про розуміння як вона це виражає, і як ви реагуєте. Фрази на кшталт «здається трохи агресивним» або «потенційно впливає на продуктивність» не є просто критикою; вони ретельно побудовані спостереження, призначені для того, щоб спонукати до подальшого обговорення. Фраза вказує на турботу про ефективність і масштабованість — концепції, які часто обговорюються в розробці GraphQL. Більш пряме, потенційно тупе, твердження («Цей запит повільний!») може бути сприйнято негативно. Замість того, щоб негайно захищати свою роботу, продумана відповідь, яка визнає дійсність її зауважень, продемонструє професіоналізм і готовність до співпраці: «Гаразд, Сара! Я не в повній мірі розглядав наслідки виконання з таким широким діапазоном. Давайте розглянемо способи оптимізації цього — можливо, обмеження повернених полів або кешування часто доступних даних. ” Такий вид формулювання є ключовим для ефективного спілкування у команді розробників.

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

# Example: GraphQL query utilizing persisted data
query GetUserProfile($userId: ID!) {
  user(id: $userId) {
    id
    name
    email
    socialMediaLinks {
      linkedin
      twitter
    }
    notificationPreferences {
      emailNotificationsEnabled
      smsNotificationsEnabled
    }
  }
}

Нарешті, пам’ятайте, що використання технічного словника, наприклад, «затримка», «недійсність кешу» або «схема бази даних» - очікується. Однак, опис цих концепцій у ясних і коротких поясненнях, підібраних під вашу аудиторію, завжди буде ефективнішим, ніж просто використовувати жаргон.