Software & Systems

Язык клиент-серверного взаимодействия GraphQL с каждым годом приобретает все более широкую популярность [1]. Его распространение связано как с выразительностью   самого языка, так и с большим количеством инструментальных средств, позволяющих реализовать взаимодействие практически для любой современной программной среды. Многие технологические компании не только взяли на вооружение GraphQL, но и внесли (и продолжают вносить) существенный вклад в его разви-  тие [2, 3]. Основные преимущества GraphQL перед традиционным архитектурным стилем REST заключаются в строгой типизации, иерархичности данных, в отсутствии проблем чрезмерной и недостаточной выборки данных, а также необходимости управления конечными точками REST [4]. Стандартным путем определения типов данных и операций в GraphQL является статическая схема. При ее использова-  нии вся структура данных определяется зара-  нее и не может быть изменена динамически во время работы приложения, обслуживающего запросы. Это обстоятельство не позволяет применять GraphQL в приложениях, где структура данных может динамически изменяться. Данная особенность послужила причиной отказа от использования технологии GraphQL при проектировании авторами ядра интегрированной информационной системы управления документами (СУД) [5]. Взамен для построения API был использован гибридный подход, основанный на REST и сочетающий преимущества иерархичных запросов с динамически изменяемой схемой данных. В процессе опытной эксплуатации системы были выявлены две важные особенности ее работы:

-     динамическая природа структуры данных является источником многих ошибок в формировании, валидации и обработке запросов;

-    частота изменения структуры данных настолько мала, что позволяет выполнять генерацию схемы динамически во время запуска приложения либо непосредственно перед запросом.

Эти факторы позволили пересмотреть вопрос о применении технологии GraphQL в варианте динамической генерации схемы в режиме runtime (во время выполнения приложения). Под динамической генерацией подразумевается возможность простого изменения определений структур метаданных с последующим пересозданием схемы GraphQL в памяти самим приложением.

Существующие подходы к построению динамического GraphQL предусматривают хранение метаданных схемы в кэширующем слое высокопроизводительного хранилища c возможностью их изменения на лету. Как быстрое хранилище может быть использована, например, резидентная система Redis [6]. В рабо-  те [7] описано применение в качестве основного хранилища DynamoDB с индексированием метаданных в Elasticsearch. Интересный способ описания метаданных и генерации схемы GraphQL приведен в [8]. Здесь используются не получивший признания среди разработчиков стандарт RDF и спецификации   языков запросов к данным SPARQL и UGQL.   В RDF в качестве единицы описания сущности применяется так называемая семантическая тройка, или триплет. Утверждение, высказываемое о сущности, имеет вид субъект–предикат–объект. Множество RDF-утверждений образуют граф, вершинами которого являются субъекты и объекты, а ребра отображают отношения. Ввиду несколько запутанной семантики и сложности реализации данная модель не получила широкого распространения.

СУД также реализует вышеописанные подходы хранения кэша схемы в памяти наряду с основным хранилищем в реляционной СУБД. Но при этом используется собственный формат описания и хранения метаданных посредством четко определенного языка DSL. Первичные метаданные описываются через конфигурационные файлы (формата YAML или JSON), на основании которых генерируются необходимые инструкции SQL для создания/модификации таблиц. При необходимости модификации схемы на лету выполняется управляющий   API-запрос, содержащий данные о создаваемой/изменяемой сущности в аналогичном YAML/JSON-формате. Подобный декларативный подход (когда описывается, как должен выглядеть результат, а не какие изменения необходимо выполнить) в настоящее время широко применяется при проектировании информационных систем (яркий пример – экосистема Kubernetes [9]).

Платформа СУД относится к классу систем, называемых Headless CMS [10]. В отличие от традиционных CMS эти системы предполагают управление только контентом (телом), независимо от интерфейса (головы), в котором он будет использоваться. Существует большое количество готовых Headless CMS [10], однако ни одна из них полностью не соответствует требованиям к платформе СУД, а именно – отсутствует функционал версионирования и управления жизненным циклом (ЖЦ) объектов. Кроме того, большая часть решений является проприетарным ПО. В силу своей принадлежности к данному классу систем платформа СУД получила рабочее название Scientific CMS (SciCMS) как ориентированная на работу с высокотехнологичной продукцией.

Проектирование API

Принимая во внимание изначально заложенные требования к платформе и учитывая опыт эксплуатации предыдущей версии системы, в переработанном варианте использован GraphQL с его выразительными языковыми средствами и развитым инструментарием. Для обеспечения переносимости в качестве среды выполнения выбрана платформа Java, поддерживаемая большинством современных ОС. Ядро SciCMS построено на свободно распространяемом фреймворке Spring. Для реализации протокола GraphQL использована библиотека GraphQL Java. Поддерживаются обработка вложенных объектов и иерархические рекурсивные запросы. С целью оптимизации рекурсивные запросы реализуются непосредственно средствами СУБД [11]. Базовые операции с сущностями системы приведены в таблице 1. Поддерживаются версионность и мультиязычность. Имеется возможность настройки ЖЦ сущности (возможные состояния и переходы между ними) в специальном редакторе. Кроме того, платформа позволяет создавать пользовательские операции и привязывать их к сущностям определенного типа.

Сценарии взаимодействия с системой

Обобщенная диаграмма прецедентов приведена на рисунке 1.

Администратор, пользователь либо сторонняя система должны быть авторизованы в си-  стеме и иметь соответствующие разрешения на выполняемые операции. В случае внешней системы для авторизации используются технологические учетные записи (ТУЗ).

В задачи администратора входят управление пользователями, ролями и доступами, а также определение структуры объектов системы, включая атрибуты, представления и обработчики. Кроме того, администратор настраивает параметры версионирования, локализации и управления ЖЦ.

Основные операции над объектами системы (ввод данных об объектах, добавление технической документации, изменение статуса ЖЦ) проводит инженерно-технический персонал. При необходимости любой пользователь может получать оповещения о необходимых операциях или изменениях, а также отслеживать историю изменений.

Внешняя система (приложение ERP, АСУ производства и т.д.) посредством прикладного программного интерфейса (API) также получает данные об учетных сущностях, включая историю изменений и состояние ЖЦ.

Базовый процесс редактирования данных об изделии представлен в виде диаграммы последовательности (см. http://www.swsys.ru/upload  ed/image/2022-4/2022-4-dop/16.jpg).

Проектирование серверной   части системы

Платформа SciCMS состоит из двух независимых модулей: клиентского (работающего в браузере) и серверного. Серверный модуль составляет ядро платформы. На рисунке 2 приведена диаграмма классов подсистемы загрузки метаданных этого модуля. Метаданные платформы определяются в виде YAML- или JSON-файлов, то есть для добавления новой сущности в систему достаточно описать ее харак-  теристики и атрибуты в файле. При этом   платформа сама создаст соответствующие структуры в БД и отследит их версии. Изменение файла схемы вызывает изменение в метаданных с последующим выполнением операций изменения (пересоздания) таблиц и перегенерации схемы GraphQL. Обработка файлов реализуется в классе FileSchemaReader через вызов метода read(). Данный метод возвращает объект типа DbSchema, который, в свою очередь, содержит коллекцию объектов Item с метаданными схемы.

Структура   метаданных платформы

Структура метаданных [5] была переработана в пользу более эффективной организации связанных данных. Так, например, таблица core_items (см. http://www.swsys.ru/uploaded/  image/2022-4/2022-4-dop/17.jpg) c метаданными сущностей предметной области в своем поле SPEC содержит описание атрибутов соответствующей сущности в JSON-формате. В качестве хранилища данных платформы используется реляционная СУБД. Поддерживаются БД Oracle и PostgreSQL. Схема данных разбита на наборы таблиц, которые отвечают за различные подсистемы (ядро, контроль доступа, управление ЖЦ, собственно данные) и именуются соответствующим префиксом. Все таблицы, помимо основных атрибутов, содержат служебные атрибуты аудита, управления версиями и ЖЦ.

Aтрибут versioned определяет, является ли сущность версионируемой. Для целей версионирования каждая таблица хранит набор служебных атрибутов: generation, major_rev, minor_rev, is_current. Версии могут присваиваться автоматически (на основании заданной политики версий – атрибут revision_policy_id сущности) либо вручную. Данное поведение определяется атрибутом manual_versioning.

Аналогично versioned атрибут localized определяет, поддерживает ли сущность мультиязычность. Для этого в каждую таблицу включается атрибут locale.

Помимо версионирования и управления ЖЦ, еще одной важной особенностью SciCMS, отличающей ее от других подобных систем, является возможность использования связанных данных из разных источников в рамках единого информационного пространства. С этой целью каждая сущность содержит поле data_source. Все настройки источников данных задаются в конфигурационных файлах. Данная особенность системы позволяет с высокой эффективностью использовать SciCMS как инте-  грационную основу для многих систем, использующих РСУБД в качестве хранилища данных. Использование нескольких источников данных в рамках одной GraphQL-схемы дает возможность объединения различных сервисов с их собственными подграфами в единый интегрированный шлюз и является эффективной альтернативной таким мощным интеграционным решениям, как, например, GraphQL Federation [12].

Система позволяет хранить все возможные виды связей между сущностями (один-к-одному, многие-к-одному, один-ко-многим, многие-ко-многим). Для моделирования связей «многие-ко-многим» используются дополнительные промежуточные таблицы.

Для иерархической выборки связанных сущностей используется механизм Data Fetchers, эффективно решающий так называемую проблему N+1, заключающуюся в необходимости выполнять дополнительный запрос к связанной сущности для каждого элемента текущей выборки [13].

Изначально данная проблема в СУД решалась путем выполнения дополнительных соединений (Join) в исходном запросе [5]. В процессе опытной эксплуатации подход не оправдал себя при соединении трех и более таблиц, приводя к существенному замедлению выполнения запросов. В связи с этим было проведено небольшое экспериментальное исследование по измерению времени выполнения запросов в СУБД Oracle с различным числом соединений (от 0 до 6). Размер экспериментальной выборки составляет 500 записей. Все столбцы, участвующие в соединении, проиндексированы. Результаты измерений, среднее время и стандартное отклонение приведены в таблице 2. Стандартное отклонение рассчитано по формуле , где ti – значение времени i-й выборки (мс);  – среднее значение; n – число запросов.

Зависимость времени выполнения и стандартного отклонения от числа соединений показана на рисунке 3.

График зависимости показывает, что изменение эффективности выполнения запросов происходит нелинейно, крутизна ее нарастает с каждым дополнительным соединением. Если при одном соединении среднее время составляет 148 мс, то для шести соединений оно пре-  вышает 1 секунду. По такому же закону увели-  чивается и стандартное отклонение, что говорит еще и о деградации стабильности времени выполнения запроса. Это, в свою очередь, требует тщательной настройки индексов таблиц, а также учета особенностей работы оптимизаторов конкретных СУБД. Описать математически закономерность изменения времени выполнения не представляется возможным, так как оно в большой степени зависит от таких факторов, как структура таблиц, размер данных, алгоритмы компиляции и оптимизации СУБД, характеристики вычислительной среды, топология кластеров и сети и т.д.

Суть работы механизма Data Fetchers заключается в выборке связанных сущностей одним запросом к БД по условию принадлежно-  сти этих сущностей к одной из уже выбранных записей верхнего уровня и последующем связывании их непосредственно в приложении. Такой способ гарантирует линейное нарастание времени выполнения от числа соединений и избавляет от проблемы повторной выборки уже запрошенных однажды данных. Запросы при этом выполняются независимо друг от друга, что при необходимости позволяет использовать различные источники данных для каждого из них.

Управление ЖЦ

Для управления ЖЦ служит таблица метаданных core_lifecycles (рис. 4). Каждая таблица в схеме имеет собственный атрибут lifecycle_id, являющийся внешним ключом к первичному ключу ID этой таблицы. В столбце SPEC хранится информация об этапах ЖЦ и переходах между ними. Атрибут implementation хранит название обработчика ЖЦ, позволяя назначать пользовательские обработчики событий переходов ЖЦ. Таблица core_allowed_lifecycles определяет, какие ЖЦ могут быть выбраны для определенной сущности.

Средства безопасности   и контроля доступа

Система контроля доступа была во многом переработана с целью более гибкого распределения разрешений. Метаданные ACL также хранятся в реляционной СУБД. На ER-диаграм-  ме представлены основные таблицы (рис. 5).  Основу ACL составляет механизм разрешений (permission). Каждое разрешение включает в себя список контроля доступа для определенных пользователей и ролей с указанием двоич-  ной маски доступа. Маска доступа включает в себя флаги чтения (R – read), редактирования (W – write), создания (C – create), удаления   (D – delete) и администрирования (A – administration) и позволяет в одном целом числе от 0 до 31 гибко сконфигурировать набор прав. При программном построении структуры будущих SQL-запросов вызываются специальные обработчики, ответственные за фильтрацию данных и операций на основании ACL.

Для подключения данных обработчиков используется широко применяемый механизм (паттерн) Chain of Responsibility (цепочка обязанностей) [14] с целью дополнить структуру будущего запроса ограничивающими выражениями на основании ACL. Таким образом, контроль доступа осуществляется на уровне SQL-запросов, что исключает избыточность данных, избавляет от необходимости их последующей обработки и существенно уменьшает потоки ввода-вывода.

Выводы

Технология GraphQL является одним из ли-  деров среди инструментов предоставления публичного API в распределенных средах.   В силу преимуществ перед традиционным архитектурным стилем REST (строгая типизация, иерархичность данных, отсутствие проблем overfetching и underfetching, отсутствие множества конечных точек) многие технологические компании успешно применяют GraphQL в промышленной разработке. Несмотря на статическую природу, схема GraphQL может быть   заново сгенерирована в процессе работы приложения. Именно такая динамическая перегенерация положена в основу работы системы SciCMS. Создание/изменение сущностей и связей осуществляется декларативным путем с использованием YAML- или JSON-формата (такой подход нашел широкое применение, например, в экосистеме Kubernetes). Функционал SciCMS предусматривает возможность хранения объектов предметной области в древовидном представлении с оптимизирующими механизмами выборки, контроль версий, мультиязычность, управление ЖЦ, а также ис-  пользование нескольких источников данных. Последнее обстоятельство позволяет применять SciCMS как интеграционную основу для многих систем, использующих РСУБД в качестве хранилища данных в рамках ЕИП. Использование нескольких источников данных в рамках одной GraphQL-схемы дает возможность объединения различных сервисов с их собственными подграфами в единый интегрированный шлюз и является эффективной аль-  тернативной таким мощным интеграционным решениям, как, например, GraphQL Federation.

Литература

1.     Тонкушин М.В., Гудков К.В. Сравнительный анализ технологий GraphQL и REST // Современные информационные технологии. 2019. № 29. С. 127–131.

2.     Apollo GraphQL. URL: https://www.apollographql.com/ (дата обращения: 28.05.2022).

3.     Netflix DGS Framework. URL: https://netflix.github.io/dgs/ (дата обращения: 28.05.2022).

4.     Конин М.В., Соколова О.Д. Программные интерфейсы для управления данными, описывающими объекты с иерархической структурой // Проблемы оптимизации сложных систем: сб. тр. 2019.   С. 616–620.

5.     Черныш Б.А., Картамышев А.С. Разработка ядра интегрированной информационной системы // Программные продукты и системы. 2021. Т. 34. № 2. С. 561–566. DOI: 10.15827/0236-235X.134.237-244.

6.     Кетов Д.К. Разработка API-доступа к данным с динамически изменяемой структурой на основе GraphQL // АСУИТ: мат. конф. 2019. С. 108–114.

7.     Silveria A. GraphQL live querying with DynamoDB. ArXiv, 2020. URL: https://arxiv.org/abs/2008.  00129 (дата обращения: 28.05.2022).

8.     Gleim L., Holzheim T., Koren I., Decker S. Automatic bootstrapping of GraphQL endpoints for RDF triple stores. ASLD, 2020, pp. 119–134.

9.     Манойло В.Е. Использование технологий Docker и Kubernetes для построения инфраструктуры сложных систем // Современное образование: Традиции и инновации. 2022. № 1. С. 135–139. DOI: 10.51623/23132027_122_135.

10.  Артемьев Е.В., Гафаров Ф.М. Headless CMS. Концепция и преимущества // Интернаука. 2020.   № 22-1. С. 10–12.

11.  Chernysh B.A., Kartamyshev A.S., Murygin A.V. Hierarchical data model choosing in the information systems design in relational DBMS. Proc. FarEastCon, 2021, pp. 1–5. DOI: 10.1109/FarEastCon50210.2020.  9271190.

12.  Stunkel P., Bargen O., Rutle A., Lamo Y. GraphQL federation: A model-based approach. J. of Object Technology, 2020, vol. 19, no. 2, pp. 18:1–21. DOI: 10.5381/jot.2020.19.2.a18.

13.  Иванов И.А. Решение проблемы «SELECT N+1» при обращении к базе данных при имплементации GraphQL на серверной и клиентской логике // Педагогика. Образование. Практика: сб. тр. конф. 2019. С. 93–95.

14.  Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley Publ., 1995, 395 p.

References

1. Tonkushin M.V., Gudkov K.V. Comparative analysis of GraphQL and REST technologies. Modern Information Technologies, 2019, no. 29, pp. 127–131 (in Russ.).
2. Apollo GraphQL. Available at: https://www.apollographql.com/ (accessed May 28, 2022).
3. Netflix DGS Framework. Available at: https://netflix.github.io/dgs/ (accessed May 28, 2022).
4. Konin M.V., Sokolova O.D. Programming interfaces for managing data describing objects with a hierarchical structure. Proc. OPCS, 2019, pp. 616–620 (in Russ.).
5. Chernysh B.A., Kartamyshev A.S. The core design of an integrated information system. Software & Systems, 2021, vol. 34, no. 2, pp. 561–566. DOI: 10.15827/0236-235X.134.237-244 (in Russ.).
6. Ketov D.K. Developing a GraphQL-based API to dynamic structured data. Proc. ASUIT, 2019,
   pp. 108–114 (in Russ.).
7. Silveria A. GraphQL live querying with DynamoDB. ArXiv, 2020. Available at: https://arxiv.org/abs/2008.00129 (accessed May 28, 2022).
8. Gleim L., Holzheim T., Koren I., Decker S. Automatic bootstrapping of GraphQL endpoints for RDF triple stores. ASLD, 2020, pp. 119–134.
9. Manoylo V.E. Using Docker and Kubernetes technologies to build the infrastructure of complex systems. Modern Education: Traditions and Innovations, 2022, no. 1, pp. 135–139. DOI: 10.51623/23132027_122_135 (in Russ.).
10. Artemyev E.V., Gafarov F.M. Headless CMS. Concept and benefits. Internauka, 2020, no. 22-1,
    pp. 10–12 (in Russ.).
11. Chernysh B.A., Kartamyshev A.S., Murygin A.V. Hierarchical data model choosing in the information systems design in relational DBMS. Proc. FarEastCon, 2021, pp. 1–5. DOI: 10.1109/FarEastCon50210.2020.9271190.
12. Stunkel P., Bargen O., Rutle A., Lamo Y. GraphQL federation: A model-based approach. J. of Object Technology, 2020, vol. 19, no. 2, pp. 18:1–21. DOI: 10.5381/jot.2020.19.2.a18.
13. Ivanov I.A. Solving the ²SELECT N+1² problem when accessing the database when implementing GraphQL on the server and client logic. Proc. Pedagogy. Education. Practice, 2019, pp. 93–95 (in Russ.).
14. Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley Publ., 1995, 395 p.