GraphQL – Зміна і покращення способу спілкування застосунків

Не минуло багато часу, коли наступне покоління буде купувати криптовалюту та перевіряти свій баланс довірчих фондів у Fortnite lobby між іграми. Це буде можливим завдяки багатьом технологічним досягненням.

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

Лідером у цьому плані є GraphQL, відкрита мова запитів та маніпуляцій з даними. Основою його екосистеми є специфікація та колекція інструментів, створених навколо нього.

Він не новий – час рухається швидко. Facebook розробив його у 2012 році та використовував тільки внутрішньо для розробки мобільних застосунків. У 2015 році він був відкритий, і сьогодні ним керує фундація GraphQL (https://graphql.org/foundation/), яка контролює його подальший розвиток.

Чому я пишу про це зараз? Типовий шлях до технологічної адоптації включає наступні етапи: 1) хобі/особисті проекти, 2) реалізація на декількох мовах, 3) реалізація у стартапах та малих компаніях, 4) середні компанії та використання у розробці продукції, 5) великі корпорації та технологічні гіганти.

GraphQL досяг рівня 5. Наразі він використовується GitHub, Pinterest, Shopify, Microsoft, а також最近, станом на березень 2022 року, Salesforce.

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

Як він відрізняється від традиційного REST API?

• Одним з основних переваг є те, що з GraphQL ви можете запитувати дані та отримувати тільки ті дані, які вам потрібні. Якщо вам потрібно тільки дві поля, пов’язані з певним інцидентом клієнта, то це саме те, що ви отримаєте. Традиційне REST API поверне вам УСІ поля, пов’язані з інцидентом. Це може бути 100+ полів. Тепер вам потрібно щось зробити з усіма цими даними, яких ви не хотіли спочатку. Це називається надмірним завантаженням даних (під завантаженням також є проблема).
• Вищезгадане робить GraphQL швидшим за інші методи API при поверненні даних.
• GraphQL є сильно типізованою мовою, яка, серед іншого, означає, що помилки коду виявляються до виконання програми, а не під час її виконання.
• Було створено велику кількість інструментів навколо GraphQL, що зробило його дуже дружнім до розробників.
• GraphQL має один кінцевий пункт, на відміну від REST API, який має кілька кінцевих пунктів. Це означає, що всі ваші дані можна отримати в одному запиті.

Дві сторони медалі: запитувач (клієнт) та постачальник (хост GraphQL)

Я розглянув GraphQL до цього моменту з точки зору запиту даних. Компанія, така як Salesforce або Microsoft, встановила GraphQL API, яку ви можете використовувати для запиту та маніпуляції даними (читання, оновлення, додавання).

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

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

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

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