Notes

Come utilizzare un'API GraphQL per l'amministrazione del database
Una recente discussione su graphql-europe mi ha fatto capire che GraphQL sarebbe un'API straordinaria per l'amministrazione dei database.
Sapete che ci sono tantissime funzioni e opzioni per controllare i dettagli di sicurezza, indicizzazione, metadati, clustering e altre operazioni?
Ho utilizzato il viaggio di ritorno in treno per creare un endpoint di amministrazione GraphQL per Neo4j, esponendo tutte le procedure disponibili come query o mutazioni. Utilizzando Kotlin, fortunatamente è stata questione di sole poche righe (200) di codice. E ha funzionato sorprendentemente bene.
Se conosci qualche altro database che espone la sua API di amministrazione tramite GraphQL, faccelo sapere nei commenti: mi piacerebbe dare un'occhiata.
E se ti ispirassi a basare parte del tuo lavoro su questa idea, ne sarei onorato, ancora di più con l'attribuzione :)
TL;DR Puoi ottenere la tua API di amministrazione Neo4j pubblicata su /graphql/admin installando la versione più recente dell'estensione neo4j-graphqlextension. In Neo4j Desktop fai semplicemente clic su "Installa GraphQL" nella sezione Plugin del tuo database (versione 3.4.0.1). Potrebbe essere necessario configurare un'intestazione di autenticazione di base per le credenziali dell'utente del database. Quindi sei pronto per eseguire query sulla tua nuova e brillante API di amministrazione tramite GraphiQL o GraphQL Playground.
L'endpoint non è limitato alle procedure integrate. Le librerie esterne come APOC, algoritmi grafici o neo4j-spatial vengono esposte automaticamente.
Vantaggi Secondo me, il vantaggio più grande è la natura autodocumentante delle API GraphQL basate sul rigido schema fornito.
La digitazione avanzata, la documentazione e le impostazioni predefinite sia per i tipi di input che di output aumentano la chiarezza e riducono il numero di tentativi di tentativi ed errori. La selezione personalizzata dei campi di output e l'attraversamento più approfondito opzionale delle strutture dei risultati consentono una rapida personalizzazione di ciò che si desidera recuperare.
Con la chiara separazione tra query di lettura e mutazioni di scrittura, è facile ragionare sull'impatto di una chiamata.
E ovviamente l'incredibile completamento automatico con la guida in linea e la documentazione disponibile automaticamente in GraphiQL e GraphQL-Playground rendono l'interazione con tale API una gioia. 🎉
Parametrizzare tutti gli input e limitare le dimensioni dei risultati è solo la ciliegina sulla 🎂.
Un altro vantaggio è che puoi combinare più query in un'unica chiamata. Tutte le informazioni rilevanti per uno schermo intero vengono recuperate in un'unica richiesta.
Naturalmente puoi utilizzare tutti gli strumenti GraphQL disponibili come middleware o librerie per creare rapidamente applicazioni front-end (apollo-tools, React, semantic -ui, vittoria, ecc.). Ciò ti consente di integrare rapidamente queste API nei tuoi script o dashboard di monitoraggio/amministrazione.
Dettagli di implementazione Come il normale endpoint GraphQL in neo4j-graphql, questa è un'estensione del server che serve endpoint GET, POST e OPTIONS. Prendono query, variabili e nomi di operazioni da eseguire all'interno di una singola transazione. Dopo l'esecuzione, i risultati o gli errori vengono restituiti come JSON al client.
Lo schema graphql necessario è creato dalle procedure definite dall'utente disponibili distribuite in Neo4j.
Hai per consentire esplicitamente l'esposizione delle procedure tramite l'impostazione di configurazione graphql.admin.procedures.(lettura/scrittura) con la sintassi della procedura Neo4j o i nomi dei campi dell'endpoint admin. Ad esempio, potresti impostarlo su:
graphql.admin.procedures.read=db.*,dbms.components,dbms.queryJ*graphql.admin.procedures.write=db.create*,dbIndexExplicitFor*User Defined Procedure Nel 2016, Neo4j 3.0 ha ottenuto un nuovo punto di estensione. È possibile fornire metodi Java annotati come procedure definite dall'utente, che possono quindi essere richiamate in modo autonomo o come parte delle query del database. Quando il nostro browser Neo4j (basato su React) è passato da HTTP a un trasporto binario, le API REST di gestione originali sono state aumentate con procedure che forniscono le stesse funzionalità.
Ogni procedura può accettare parametri e restituire un flusso di dati con colonne denominate individualmente, simili ai normali risultati delle query. Sia gli input che gli output possono utilizzare tipi di dati dal sistema di tipi Cypher.
call dbms.listConfig('dbms.connector.http') produce nome, valore, descrizione;╒═══════════ ═══════════════════╤═══════╤═════════════ ═════════ ══╕│"nome" │"valore"│"descrizione" │╞═════════════════════════════ ═╪══ ═════╪═════════════════════════╡│"dbms.connector.http.enabled" │"true" │" Abilita questo connettore ."│├──────────────────────────────┼─────── ┼─────── ─────────────────┤│"dbms.connector.https.enabled"│"true" │"Abilita questo connettore."│└───────── ─────────────────────┴───────┴─────────── ───────── ────┘ Da allora, una grande quantità di funzionalità è stata spostata in procedure e funzioni, dandoci un'ampia selezione di cose da esporre tramite GraphQL.
Per costruire lo schema, ho ripetuto sulle procedure disponibili, creando un campo per ciascuna procedura.
Ho preso i parametri della procedura denominata come argomenti di input e ho utilizzato tipi di output personalizzati (per procedura) contenenti le colonne restituite. I parametri di input con valori predefiniti potrebbero essere nullable, gli altri sono definiti come non null. Le descrizioni delle procedure sono state trasformate in descrizioni di campi e anche le informazioni sulla deprecazione sono state trasferite.
Ho mappato i tipi scalari di base e gli elenchi direttamente sui tipi GraphQL.
Solo per la mappa (dict/object) type ho dovuto mapparlo a un List dove ogni attributo è
type Attribute name: String! valore: tipo di stringa: stringa! = "String"> che ha funzionato sorprendentemente bene sia per gli input che per gli output.
Allo stesso modo, ho creato tipi personalizzati per Node, Relationship e Path.
Per questi quattro tipi personalizzati , ho aggiunto il codice di (de-)serializzazione appropriato. Tutti gli altri tipi sconosciuti sono stati renderizzati in stringhe.
Il risolutore per ciascun campo esegue semplicemente la procedura incapsulata con gli argomenti di input dall'ambiente. I risultati vengono quindi mappati sui campi del tipo di output (facoltativamente trasformati) e restituiti all'endpoint.
In base ai loro metadati, ho combinato i campi in tipi di oggetto rispettivamente per query e mutazioni.
E fondamentalmente è tutto.
Anch'io sono rimasto sorpreso quando ho avviato GraphiQL dopo aver distribuito l'estensione che sono riuscito a chiamare intuitivamente qualsiasi query e mutazione senza intoppi.
Sfide La mia sfida più grande è la mancanza di spazi dei nomi in GraphQL. here con i tipi nidificati, lo stesso non è disponibile per le mutazioni.
Per mantenere la denominazione dell'API coerente in entrambi, ho deciso di non sottostrutturare query e mutazioni simili e ho invece unito le parti in maiuscolo dello spazio dei nomi e del nome della procedura insieme.
Quindi db.labels si trasforma in dbLabels .
Un'altra piccola sfida era la mancanza di informazioni sulle operazioni di lettura e scrittura negli ambiti DBMS e SCHEMA di Procedure Neo4j. Quindi ho dovuto utilizzare una whitelist per determinare quelli di "sola lettura", il che ovviamente non è sufficiente.
Notabili Qualcosa che altre tecnologie API non hanno integrato, e che è davvero interessante, è la possibilità di scegliere e selezionare un numero qualsiasi di query o mutazioni che desideri eseguire in una singola richiesta.
Se necessario, puoi anche eseguire l'alias di più invocazioni della stessa query con parametri diversi (pensa alle statistiche per database) .
E puoi anche eseguire algoritmi grafici o istruzioni cifrate come parte di questa API, il che è piuttosto interessante.
Passi successivi Attualmente espongo direttamente solo i parametri e i risultati delle procedure agli utenti. Andando avanti, sarebbe bello derivare tipi di livello superiore che offrano i propri campi di query (dinamici), come
un tipo Label che può anche restituire conteggi, un tipo di server che può fornire il proprio ruolo cluster o altre informazioni locali, aggiungendo campi più dinamici con parametri su un tipo di nodo o relazione per attraversamenti personalizzati Mi piacerebbe 💕 un sacco di dispositivi mobili, app Web e client a riga di comando di monitoraggio e gestione da creare su questa API di gestione.
Sono entusiasta di vedere dove potremmo migliorare l'usabilità e quali feedback e richieste riceveremo. Ovviamente il primo obiettivo sarebbe un'app grafica per Neo4j Desktop. Quindi, se sei interessato a tutto questo, contattaci e parliamone.
Buon hacking! — Michael
Se riscontri problemi, aggiungi un commento o solleva un problema su GitHub.





My Website: http://www.godorologi.it