Триває дискусія про те, що краще використовувати для створення мікросервісів: REST чи GraphQL. Обидві технології мають своїх прихильників і критиків, але коли справа доходить до конкретних потреб архітектур мікросервісів, то GraphQL стає явним лідером. DevOps.com розповідає, чому.
Розуміння проблем RESTful
Незважаючи на те, що протягом багатьох років REST був основним стилем API, який хвалили за простоту та загальну застосованість, його обмеження стають яскраво очевидними в контексті мікросервісів:
- Надмірна вибірка даних.
- Кілька запитів HTTP на пов’язані дані.
- Складні стратегії керування версіями.
Такі проблеми можуть перешкоджати продуктивності та масштабованості архітектур мікросервісів.
Надмірна вибірка даних
REST API розроблені для повернення фіксованого набору даних, що часто призводить до надмірної вибірки. Ця надлишковість особливо проблематична в мобільних мережах, де кожен додатковий байт даних може призвести до повільнішої роботи програм і погіршення взаємодії з користувачем.
Наприклад, уявіть, що у нас є кінцева точка REST API /api/user/{userId}, яка повертає такі дані для користувача.
У сценаріях, коли мобільні програми вимагають лише певних даних користувача, як-от ім’я та електронна адреса для огляду профілю, отримання повних даних користувача означає надмірне отримання.
Це надмірне використання даних може коштувати дорого для користувачів з обмеженими тарифними планами та призвести до зниження продуктивності програми й погіршення взаємодії з користувачем.
Затримка та проблема N+1
Мікросервіси часто потребують розподілу даних між кількома сервісами.
Припустімо, у вас є програма електронної комерції, де домен замовлення обробляє сутності продукту, клієнта, замовлення та повернення, а домен запасу керує сутностями продукту, запасу, складу та доставки. Загальною операцією може бути відображення деталей замовлення разом із поточним станом запасів для кожного продукту.
Скажімо, у нас є мікросервіс замовлень і стоковий мікросервіс.
У нашому сценарії клієнт розміщує три замовлення (N=3), кожне з яких містить чотири різні продукти. Щоб відобразити деталі замовлення зі станом запасів для кожного продукту, програма спочатку робить один запит для отримання замовлень. Потім для кожного продукту в кожному замовленні вона робить додаткові запити до мікросервісу стоків, щоб отримати інформацію про запаси.
Це призводить до одного початкового запиту та 12 наступних запитів (три замовлення по чотири продукти на замовлення), що підсумовує 13 викликів API. Таке мультиплікативне збільшення запитів призводить до більшої затримки через багаторазовий час проходження (RTT) і збільшення навантаження на мережу та сервери, що втілює проблему N+1.
Проблеми з керуванням версіями
Підтримка REST API з часом передбачає складні стратегії керування версіями, такі як впровадження нових кінцевих точок або вбудовування номерів версій у шлях API. Це може призвести до роздуття і плутанини, ускладнюючи розробку та використання API.
Переваги GraphQL
GraphQL усуває багато недоліків REST.
Дизайн, орієнтований на домен
Мікросервіси процвітають завдяки дизайну, керованому доменом, де кожна служба побудована навколо певних бізнес-можливостей. Схемоцентричний підхід GraphQL ідеально узгоджується з цим, створюючи більш організовану й узгоджену структуру для мікросервісів.
Уніфікована схема
В архітектурі мікросервісів кожна служба може мати свою схему, що представляє частину бізнес-області. GraphQL виділяється тим, що дозволяє об’єднувати або з’єднувати ці схеми, надаючи клієнтам єдиний інтерфейс. Це означає, що клієнти можуть запитувати дані з кількох служб в одному запиті, різко зменшуючи складність і кількість мережевих викликів.
Вирішення проблеми N+1
Здатність GraphQL отримувати дані за допомогою одного запиту незалежно від того, скільки базових служб потрібно викликати, безпосередньо вирішує проблему N+1, притаманну архітектурам REST. Це не тільки підвищує продуктивність, але й спрощує логіку отримання даних на стороні клієнта.
Для проблеми N+1, описаної раніше, якщо сервіси підтримують GraphQL, його можна використовувати для отримання вкладених даних в одному запиті, ефективно вирішуючи проблему N+1.
Ефективність і продуктивність
Даючи змогу клієнтам точно вказувати, які дані їм потрібні, GraphQL усуває проблеми надмірної й недостатньої вибірки, поширені в REST API. Це призводить до більш ефективного пошуку даних, зменшення використання пропускної здатності та швидшого використання програм, що особливо помітно в мобільних середовищах.
У попередньому сценарії, коли мобільні програми вимагають лише певних даних користувача, як-от ім’я та електронна адреса для огляду профілю, клієнти можуть запитувати лише ім’я та електронну адресу.
Спрощене керування версіями
На відміну від REST, GraphQL зменшує потребу у керуванні версіями, дозволяючи додавати нові поля й типи до схеми, не впливаючи на наявні запити. Ця пряма сумісність означає, що клієнти та сервери можуть із часом розвиватися плавніше.
Сьогодні GraphQL є зрілою технологією, яка відповідає конкретним потребам сучасної веброзробки, що не повністю задовольняються традиційними REST API. Її дизайн сприяє ефективності, гнучкості та продуктивності розробника.
Можна сказати, що майбутнє GraphQL яскраве, а зусилля спільноти спрямовані на усунення поточних обмежень, зокрема щодо безпеки, продуктивності та стандартизації. Оскільки ці зусилля принесуть плоди, очікується, що впровадження GraphQL розшириться, зміцнюючи її позиції як ключової технології в ландшафті API.
Читайте також на ProIT: GraphQL як альтернатива REST API: як працює на Python, в чому переваги та недоліки.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
