Вас приветствует Интернет конференция!
Приветствуйем на нашем сайте
ПРОБЛЕМА НАДМІРНОСТІ ДАНИХ І ЇЇ ВИРІШЕННЯ ЗА ДОПОМОГОЮ ТЕХНОЛОГІЇ GRAPHQL ЯК ЗАСОБУ ОБМІНУ ІНФОРМАЦІЇ МІЖ КЛІЄНТОМ ТА СЕРВЕРОМ У КОНТЕКСТІ WEB-ЗАСТОСУНКІВ
30.09.2021 21:33
[1. Информационные системы и технологии]
Автор: Соботник Е.Л., студент спеціальності інженерія програмного забезпечення, кафедра інженерії програмного забезпечення, Івано-Франківський національний технічний університет нафти і газу, м. Івано-Франківськ; Бандура В.В., к.т.н, доцент, кафедра інженерії програмного забезпечення, Івано-Франківський національний технічний університет нафти і газу, м. Івано-Франківськ
Відомо, що більшість WEB-застосунків складаються з клієнта та сервера. Це 2 окремих додатки, що у комплексі вирішують ту чи іншу бізнес-задачу. Стандартно оці 2 додатки спілкуються між собою за допомогою технології REST [1]. Та, на жаль, із стрімким розвитком інформаційних технологій збільшується і кількість даних, що обробляються сучасними додатками. Це спричинило завантаження певних наборів даних, які не потрібні при роботі WEB-застосунку. Таке завантаження даних збільшує час виконання програми, що негативно впливає на використання програмного забезпечення. Такий ефект називається надмірністю даних, і компанія Facebook представила свій засіб вирішення цієї проблеми – технологію GraphQL [2].
Коротше кажучи, GraphQL – це мова запитів із відкритим кодом, створена Facebook – компанією, яка, як не дивно, залишається на вершині розробки WEB-програмного забезпечення. До того, як GraphQL став відкритим вихідним кодом у 2015 році, Facebook використовував його для своїх мобільних додатків з 2012 року, як альтернативу загальній архітектурі REST. Ця технологія дозволяє створювати запити на конкретні дані, надаючи клієнтам можливість контролю над інформацією, що надсилається. Вона є складнішою за архітектуру RESTful, оскільки серверна база визначає, які дані доступні для кожного ресурсу на кожній URL-адресі, тоді як інтерфейс завжди повинен запитувати всю інформацію у ресурсі, навіть якщо потрібна лише частина. Ця проблема і називається надмірним завантаженням даних. У найгіршому випадку клієнтська програма повинна зчитувати кілька ресурсів за допомогою декількох мережевих запитів. Це надмірне завантаження створює потребу в надсиланні запитів, як водоспад, один за одним, щоб отримати певні дані. Мова запитів, така як GraphQL на стороні сервера та на стороні клієнта, дозволяє клієнту вирішити, які дані йому потрібні, зробивши один запит до сервера. У результаті використання мережі для мобільних додатків Facebook різко зменшилось, оскільки GraphQL зробив її більш ефективною при передачі даних [3, с. 1].
Facebook реалізувала дану технологію із відкритим кодом та специфікацією GraphQL. Перша розробка була написана мовою JavaScript, а згодом стала підтримувати й інші мови програмування, такі як C#, Java, Python, PHP тощо. Зараз ця технологія дуже стрімко розвивається і список підтримуваних мов дедалі збільшується. Екосистема навколо GraphQL зростає не тільки горизонтально, пропонуючи кілька мов програмування, але також і вертикально, з бібліотеками поверх GraphQL, такими як Apollo та Relay, які дозволяють зручно оперувати змінними та залежностями, що необхідні для роботи. Операція GraphQL – це або запит (читання), мутація (запис), або підписка (безперервне читання). Кожна з цих операцій – це лише рядок, який потрібно побудувати відповідно до специфікації мови запитів GraphQL. На щастя, GraphQL постійно розвивається, тому в майбутньому можуть бути інші операції. Як тільки операція GraphQL досягає сервера, вона може бути інтерпретована щодо всієї схеми GraphQL і оброблена з використанням даних WEB-клієнта, що надсилає їх. GraphQL не знає нічого про мережевий рівень, який часто є HTTP, а також про формат вхідних даних, який зазвичай є JSON. Ця технологія взагалі не прив’язується до архітектури додатків. Це лише мова запитів [3, c.2]. Така інкапсуляція дозволяє абстрагувати дану технологію від конкретної реалізації застосунків і за рахунок цього надає можливість її інтеграції у будь-яке середовище, що збільшує використання цієї технології інженерами програмного забезпечення.
Розглянемо приклад GraphQL-запиту на рис. 1, який виконується клієнтом і надсилається на сервер.
Рис. 1 – приклад виконання GraphQL-запиту (читання)
Як бачимо, цей запит вже вимагає декілька ресурсів (автор, стаття), що називаються полями в GraphQL, і лише певний набір вкладених даних для цих полів (name, urlSlug для статті), хоча сам об’єкт пропонує більше інформації у своїй схемі GraphQL (наприклад, опис, дані про випуск статті). Архітектурі RESTful потрібні принаймні два запити, які виконуються один за одним, для отримання сутності автора та її статей, тоді як GraphQL-запит зробив це за один раз. Крім того, запит лише вибрав необхідні поля замість цілої сутності. Відповідь сервера на такий запит зображено на рис. 2.
Рис. 2 – приклад відповіді сервера на GraphQL-запит
Отже, серверна програма пропонує схему GraphQL, де вона визначає всі доступні дані зі своєю ієрархією та типами, а клієнтська програма лише запитує необхідні дані. Такий підхід економить ресурси і трафік, а також вирішує проблему надмірності даних.
Список використаних джерел:
1. https://en.wikipedia.org/wiki/Representational_state_transfer
2. https://en.wikipedia.org/wiki/GraphQL
3. R. Wieruch The Road to GraphQL. – Germany, Berlin, 2018. – 341 c.
Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License
Знайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter
Другие научные работы даной секции
-
ОПТИМІЗАЦІЯ РОЗРАХУНКІВ ДЛЯ МАГІСТРАЛЬНОЇ ЛІНІЇ ЗА ДОПОМОГОЮ ІНФОРМАЦІЙНОЇ СТОРІНКИ
30.09.2021 21:40 -
БАГАТОШАРОВА ВІРТУАЛЬНА МЕРЕЖА
30.09.2021 21:38 -
ВЕБ-СИСТЕМА ДЛЯ ІНТЕРАКТИВНОЇ РОБОТИ З 3D-ОБ’ЄКТАМИ
30.09.2021 21:36 -
КОМП’ЮТЕРНА СИСТЕМА ІДЕНТИФІКАЦІЇ ЗМІСТУ ЕТИКЕТОК ТОВАРІВ ЗА ЇХ ЗОБРАЖЕННЯМ
30.09.2021 21:35 -
COMPUTER SCIENCE IN THE MEDICINE
30.09.2021 21:28
Конференции
Конференции 2024
Конференции 2023
Конференции 2022
Конференции 2021
