Apollo, den greske guddommen
Apollo, verktøyselskapet bak en av de mest populære implementeringene av GraphQL, legger til ny fleksibilitet til gateway-nivået sitt som skal smøre skliene for å utvide bruken fra arbeidsgruppe til bredere bedriftsomfattende implementeringer. Og ved å rette blikket mot bedriften, endrer Apollo lisensieringen for familiejuvelene – gatewayen, eller ruternivået, som er nøkkellenken for å koble forespørsler til data.
Den nye funksjonen er en del av Apollo Federation 2.0-utgivelsen; det gjør det mer fleksibelt for team å dele, overføre eierskap og endre eller utvide de underliggende datamodellene representert av grafen. Tidligere kunne hvert element i skjemaet bare eies av et enkelt team; den nye versjonen lar flere team dele ansvaret.
Den veiledende oppfatningen er at selv om strengt eierskap kan fungere på arbeidsgruppenivå, når det utvides til bredere tverrsnitt av organisasjonen, og bredere datamengder, kan eierskapet måtte bli mer fleksibelt for å overvinne siloer. For eksempel kan det hende at teamet som i utgangspunktet definerer kundeposten, ikke nødvendigvis er teamet som eier ansvaret for posten etter hvert som den utvikler seg. Apollos v2 lemper på restriksjoner som låser eierskap for å gjøre det mulig å endre eller flytte eierskapet.
Og selvfølgelig, ettersom ansvaret deles, må styringen av endringer bli mer eksplisitt. Apollo Federation 2 legger til en funksjon for å spesifisere godkjennings-/gjennomgangsarbeidsflyter til prosessen.
En annen ny funksjon i gatewayen gjør at skjemaer lettere kan forenes uten å kreve omskriving av skjemaet. For eksempel kan selskaper som lager produkter ta individuelle produkt-SKU-er og utvide dem til familier av relaterte SKU-er; med den nye gatewayen blir det enklere å utvikle skjemaer for å støtte føderasjon.
Den andre overskriftsendringen er lisensieringen. Som Big on Data-broren George Anadiotis dekket i sitt uttømmende innlegg i fjor sommer om Apollos finansiering og opprinnelse, har Apollos forretningsmodell vært åpen kjerne. Selskapets verktøy har tre nivåer. Det er en klient hvor det skrives spørsmål; Apollo tilbyr en Studio IDE som er åpen kildekode med MIT-lisensen. Og den har en backend-server som kobler innkommende spørringer til grafen, som på samme måte er MIT-lisensiert.
Familiejuvelene, som endringene i v2 handler om, er gatewayen eller ruteren. Dette er stykket med hjernen, hvor det lages spørringsplaner som utfører alle sammenføyningene. Dette er stykket som med denne versjonen tar i bruk Elastic-lisensen, som i hovedsak forbyr kunder å lansere sine egne administrerte tjenester for utleie. Apollo valgte den elastiske lisensen fordi den var mindre kompleks enn SSPL, den MongoDB-orienterte lisensen som, ironisk nok, Elastic tok i bruk for sine familiejuveler (Elasticsearch og Kibana) tidlig i år.
OK, hvis du vil mer bakgrunn om angsten rundt åpen kildekode-lisensiering, vi har dekket deg.
Men den virkelige historien handler om GraphQL, den lille API-en som kunne. Opprinnelig som en spesifikasjon hos Facebook, er Apollo et av de kommersielle firmaene som har utviklet implementeringer av det. Til tross for navnet er GraphQL ikke nødvendigvis et grafdatabasespørringsspråk, selv om vi forventer at noen grafdatabaser vil støtte det som en grensesnitt for å forenkle spørringer. I stedet refererer grafen til GraphQL til den underliggende grafen som kartlegger måldatakilden, og løfter derfor all byrden med å spesifisere hvordan du skal koble til dataene fra klienten tilbake til serveren. I hovedsak vet grafen hvor dataene er, og derfor trenger ikke søket ditt å finne dem fysisk.
GraphQLs tidlige krav til berømmelse var med mobilapplikasjoner, som er spesielt følsomme for skravlingen involvert med REST-spørringer som ofte krever flere runder frem og tilbake for å komme til dataene. MongoDB var en av de tidligste brukerne av GraphQL da den omfavnet den som en del av Realm-mobilutviklingsplattformen.
For Apollo er det viktig å smøre skliene for føderasjon for å skalere bruken av GraphQL. Etter hvert som dataområdet blir bredere og støtter flere samfunnslag på tvers av en bedrift, kommer skjemaer til å utvikle seg raskere. Så det blir nødvendig å legge til rette for samarbeid og prosess for å støtte det. Behovet for et mer smidig rammeverk for å muliggjøre tilgang til data vokser med implementering av mikrotjenester, som på egen hånd tilfører sin del av kompleksiteten til programvareutvikling.
Det er fristende å tro at man kan representere alle, eller i det minste et bredt spekter av bedriftsdata på et enkelt kart. Riktignok er grafer mye mer fleksibel enn de rigide hierarkiske eller relasjonelle tilnærmingene til bedriftsdatamodeller som aldri kunne skaleres tidligere. Men selv om graf er et mer fleksibelt middel for kartlegging av data, er det alltid et spørsmål om hvor godt ryddige konsepter vil skalere i den virkelige verden.
De nye funksjonene er ment å møte utfordringene med å bringe det underliggende kartlegging og definisjon av skjema til, bokstavelig talt en bredere verden. Betrakt det som en overgangsrite for GraphQL.
Big Data
The State of AI in 2021: Language models, healthcare, ethics, and AI agnosticism Google Cloud Next: Meeting the bedrift der den bor AI ser mer finansiering, men trenger flere mennesker og bedre data De beste karrierene du kan starte med en informatikkgrad Data Management | Digital transformasjon | Robotikk | Internet of Things | Innovasjon | Enterprise Software