top of page
Фото автораТаїсія Красноштан

GraphQL: чому розробники обирають його замість REST?


Чому GraphQL обирають замість REST

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


GraphQL був створений у 2012 році компанією Facebook для оптимізації роботи з даними у масштабних проєктах. Відкритий вихідний код у 2015 році зробив його популярним серед розробників, адже він вирішує багато проблем, характерних для REST.


Сьогодні разом із Сергієм Гіденко, Senior Software Engineer в Osavul, ми розберемо, чому GraphQL стає все популярнішим і чим він відрізняється від REST API.


Сергій Гіденко, Senior Software Engineer в Osavul




Що таке GraphQL?


GraphQL для початківців може здатися складним через свою новизну та потужність. Але спробуємо пояснити, чи все так складно як здається.


Уявіть, що ви створюєте додаток і хочете отримати дані про користувача з сервера. Вам потрібні його ім'я, електронна пошта та список замовлень. У REST API це може потребувати кількох запитів до різних ендпоінтів. Але навіть після цього ви можете зіткнутися з двома основними проблемами:


  • Over-fetching — отримання надлишкових даних, які вам не потрібні.

  • Under-fetching — нестача потрібної інформації, що змушує робити додаткові запити.


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


Якщо говорити про захист GraphQL API від небезпечних запитів (наприклад, надто глибоких або важких для обробки), то тут існує кілька методик: «Серед них можна виділити обмеження глибини запиту за рівнями вкладеності, контроль складності запитів та використання пагінації. Для запобігання SQL ін'єкціям важливо дотримуватися загальноприйнятих практик, таких як екранування даних та використання ORM, які можуть перед запитами до бази даних попередньо обробляти вхідні дані», — пояснює Сергій Гіденко з Osavul. 



Як працює GraphQL?


GraphQL — це не просто мова запитів, а комплексний підхід до взаємодії з даними, побудований навколо поняття схеми (schema). Схема — це своєрідна "карта" даних, яка визначає, які об’єкти, поля та взаємозв’язки доступні в API. Вона є основою для взаємодії між клієнтом і сервером, слугуючи інструкцією для обох сторін.


Завдяки схемі клієнт знає, які дані можна запитати, а сервер — які саме дані потрібно надати у відповідь. Робота з GraphQL зводиться до трьох основних концепцій: запити (queries), мутації (mutations) та підписки (subscriptions).


Запити 


Запити дозволяють клієнту отримувати дані з GraphQL API. На відміну від REST, де запити повертають весь ресурс, GraphQL дозволяє клієнту запитувати лише потрібні поля. Це оптимізує використання трафіку та зменшує навантаження на сервер.


Мутації 


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


Підписки 


Підписки дозволяють отримувати актуалізовані дані в реальному часі. Це незамінна функція для додатків, що потребують постійного оновлення, наприклад, чатів чи дашбордів.


Запити, мутації та підписки в GraphQL


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


Ефективність сервера — ще один важливий аспект. За словами Сергія, важливо належним чином організувати взаємодію з базою даних, щоб уникнути зайвих витрат ресурсів. Для цього є кілька стратегій:


  1. Кешування: для рідко змінюваних даних використовуйте кешування на серверному або клієнтському рівнях.

  2. Дата-лоадери: щоб уникнути проблеми N+1, Сергій рекомендує використовувати дата-лоадери. Вони агрегують вкладені дані та виконують один запит замість багатьох.

  3. Відкладені поля: у певних сценаріях варто використовувати поля, які поступово завантажують більш повільні дані, не блокуючи основну відповідь.


Ці підходи дозволяють досягти балансу між швидкістю відповіді сервера та ефективністю використання ресурсів.



Переваги і особливості GraphQL


GraphQL обирають все більше розробників завдяки його численним перевагам:

  1. Отримання лише потрібних даних: клієнти можуть запитувати тільки ті поля, які їм потрібні.

  2. Менша кількість запитів: GraphQL дозволяє об’єднувати кілька запитів у один, що значно спрощує взаємодію з API.

  3. Економія трафіку: завдяки тому, що сервер повертає лише запитувані дані, використання мережевого трафіку оптимізується.

  4. Гнучкість у розробці: клієнт отримує більше контролю над тим, які саме дані і як вони мають бути представлені.

  5. Типізація даних: використання строго типізованих схем зменшує ймовірність помилок і робить API більш передбачуваним.


Попри переваги GraphQL, у нього є свої особливості, які можуть стати викликами для розробників. 


Сергій Гіденко про GraphQL


Вирішенням цієї проблеми є використання сучасних бібліотек для розмежування доступу, таких як GraphQL Shield або кастомних middleware. Проте це може потребувати більше часу та ресурсів на налаштування порівняно з REST API.


Ще одне обмеження, на яке звертає увагу Сергій, — відсутність стандартних HTTP статус-кодів у GraphQL. Оскільки вся відповідь надсилається через один ендпоінт, розробникам потрібно створювати власну систему обробки помилок. «Це вимагає додаткових зусиль, але дозволяє створити більш контрольовану і гнучку систему управління помилками», — додає він.


На питання, чи є специфічні інструменти для моніторингу продуктивності GraphQL на рівні бекенду, Сергій рекомендує використовувати систему моніторингу, яка застосовується у компанії: «Незалежно від системи моніторингу, налаштування збору метрик з GraphQL ендпоінту буде однаково простим. Щодо спеціалізованих систем для GraphQL, рекомендую розглянути використання Apollo Server Studio. Цей інструмент є одним із найпопулярніших і забезпечує вбудовану підтримку Apollo Studio, а також можливість аналізу запитів та виявлення помилок».



GraphQL vs REST: Порівняння


Розглянемо основні відмінності між GraphQL та REST API:


Основні відмінності GraphQLвід REST

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



Основні компоненти GraphQL


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


Схема


Схема є центральним елементом GraphQL API. Вона визначає, як виглядають дані, описуючи всі доступні типи об’єктів, їхні поля та взаємозв’язки. Завдяки їй клієнти можуть створювати передбачувані запити, точно знаючи, які дані доступні.


Наприклад, GraphQL схема дозволяє чітко описати, що у користувача є ім'я, email та список замовлень. Це гарантує, що клієнт отримає лише ті дані, які були визначені схемою.


Резолвери 


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


«У GraphQL часто виникає проблема зайвих запитів до бази даних, коли один запит може спричинити каскадне виконання додаткових запитів» — попереджає Сергій. І, щоб уникнути цього, він рекомендує наступне:


  1. Організовувати резолвери за типами, щоб кожен резолвер відповідав лише за свій тип даних.

  2. Використовувати дата-лоадери (data loaders), які дозволяють групувати запити та виконувати їх оптимально, уникаючи проблеми N+1 запитів. Це забезпечує не лише ефективність, а й мінімізує навантаження на базу даних.


Типи даних

Типи даних GraphQL визначають структуру даних і дозволяють забезпечити передбачуваність API. Вони можуть бути примітивними (наприклад, рядок чи число) або складними (об’єкти, списки тощо).


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


Крім цього, Сергій пропонує такі підходи:


  1. Власні скалярні типи: їх можна використовувати для додаткової валідації та серіалізації даних, наприклад, для обробки дати чи email.


  2. Input-типи для мутацій: замість передачі багатьох параметрів у запиті доцільно використовувати input-типи, що спрощує код і зменшує ймовірність помилок.


  3. Перелічувані типи (Enums): вони підходять для полів із заздалегідь визначеним набором значень, що значно підвищує зручність роботи з API.



Як почати працювати з GraphQL


Щоби почати роботу з GraphQL, можна використовувати бібліотеки, такі як Apollo Server або GraphQL.js. Ось приклад налаштування сервера з використанням Apollo Server:


  1. Встановлюємо Apollo Server:


const { ApolloServer, gql } = require('apollo-server');


  1. Оголошуємо схему GraphQL:


const typeDefs = gql`

  type Query {

    hello: String

  }

`;


  1. Створюємо резолвери для обробки запитів:


const resolvers = {

  Query: {

    hello: () => 'Привіт, GraphQL!',

  },

};


  1. Налаштовуємо сервер:


const server = new ApolloServer({ typeDefs, resolvers });


server.listen().then(({ url }) => {

  console.log(`🚀 Сервер працює за адресою ${url}`);

});


Цей код налаштовує простий сервер, який обробляє запит і повертає рядок «Привіт, GraphQL!» при запиті до поля hello.


Запити у GraphQL дуже гнучкі та дозволяють запитувати лише потрібні дані. Наприклад, щоб отримати ім'я та електронну адресу користувача з ID 1, запит буде виглядати так:


query {

  user(id: "1") {

    name

    email

  }

}


Цей запит поверне тільки ці два поля, що дозволяє мінімізувати обсяг даних у порівнянні з REST, де часто повертається весь об'єкт з зайвими полями.



Використання GraphQL на практиці: кейси


GraphQL знайшов широке застосування серед провідних технологічних компаній завдяки своїй гнучкості та ефективності. Розглянемо кілька реальних прикладів, які ілюструють його переваги у практичному використанні.



GraphQL у Meta

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



GraphQL у GitHub

Компанія обрала GraphQL для побудови свого API, забезпечуючи розробникам простий і гнучкий доступ до даних, таких як репозиторії, issues і користувачі. Замість багатьох різних ендпоінтів у REST API, GitHub API на GraphQL дозволяє об'єднувати кілька запитів в один. І це значно спрощує роботу з їхньою платформою.



GraphQL у Shopify

У випадку Shopify, провідної платформи для створення інтернет-магазинів, GraphQL допомагає API підтримувати широкий спектр запитів. Наприклад, розробники можуть отримати дані про продукти, замовлення або покупців у тому форматі, який найкраще підходить для їхнього застосунку.



Сергій Гіденко про кейси використання GraphQL

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


«Але,  — попереджає Сергій,  — на мою думку, однією з найпоширеніших проблем інтеграції GraphQL API з API іншого типу, базами даних та іншими технологіями є відсутність підтримки декларативного отримання даних цими технологіями. Для вирішення цього, часто необхідно використовувати сторонні бібліотеки для роботи з базами даних або вносити зміни до зовнішніх APІ».


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


Як бачимо, сьогодні GraphQL активно використовується у багатьох проєктах, і його популярність продовжує зростати, що робить його вигідним вибором для сучасних команд розробки. Зважаючи на свою 8-річну історію, GraphQL вже змінив підхід до побудови API, і, за словами Сергія, "ці технології будуть продовжувати змінювати спосіб розробки API в майбутньому". Одним із важливих кроків у розвитку GraphQL є GraphQL Federation, яка дозволяє об'єднувати кілька сервісів в один запит. Це робить інтеграцію клієнтської частини з бекендом значно простішою і більш гнучкою.


«Однак, тим бекенд-розробникам, які тільки починають впроваджувати GraphQL, я б рекомендував утриматися від поспіху при впровадженні цієї технології, оскільки вона складніша за звичайний REST API. У випадку pet-проекту або початкового стартапу варто пам'ятати, що використання GraphQL може сповільнити розробку та негативно позначитися на результативності. Однак, за наявності чіткого бачення проєкту, розуміння моделі даних, масштабування та дедлайнів, використання GraphQL може бути вигідним на перспективу. Також, я б рекомендував приділяти особливу увагу резолверам, дата-лоадерам та кешуванню», — додає Сергій.

© 2035 by Business Name. Made with Wix Studio™

bottom of page