Руководство по добавлению API в ваш график Neo4J с помощью библиотеки @neo4j/graphql.
Чтобы доказать, что концепция мой новый продукт — Clime (приложение для объединения знаний о продукте с помощью нескольких инструментов) была технически осуществима, я создал доказательство концепции с помощью Neo4J, поскольку проблема хорошо поддается графическому представлению. базы данных.
После создания базового набора узлов и установления отношений между ними я смог выполнять запросы, которые позволяли одному узлу находить связанные узлы, которые не были связаны напрямую, используя узел, с которым были связаны оба набора узлов.
Это подтвердило технические аспекты моей идеи, поэтому я перешел к следующему шагу проверки моей идеи, которая заключалась в создании целевой страницы для повышения интереса к продукту.
Как только целевая страница была запущена, я решил вернуться к проверке концепции, поскольку что-то меня беспокоило — база данных графов предоставила средства для запроса графа знаний о продукте, но я еще не планировал, как я буду создавать приложение. Сверху.
Я вижу Clime как централизованный репозиторий для объединения знаний о продукте, доступный из инструментов, которые использует команда (например, вы можете щелкнуть правой кнопкой мыши дизайн в Figma и получить список пользовательских историй, с которыми он связан) через ряд плагинов и интеграций, созданных мной или сообществом пользователей.
Хотя, вероятно, было бы достаточно просто создать библиотеку для обработки запросов Neo4J напрямую, я чувствовал, что другим будет проще работать с REST или GraphQL API, что является ключевым, если я хочу создать продукт, который люди могут создавать. собственные программы для.
После небольшого исследования я был очень рад увидеть, что у Neo4J уже есть решение для создания оболочки GraphQL вокруг базы данных графа — пакет @neo4j/graphql.
Этот пакет в сочетании с драйвером Neo4J (библиотека для доступа к экземпляру Neo4J) позволяет вам создать схему GraphQL для узлов в вашем графе Neo4J и предоставляет некоторые удобные директивы GraphQL, упрощающие определение взаимосвязей запросов. Затем схему GraphQL можно использовать с Apollo или выбранным вами сервером GraphQL.
Создание схемы GraphQL для Neo4J
Прежде чем мы сможем создать API, нам нужна модель данных, которую мы хотим предоставить через этот API. Для API над графовой базой данных эта модель должна включать как узлы, так и ребра, поскольку отношения, которые представляют ребра, будут ключевыми для возврата связанных данных.
Для простоты я собираюсь повторно использовать модель, которую я использовал для проверки концепции Clime.
Mockup— (Дизайн,:VISUALISESиUserStory)UserStory— (Определение поведения системы,:DEFINESaProduct)Product— (Продукт, объект верхнего уровня)Test— (Проверка, выполняемая для проверки правильности работы системы,:TESTSaUserStory)
На основе этой модели вот запрос Cypher, который добавит образец набора данных в Neo4J:
Чтобы создать GraphQL API для этой модели, нам нужно создать определения типов, чтобы конструктор Neo4jGraphQL знал, как сопоставлять узлы в Neo4J с объектами GraphQL. Для начала мы можем просто включить поля, которые будут отображаться в этих объектах (позже мы рассмотрим связанные узлы).
После того, как схема настроена в Apollo, вы можете запрашивать эти типы и поля, как обычно делаете с GraphQL.
Возврат связанных узлов
Базовых полей, которые в настоящее время возвращаются, достаточно, чтобы увидеть значения узлов, но основная причина использования графовой базы данных заключается в том, чтобы иметь возможность находить связанные узлы, и библиотека @neo4j/graphql предлагает несколько директив GraphQL, упрощающих настройку. .
Директива @relationship позволяет добавлять поля для узлов, которые напрямую связаны с определяемым исходным узлом. Он принимает два аргумента; type — тип ребра, соединяющего два узла, и direction — направление отношения (IN для другого узла, определяющего ребро, OUT, если исходный узел определяет ребро).
Возврат данных из ребер, которые связывают узлы
Поле @relationship может быть расширено с помощью директивы @relationshipProperties для включения свойств, установленных во время определения границы между двумя узлами. Определение поля @relationship представляет собой аргумент properties, который соответствует типу, реализующему интерфейс @relationshipProperties.
При запросе связанного поля вы не сможете получить доступ к данным ребра из поля, вместо этого вам нужно будет запросить объект [FIELD NAME]Connection (например, userStoriesConnection), который содержит данные ребра и узел
Возврат данных из узлов, не связанных напрямую
Если нет четкой связи между исходным узлом и другим узлом, который вы хотите вернуть, поскольку они имеют общий связанный узел, вы можете использовать директиву @cypher для выполнения запроса Cypher и возврата результатов в виде поля.
Вот как вы могли бы использовать эти директивы в своей схеме:
И пример запроса для получения отношений:
Запись данных в Neo4J через GraphQL
Библиотека @neo4j/graphql создает полезный набор мутаций для выполнения действий Create-Read-Update-Delete (CRUD) над типами, определенными в схеме GraphQL, которую мы уже рассмотрели (читайте выше), но вот как вы можете создавать, обновлять и удалять узлы и ребра.
Добавление узлов и ребер
Чтобы создать новый узел, вы можете вызвать мутацию create[TYPE NAME] (например, createTest), которая примет входной объект, который является полями без идентификатора для типа. Примером этого может быть:
Обновление узлов и ребер
Чтобы обновить узел, вы можете вызвать мутацию update[TYPE NAME] (например, updateTest), которая возьмет объект where (для поиска узла для обновления) и объект обновления с полями, которые будут обновлены на этом узле.
Вы можете использовать ту же мутацию update[TYPE NAME] для создания новых ребер между узлами, определив объект connect или connectOrCreate с объектом where для поиска исходного узла и объектом where для поиска целевого узла (разница в том, что connectOrCreate создаст узел, являющийся ссылка на него, если он не существует).
Удаление узлов и ребер
Если вы хотите удалить ребро между двумя узлами, вы можете использовать ту же мутацию update[TYPE NAME], но вместо объекта connect вы определяете объект disconnect с объектом where, чтобы найти узел, с которым нужно удалить связь.
Удаление узла выполняется с помощью мутации delete[TYPE NAME] (например, deleteTest) с объектом where, чтобы найти удаляемый узел.
Использование API в приложении
Существует ряд клиентов GraphQL, которые вы можете использовать в своем приложении для извлечения данных из графика Neo4J с помощью GraphQL.
Репозиторий для проверки концепции, указанный в верхней части страницы, содержит базовый плагин Figma, который я создал для использования GraphQL API, он использует клиент Apollo для React, который предоставляет клиент Apollo через контекст React и имеет хуки useQuery и useMutation для выполнять операции внутри компонентов более низкого уровня.
Эти хуки выполняют те же запросы и мутации, что и перечисленные выше, поэтому очень легко создавать эти вызовы, используя песочницу Apollo и копируя их.
Краткое содержание
Библиотека @neo4j/graphql создает действительно мощный API поверх Neo4J, который позволяет тем, у кого мало опыта работы с базами данных графов (например, мне), создавать приложения, которые могут использовать преимущества, предлагаемые базой данных графов при работе со связями между записями.
Примеры и директивы CRUD, которые я рассмотрел, на самом деле являются только поверхностными функциями библиотеки, поэтому я настоятельно рекомендую прочитать документацию библиотеки Neo4J GraphQL, поскольку она очень хорошо организована и проницательна.
Вы можете найти мой код для проверки концепции, который содержит тестовые данные Neo4J, сервер GraphQL и пример плагина Figma, который я создал, чтобы доказать свою идею, на моем Gitlab:
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.
