Introducere în Hasura GraphQL Engine pentru API-uri dinamice cu PostgreSQL

În general, în ultimii ani, API-urile REST au fost criticate ca fiind inflexibile în timp ce se confruntă cu cerințele tehnologice în schimbare rapidă. Privind retrospectiv, mulți cred că GraphQL a fost creat pentru a face față acestei nevoi de flexibilitate și eficiență suplimentară în dezvoltarea API. Astfel, atenuarea deficiențelor API-urilor REST. Ca rezultat al tranziției Facebook de la aplicațiile HTML5 la configurații mai robuste și native, GraphQL a crescut în popularitate și adoptare în ultimii cinci ani cu un motiv întemeiat. În acest blog, vom aprofunda în fenomenul GraphQL, PostgreSQL și mai târziu vom avea o introducere detaliată a motorului Hasura GraphQL. Într-un fragment, motorul Hasura GraphQL-PostgreSQL relația și ecosistemul.

GraphQL: O rebeliune Facebook

În timp ce mulți cred că GraphQL a fost creat ca o rebeliune față de API-urile REST, acest lucru ar putea fi mai departe de adevăr. În mod ironic, a fost creat pur și simplu pentru a satisface o nevoie internă la Facebook. Proiectat inițial și cu sursă deschisă de echipa Facebook, GraphQL este adesea confundat ca o tehnologie de bază de date. În esență, în ciuda concepției greșite, GraphQL este din punct de vedere tehnic un limbaj de interogare pentru API-uri și nu baze de date. În consecință, reduce complexitatea construirii API-urilor, reținând toate cererile la un singur punct final. Spre deosebire de API-urile REST tradiționale, GraphQL este declarativ, ceea ce înseamnă că orice este solicitat este returnat. Deși pentru a obține puțin mai mult context, va trebui să facem un pas înapoi și să revedem API-urile REST.

Arhitectura REST

De obicei, API-urile sunt reguli, rutine sau protocoale care specifică modul în care componentele software ar trebui să interacționeze. Transferul de stat reprezentativ (REST) ​​este practic o arhitectură de proiectare API utilizată în mod normal în implementarea serviciilor web în care totul este considerat o „resurse”. Din păcate, metodologia RESTful s-a limitat în mod constant la a se ocupa de resurse individuale. Prin urmare, dacă ar fi nevoie de date și provin de la două sau mai multe resurse, de exemplu, postări și utilizatori, ar fi necesare călătorii multiple la server pentru a colecta tot ce este necesar. În plus, REST s-a confruntat cu probleme cu preluarea „peste” și „sub”. Toate acestea nu au fost ideale, mai ales odată cu apariția mai multor aplicații bazate pe date care gestionează seturi mari de date care combină resurse aferente. Ceea ce ar putea explica situația dificilă cu care se confruntă Facebook.

Astfel, necesitatea unei arhitecturi API care să adopte o abordare mai flexibilă și mai progresivă.

Crearea unei alternative

Alternativ, GraphQL nu se gândește la date în termeni de adrese URL de resurse, chei secundare sau tabele, ci în termeni de grafic al obiectelor și modelelor care utilizează NSObjects sau JSON. Mai exact, GraphQL nu are nevoie de puncte finale dedicate pentru fiecare caz de utilizare, deoarece diferite capabilități și cazuri de utilizare pot fi reprezentate într-un singur „Graph”. Folosind limbajul de interogare GraphQL, puteți descrie exact cum ar trebui să arate răspunsul, deci nu sunt necesare călătorii dus-întors la server. Ca limbaj de interogare la nivel de aplicație, este conceput pentru a interpreta un șir de la un server/client și a returna acele date într-un format stabil, ușor de înțeles și previzibil. Este pur și simplu un instrument pentru a consolida mai bine datele.

Simplitate, stabilitate și eficiență.

Adevărul este că nu toate proiectele necesită GraphQL în ciuda schemei sale bine definite, așa că știm sigur că nu vom supraprelua. Cu toate acestea, dacă avem un produs de întreprindere care se bazează pe date din mai multe surse, de exemplu MySQL, Postgres și alte API-uri, atunci GraphQL este opțiunea mai bună. GraphQL se mândrește cu simplitate, în special în ceea ce privește regăsirea datelor, deoarece datele sunt colectate sub un punct final comun sau apel. În esență, deoarece clienții obțin exact ceea ce au nevoie, acest lucru reduce efectiv dimensiunea fiecărei cereri făcute de client, rezultând aplicații de înaltă performanță. Deoarece GraphQL unifică datele care altfel ar necesita mai multe puncte finale, ușurează extragerea repetată complexă, astfel o eficiență mai bună a interogărilor. În consecință, cu simplitatea sa vine mai multă stabilitate back-end, planificare, construcție, execuție și funcționare continuă în timp.

Avantajele GraphQL

Pe scurt, GraphQL permite extragerea datelor cu interogări ușor de înțeles, permite dezvoltarea rapidă a aplicațiilor ușoare și rapide, deoarece datele sunt accesate mai direct decât prin intermediul unui server. În plus, permite regăsirea mai multor resurse cu o singură interogare fără a utiliza mai multe URL-uri sau înlănțuirea resurselor, folosind în același timp un punct final pentru toate datele. Amintiți-vă, datele sunt definite pe server cu o schemă bazată pe grafic, deci sunt livrate ca pachet, mai degrabă decât prin apeluri multiple. Acest lucru permite un impuls operațional în agregarea răspunsurilor API în timpul dezvoltării API.

Acest lucru, la rândul său, reduce sarcina echipelor de dezvoltare front-end, facilitează versiunea API, simplifică întreținerea și economisește cererile de transfer de date. În plus, permite mai multă predictibilitate la primirea datelor, acceptă preluarea declarativă a datelor și atenuează supra-aducerea și prelevarea insuficientă. În esență, suprapreluarea are loc atunci când un client descarcă mai multe informații decât este necesar de fapt în aplicație, în timp ce preluarea insuficientă implică faptul că un anumit punct final nu a furnizat suficiente informații, solicitând astfel clientului să facă cereri suplimentare pentru a prelua ceea ce are nevoie.

Din punct de vedere tehnic, GraphQL este un wrapper care poate fi definit, ceea ce înseamnă că nu trebuie să înlocuiți complet un sistem REST. În esență, aceasta înseamnă că GraphQL este compatibil cu sistemele cu care sunt compatibile API-urile centrate pe REST. În plus, GraphQL permite dezvoltarea fără întreruperi și independentă a frontului și back-end-ului. Acest lucru se datorează faptului că, odată ce schema este bine definită, echipele care lucrează pe front-end și back-end sunt conștiente de structura definită a datelor. Toate aceste beneficii sunt considerate avantajoase de mulți ingineri full-stack. În cele din urmă, GraphQL are o capacitate uimitoare de introspecție aprofundată și auto-documentare.

Cazuri de utilizare GraphQL în dezvoltarea API

Considerat extrem de puternic, GraphQL este folosit de dezvoltatorii Full-stack care caută o lizibilitate stabilă, cu viteză și indexare rapidă. Mai exact, GraphQL este util în dezvoltarea API-urilor care necesită un debit mare de date. De fapt, minimizează cantitatea de date necesară pentru transferul printr-o rețea. Acest lucru este extrem de benefic pentru utilizatorii de telefonie mobilă, dispozitive cu putere redusă și rețele neglijente. Acesta este unul dintre motivele inițiale pentru care Facebook a creat GraphQL. Contrar credinței, GraphQL nu este aplicabil numai în baze de date complexe uriașe, ci poate crea baze de date relativ simple, cu o eficiență mai mare.

În plus, poate fi aplicat pe o varietate de cadre și platforme front-end unice, oferind un peisaj eterogen întreținut cu un singur API pentru a se potrivi tuturor cerințelor utilizatorilor. În plus, facilitează dezvoltarea rapidă a caracteristicilor, deoarece crește dramatic viteza caracteristicilor pentru echipele de dezvoltatori full-stack. Face acest lucru prin reducerea comunicării necesare între echipe în timp ce dezvoltă noi funcții, deoarece dezvoltatorii front-end pot face solicitări API, de exemplu, pentru a introduce noi funcții sau pentru a le schimba pe cele existente, fără a fi nevoie să aștepte ca dezvoltatorii de back-end să le livreze. Acest rezumat rapid GraphQL ar trebui să fie suficient pentru moment, când intrăm în introducerea noastră în motorul Hasura GraphQL. Deși să atingem PostgreSQL pentru mai mult context.

Ce este PostgreSQL?

Fiind un sistem gratuit de gestionare a bazelor de date relaționale, condus de comunitate, PostgreSQL nu este deținut de nicio companie. Considerat cel mai puternic și mai consistent RDBMS disponibil, Postgres a fost scris în C și acceptă o serie de limbaje de programare, cum ar fi C/C++, JavaScript, Java, Python, R, Go, Lisp, .Net etc. Este din ce în ce mai preferat printre majoritatea dezvoltatori full-stack, PostgreSQL este mai bogat în funcții decât MySQL, sora sa, câștigând popularitate datorită caracteristicilor, scalabilității și performanței sale. PostgreSQL este popular în proiectele în care cerințele gravitează în jurul procedurilor complexe, designurilor complicate, integrării la comandă și integrității datelor.

Avantajele Postgres pentru dezvoltatorii Full-Stack

În general, funcții cum ar fi căutarea în text complet, coloanele JSON, replicarea logică, dau lui Postgres mâna de sus pe MySQL. Acest lucru este optim pentru cerințele de performanță ale bazelor de date comerciale tipice, permițând în același timp consolidarea mai multor sisteme de baze de date într-unul singur pentru mai puține cheltuieli și costuri. În plus, caracteristicile sale mai recente pentru stocarea cheii-valoare (tipuri de coloane JSON / JSONB) îl fac o alternativă potrivită la bazele de date NoSQL. În plus, acceptă clustering sau o arhitectură master-slave, făcându-l bine potrivit pentru medii de tip cloud. În plus, extensia sa populară de înveliș de date străine permite interogarea surselor externe direct din PostgreSQL atunci când este necesar. Mai exact, este cel mai potrivit pentru sistemele care necesită executarea de interogări complexe, depozitare de date și analiză dinamică a datelor.

De fapt, PostgreSQL acceptă mai bine anumite funcții pe care MySQL nu le face. De exemplu, verificați constrângerile, tipurile de date bogate (cum ar fi matrice, hărți, JSON), suport geospațial mai bogat (PostGIS) și suport mai bogat pentru text complet. În plus, acceptă crearea de index fără blocare, indexuri parțiale, expresii comune de tabel și funcții de analiză mai dinamice. Cu toate acestea, PostgreSQL oferă suport SLL nativ pentru conexiunile pentru criptarea comunicațiilor client/server, precum și o îmbunătățire încorporată numită SE-PostgreSQL care oferă controale suplimentare de acces bazate pe politica SELinux.

Cu multe caracteristici bogate pentru produse de nivel enterprise, PostgreSQL este potrivit pentru sisteme mari în care datele necesită autentificare și vitezele de citire/scriere sunt esențiale pentru succesul proiectului. În plus, acceptă, de asemenea, mai mulți îmbunătățitori de performanță care sunt în mod normal disponibili în soluțiile proprietare. Acestea includ: concurență fără blocări de citire, server SQL și suport pentru date geospațiale, pentru a menționa câteva.

Un alt avantaj principal al arhitecturii Postgres este extensibilitatea sa unică. Permite utilizatorilor să adauge funcții precum tipuri de date, metode de acces la index, limbaje de programare pentru server, pachete de date străine (FDW) și extensii care se pot încărca fără a modifica codul sistemului de bază. Utilizează o arhitectură modernă de procesor multi-core, astfel încât performanța sa să crească aproape liniar pe măsură ce numărul de nuclee crește. Acest lucru este important, în general, caracteristici precum căutarea în text complet, coloanele JSON, replicarea logică, dau lui Postgres mâna de sus pe MySQL. Acest lucru este optim pentru cerințele de performanță ale bazelor de date comerciale tipice, permițând în același timp consolidarea mai multor sisteme de baze de date într-unul singur pentru mai puține cheltuieli și costuri. În plus, caracteristicile sale mai recente pentru stocarea cheii-valoare (tipuri de coloane JSON / JSONB) îl fac o alternativă potrivită la bazele de date NoSQL. În plus, acceptă clustering sau o arhitectură master-slave, făcându-l bine potrivit pentru medii de tip cloud. În plus, extensia sa populară de înveliș de date străine permite interogarea surselor externe direct din PostgreSQL atunci când este necesar. Mai exact, este cel mai potrivit pentru sistemele care necesită executarea de interogări complexe, depozitare de date și analiză dinamică a datelor.

Contra ale PostgreSQL

În general, dacă vă plac standardele ANSI SQL, luați în considerare PostgreSQL, deși dacă preferați standardele ODBC, atunci optați pentru MySQL. Din păcate, ocazional, Postgres nu se confruntă cu performanța cu medii de producție live, „întotdeauna la înălțime”. Un dezavantaj suplimentar cu Postgres este faptul că replicarea sa este implementată la nivelul motorului de stocare. Acest lucru îl face mai costisitor decât replicarea MySQL, care este mai matură și implementată la „nivelul motorului de interogare”.

Introducere în motorul Hasura GraphQL

Deoarece am acoperit pe scurt dezvoltarea API-ului GraphQL și PostgreSQL, ar trebui să avem suficient context pentru o introducere în motorul Hasura GraphQL. Practic, Hasura este pur și simplu un motor GraphQL pentru RDBMS PostgreSQL, oferind o modalitate simplificată de bootstrapping și de gestionare a dezvoltării GraphQL API. Privind retrospectiv, Hasura este în prezent singura soluție ușor disponibilă care adaugă instantaneu GraphQL-as-a-Service pe aplicațiile existente bazate pe PostgreSQL. În esență, ocolind sarcina consumatoare de timp de a scrie cod backend care procesează GraphQL.

Hasura simplificat

Să luăm un minut pentru a simplifica mai mult Hasura. Practic, API-urile sunt interfețe care vă permit să solicitați informații (o interogare), și astfel să răspundeți trimițând date JSON sau XML. Acea bază de date este în mod normal găzduită și preluată de pe un server. Aici intervine Hasura pentru a simplifica lucrurile. În retrospectivă, motorul Hasura GraphQL este un server care gestionează interogările GraphQL printr-o bază de date Postgres. Acest lucru reduce efectiv timpul necesar aplicației dvs. pentru a fi gata de producție, permițându-vă să creați, să vizualizați și să modificați cu ușurință tabelele bazei de date în doar câteva clicuri. În consecință, acest lucru permite dezvoltatorilor full-stack să construiască aplicații scalabile GraphQL pe PostgreSQL într-un timp mai scurt. Acest lucru economisește dezvoltatorilor săptămâni de codare inițială și poate împiedica erorile problematice de scurgere a datelor să ajungă la producție.

Ce problemă rezolvă Hasura în dezvoltarea API-ului?

În general, Hasura simplifică gestionarea ciclului de viață API în timpul utilizării la scară largă în producție, în special pentru API-uri complexe. Mai presus de toate, motorul GraphQL atrage dezvoltatori full-stack care au întârzieri cu proiecte de dezvoltare a API-urilor de întreprindere care utilizează bazele de date PostgreSQL existente. În mod ideal, deoarece GraphQL permite cicluri de dezvoltare API extrem de rapide, Hasura oferă o modalitate simplificată pentru organizații de a trece progresiv la GraphQL, fără a afecta aplicațiile, bazele de date sau utilizatorii existente. Pe lângă performanța sa ușoară și înaltă, motorul vine cu o interfață de administrare, permițându-vă să explorați API-urile GraphQL și să vă gestionați vizual schema bazei de date și datele.

Avantajele Hasura

În primul rând, Hasura are un model solid și stabil pentru gestionarea modificărilor sau „migrațiilor” bazei de date. Acest lucru este avantajos, deoarece gestionarea schemei bazei de date este adesea dificilă. De exemplu, sarcini precum; urmărirea modificărilor de-a lungul timpului și asocierea modificărilor schemei cu îmbunătățirile API (gestionarea schemei). În plus, lucrările de rutină, cum ar fi întreținerea de scripturi care pot implementa o nouă bază de date sau pot anula modificările, se pot dovedi plictisitoare și pot cauza erori greu de diagnosticat sau o întrerupere. Ca o notă laterală pozitivă, componentele de migrare a bazei de date Hasura sunt SQL simplu, deci portabile în afara setului de instrumente Hasura. Una peste alta, Hasura are caracteristici excelente de gestionare a schemelor și nu trebuie să scrieți cod pentru a gestiona conexiunile socket-urilor web.

În al doilea rând, motorul Hasura GraphQL facilitează preluarea datelor necesare cu o singură interogare. Face acest lucru permițându-vă să adăugați vizualizări ca relații la tabele sau alte vizualizări. În plus, permite scrierea de soluții personalizate cu schema-stitching și integrarea funcțiilor fără server sau a API-urilor de microservicii care sunt declanșate la evenimentele bazei de date. Acest lucru poate fi util și facilitează construirea de aplicații 3factor. De fapt, Hasura este un motor extrem de ușor. Privind retrospectiv, consumă doar până la 50 MB de RAM, chiar dacă deservește mai mult de 1000 de solicitări/pe secundă. O rentabilitate genială a investiției!

Mai exact, Hasura facilitează și mai mult autorizarea și autentificarea la nivel de date API. Permite conectarea la un furnizor de autentificare preferat fie prin webhook, JWT, Auth0 sau implementări personalizate. Și astfel, specificarea rolurilor pentru utilizatori, definirea cine poate accesa diferite date, de exemplu, admin, utilizatori anonimi, etc. În general, sistemul său granular de control al accesului se bazează pe structura tabelului bazei de date similară cu schema GraphQL. În plus, regulile de permisiuni personalizate sunt strict definite pe baza operațiunilor și valorilor bazei de date.

În cele din urmă, Hasura sprijină în mod strălucit paginarea eficientă cu un model simplu de offset/limită asemănător SQL. De exemplu, folosește modelul de control al accesului pentru a restricționa numărul de rânduri returnate pentru o anumită interogare. Modelul său permite reglarea limitelor după rol. De exemplu, utilizatorii care impun o rată de solicitare mult mai mare sunt limitați la limite mai mici de rânduri. Acest lucru evită stresarea bazei de date și a motorului GraphQL. În plus, în special, Hasura nu vă limitează doar la GraphQL. Puteți rula în continuare REST sau alte micro-servicii non-GraphQL împotriva tabelelor Postgres pe care le gestionează Hasura. Acest lucru este posibil cu cusătura automată a schemei Hasura. Acest lucru permite îmbinarea unui serviciu non-Hasura GraphQL și back-end pentru o singură schemă unificată, combinând noile API-uri gestionate de Hasura cu API-uri și date vechi.

Cazuri de utilizare Hasura

Potrivit pentru medii de înaltă performanță, Hasura Engine oferă viteză în timp ce automatizează implementarea GraphQL-Postgres pe bazele de date existente. În consecință, acest lucru oferă companiilor care folosesc deja Postgres o modalitate mai puțin stresantă și mai puțin stresantă de a trece la GraphQL prin conectarea tabelelor existente într-un „grafic”. Hasura se ocupă eficient de cusătura schemei, permițându-vă să aplicați cu ușurință logica de afaceri personalizată. Cu schemele GraphQL de la distanță, Hasura poate fi folosit ca o poartă de acces pentru logica de afaceri personalizată, permițându-vă să scrieți pe serverele GraphQL în limba dvs. preferată, apoi să expuneți datele la un singur punct final. În plus, Hasura are o sintaxă excelentă pentru interogări și mutații cu interogări live încorporate numite abonamente în GraphQL.

Cele câteva Limitări Hasura

Din păcate, modelul sistemului de control al accesului Hasura nu va funcționa pe deplin pentru fiecare aplicație. De exemplu, nu acceptă pe deplin autorizarea accesului API la nivelul parametrilor de intrare individuali. Ca să nu mai vorbim de faptul că este limitat la baza de date Postgres care necesită migrare în majoritatea cazurilor. Deși neglijabile, mesajele de eroare pe care API-ul GraphQL le returnează pentru cererile incorecte sunt destul de neprietenoase pentru Hasura. În caz contrar, este puțin ceea ce Hasura nu poate face, așa cum am văzut în această introducere la Hasura GraphQL Engine.

Concluzie

În concluzie, pe măsură ce GraphQL crește, va simplifica și mai mult dezvoltarea API în cadrul întreprinderilor pentru a le construi la scară web. Odată cu adoptarea rapidă pe scară largă a GraphQL într-un set divers de industrii, Hasura are potențialul de a automatiza și mai mult crearea și gestionarea API-urilor cu tehnologiile standard ale industriei, GraphQL și Postgres. Hasura simplifică crearea de backend-uri CRUD (creați, citiți, actualizați și ștergeți) GraphQL. Mai important, Hasura este de departe cea mai bună și singura opțiune dacă porniți de la zero cu un API centrat pe GraphQL și Postgres, fără a scrie cod backend. Pentru orice întrebări sau consultări cu privire la posibilitățile de întreprindere GraphQL și Hasura, nu ezitați să ne contactați. Asta este pentru introducerea noastră în Hasura GraphQL Engine.