GraphQL és un gran problema: per què no és l’estàndard del sector per a la consulta de bases de dades?

Registreu-vos ara per obtenir el vostre passi virtual gratuït a la cimera de codi baix/sense codi d’aquest 9 de novembre. Escolteu els directius de Service Now, Credit Karma, Stitch Fix, Appian i molt més. Aprèn més.


GraphQL s’està convertint ràpidament en un llenguatge de consulta de referència perquè les empreses interactuïn amb les seves dades. Tot i que la gestió de dades és una de les principals preocupacions per a moltes empreses, moltes persones no entenen realment què fa GraphQL ni per què és tan popular.

De mitjana, el món genera uns 2,5 milions de bytes de dades al dia. Les empreses necessiten una manera de recollir aquestes dades i utilitzar-les de manera eficaç. Es generen moltes dades a les aplicacions (per exemple, una aplicació per a telèfons intel·ligents d’atenció al client que permet als clients dir-vos si estan satisfets o si tenen problemes i necessiten ajuda per resoldre’ls). Les aplicacions necessiten una manera d’aconseguir informació al backend; és a dir, les eines per gestionar i emmagatzemar dades. A continuació, es poden analitzar les dades per descobrir problemes i desenvolupar solucions. I, per descomptat, és bidireccional. Les aplicacions no només envien dades al backend, sinó que les aplicacions necessiten dades del backend. Per exemple, recomanacions, l’estat d’un lliurament, els saldos del compte. I per això serveix GraphQL: obtenir dades cap a i des del backend. És una API més moderna que connecta aplicacions amb backends.

Tot i que molts líders tecnològics poden haver sentit parlar de GraphQL, probablement hagin sentit molt més sobre SQL (Llenguatge de consulta estructurat). SQL és essencialment l’estàndard del sector per a la consulta de bases de dades, tot i que GraphQL està creixent en popularitat.

Com es compara GraphQL amb SQL i hi ha alguna manera d’aconseguir els avantatges d’ambdós quan es realitzen consultes?

Esdeveniment

Cimera de codi baix/sense codi

Uneix-te als principals executius d’avui a la cimera de codi baix/sense codi virtualment el 9 de novembre. Registra’t per obtenir el teu passi gratuït avui mateix.

Registra’t aquí

GraphQL vs. SQL: la visió àmplia

GraphQL té un format relativament senzill i llegible per accedir a les dades. El format únic permet una cosa anomenada “nidificació”. La nidificació és semblant a fer una pregunta dins d’una altra pregunta per obtenir una resposta més específica. Per exemple, en lloc de sol·licitar una llista de tots els gossos d’un lloc concret del refugi, podeu demanar una llista de tots els gossos i detalls imbricats de les races d’aquests gossos (trets d’un tercer, fins i tot d’un tercer font de dades del partit).

La capacitat de GraphQL per niuar consultes permet que un desenvolupador d’interfície obtingui, en una sol·licitud, la informació rellevant d’una API. Com que GraphQL és gairebé un llenguatge de consulta universal, que gestiona diferents fonts de dades amb facilitat, també podeu consultar diverses API i altres fonts de dades alhora. Així, GraphQL és el llenguatge de consulta adequat per a backends heterogenis, és a dir, backends amb diferents tipus de fonts de dades a més de bases de dades.

SQL és molt popular com a llenguatge de consulta per a bases de dades. Malauradament, no funciona per a consultes imbricades entre dades heterogènies de la mateixa manera que ho fa GraphQL. Més sintaxi d’SQL pot ser complicada. Finalment, SQL mai no va ser universal. SQL funciona molt bé per a diferents bases de dades, però no tant per a les API.

GraphQL vs. SQL en acció

Suposem que esteu treballant per reposar l’inventari de la vostra empresa i que necessiteu saber el número de seguiment i la data de lliurament prevista per a dues comandes diferents d’enviament de dues empreses diferents. GraphQL podria obtenir tota aquesta informació en una sol·licitud.

GraphQL també us mostra aquesta informació en una estructura jeràrquica que facilita veure la relació entre les dades que heu sol·licitat. En altres paraules, podeu veure que la data de lliurament del vostre paquet està relacionada amb el número de seguiment que heu rebut.

Per a SQL, potser haureu de fer una sol·licitud a la vostra base de dades per obtenir informació general sobre les dues comandes diferents. Aleshores, és possible que hàgiu d’ordenar aquesta informació per trobar els noms de les companyies de transport, seguit d’una altra sol·licitud a cada empresa de transport per obtenir números de seguiment. Finalment, en funció del número de seguiment, podeu fer una altra sol·licitud per obtenir les dates de lliurament previstes. Obtenir tota aquesta informació requeriria molt de codi i pot ser que no sigui fàcil obtenir la sintaxi correctament. Personalment he estat tractant amb bases de dades SQL durant dècades, i fins i tot sovint he de buscar la sintaxi per a consultes complexes.

Un esquema d’API GraphQL només permet un subconjunt d’operacions, depenent dels desenvolupadors que implementin aquesta API. En altres paraules, la flexibilitat que poden ser les vostres consultes depèn de la flexibilitat que siguin els desenvolupadors de l’API. Per exemple, una API només us permet cercar clients per correu electrònic. Per cercar clients per ciutat, l’aplicació hauria de reunir tots els clients i després filtrar-los un per un. Parlem de complicat.

O si esteu tractant amb dades sensibles, és possible que hàgiu de configurar les consultes i les API per factors com ara controlar qui pot accedir a les dades o quant de temps s’emmagatzemen les dades a la memòria cau (desades temporalment) al backend. Aquestes configuracions són molt difícils per a l’empresa mitjana, però ara hi ha moltes tecnologies disponibles per gestionar i configurar consultes i API de GraphQL. Aquestes tecnologies fan de GraphQL una opció viable per consultar les API, però sense aquestes tecnologies, la configuració pot ser difícil.

En canvi, SQL és més expressiu des del principi, la qual cosa significa que és més fàcil dir-li al sistema el que voleu sense molta configuració addicional. Es pot demanar fàcilment a qualsevol base de dades “per al client John Doe, doneu-me comandes l’import de les quals superi els 100 dòlars”, utilitzant una única línia de codi. SQL us donarà el que necessiteu, independentment de l’estructura de la base de dades.

La manera com m’agrada dir-ho és aquesta: GraphQL permet consultes flexibles dins del marc establert pel desenvolupador que va crear l’API. SQL permet la consulta universal en qualsevol model de base de dades. Per tant, si esteu consultant principalment bases de dades, SQL farà la feina bé.

Hi ha alguna manera de superar la bretxa?

Què passaria si poguéssiu aprofitar els atributs expressius d’SQL i la flexibilitat de GraphQL alhora? Hi ha tecnologies disponibles que afirmen fer-ho, però és poc probable que es facin populars perquè acaben sent incòmodes i complexes. La incomoditat sorgeix d’intentar forçar les construccions SQL a GraphQL. Però són diferents llenguatges de consulta amb diferents propòsits. Si els desenvolupadors han d’aprendre a fer construccions SQL a GraphQL, també podrien utilitzar SQL i connectar-se directament a la base de dades.

Tanmateix, no tot està perdut. Creiem que GraphQL es farà més expressiu amb el temps. Hi ha propostes per fer GraphQL més expressiu. Aquests poden arribar a ser estàndards. Però fonamentalment, SQL i GraphQL tenen diferents visions del món, respectivament: backends uniformes vs. diversos backends, taules vs. dades jeràrquiques i consulta universal vs. consulta limitada. Per tant, tenen finalitats diferents.

GraphQL, malgrat la seva popularitat com a llenguatge de consulta de l’API, no desbancarà SQL com a llenguatge principal per a l’accés a la base de dades.

Anant Jhingran és CEO i cofundador de StepZen.

Data DecisionMakers

Benvingut a la comunitat VentureBeat!

DataDecisionMakers és on els experts, inclosos els tècnics que treballen amb dades, poden compartir coneixements i innovació relacionats amb les dades.

Si voleu llegir idees d’avantguarda i informació actualitzada, bones pràctiques i el futur de la tecnologia de dades i dades, uniu-vos a nosaltres a DataDecisionMakers.

Fins i tot et pots plantejar contribuir amb un article propi!

Llegiu més de DataDecisionMakers

Leave a Comment

Your email address will not be published. Required fields are marked *