Apollo, de Griekse godheid
Apollo, het gereedschapsbedrijf achter een van de meest populaire implementaties van GraphQL, voegt nieuwe flexibiliteit toe aan zijn gateway-laag die de skids zou moeten smeren voor het uitbreiden van de acceptatie van werkgroep naar bredere bedrijfsbrede implementaties. En door zijn zinnen te zetten op de onderneming, verandert Apollo de licenties voor de familiejuwelen: de gateway of routerlaag, dat is de belangrijkste schakel bij het koppelen van query's aan gegevens.
De nieuwe mogelijkheid maakt deel uit van de Apollo Federation 2.0-release; het maakt het voor teams flexibeler om te delen, eigendom over te dragen en de onderliggende gegevensmodellen die door de grafiek worden weergegeven, aan te passen of uit te breiden. Voorheen kon elk element van het schema alleen eigendom zijn van één team; met de nieuwe versie kunnen meerdere teams de verantwoordelijkheid delen.
Het leidende idee is dat, hoewel strikt eigendom op werkgroepniveau zou kunnen werken, wanneer het zich uitbreidt tot bredere dwarsdoorsneden van de organisatie en grotere delen van gegevens, eigendom mogelijk flexibeler moet worden om silo's te doorbreken. Het team dat in eerste instantie het klantrecord definieert, hoeft bijvoorbeeld niet noodzakelijkerwijs het team te zijn dat verantwoordelijk is voor het record terwijl het zich ontwikkelt. Apollo's v2 versoepelt de beperkingen die eigendom blokkeren, zodat dat eigendom kan worden gewijzigd of verschoven.
En natuurlijk, aangezien de verantwoordelijkheid wordt gedeeld, moet het beheer van veranderingen explicieter worden. Apollo Federation 2 voegt een functie toe voor het specificeren van goedkeurings-/beoordelingsworkflows aan het proces.
Een andere nieuwe functie in de gateway zorgt ervoor dat schema's gemakkelijker kunnen worden gefedereerd zonder dat het schema op grote schaal moet worden herschreven. Bedrijven die producten maken, kunnen bijvoorbeeld individuele product-SKU's nemen en deze uitbreiden tot families van gerelateerde SKU's; met de nieuwe gateway wordt het gemakkelijker om schema's te ontwikkelen om federatie te ondersteunen.
De andere hoofdverandering is de licentie. Zoals Big on Data bro George Anadiotis afgelopen zomer in zijn uitgebreide post over Apollo's financiering en oorsprong beschreef, was het bedrijfsmodel van Apollo een open kern. De tooling van het bedrijf heeft drie niveaus. Er is een client waar queries worden geschreven; Apollo biedt een Studio IDE die open source is met de MIT-licentie. En het heeft een back-endserver die inkomende query's verbindt met de grafiek, die op dezelfde manier een MIT-licentie heeft.
De familiejuwelen, waar de veranderingen in v2 over gaan, is de gateway of router. Dit is het stuk met de hersenen, waar queryplannen worden gemaakt die alle joins uitvoeren. Dit is het onderdeel dat met deze versie de Elastic-licentie overneemt, die klanten in wezen verbiedt om hun eigen beheerde services te huur te lanceren. Apollo koos voor de elastische licentie omdat deze minder complex was dan SSPL, de MongoDB-georiënteerde licentie die, ironisch genoeg, Elastic begin dit jaar heeft aangenomen voor zijn familiejuwelen (Elasticsearch en Kibana).
Ok, als je wilt meer achtergrondinformatie over de angst rond open source-licenties, we hebben het voor je.
Maar het echte verhaal gaat over GraphQL, de kleine API die dat zou kunnen. Apollo is ontstaan als een specificatie bij Facebook en is een van de commerciële bedrijven die implementaties ervan hebben ontwikkeld. Ondanks zijn naam is GraphQL niet per se een zoektaal voor grafische databases, hoewel we verwachten dat sommige grafische databases het zullen ondersteunen als een front-end voor het vereenvoudigen van query's. In plaats daarvan verwijst de grafiek van GraphQL naar de onderliggende grafiek die de doelgegevensbron in kaart brengt en neemt daarom alle lasten weg van het specificeren hoe verbinding moet worden gemaakt met de gegevens van de client naar de server. In wezen weet de grafiek waar de gegevens zich bevinden, en daarom hoeft uw zoekopdracht deze niet fysiek te vinden.
GraphQL's vroege aanspraak op roem was met mobiele applicaties, die vooral gevoelig zijn voor het geratel dat gepaard gaat met REST-query's die vaak verschillende rondes heen en weer vereisen om bij de gegevens te komen. MongoDB was een van de eerste gebruikers van GraphQL toen het het omarmde als onderdeel van zijn Realm mobiele ontwikkelingsplatform.
Voor Apollo is het smeren van de skids voor federatie essentieel voor het opschalen van het gebruik van GraphQL. Naarmate het gegevensdomein breder wordt en meer lagen van de bevolking in een onderneming ondersteunt, zullen schema's sneller evolueren. En dus wordt het noodzakelijk om samenwerking te faciliteren en processen te ondersteunen. De behoefte aan een flexibeler raamwerk om toegang tot gegevens mogelijk te maken, groeit met de implementatie van microservices, die op zichzelf hun deel van de complexiteit aan softwareontwikkeling toevoegen.
Het is verleidelijk om te denken dat je alle, of op zijn minst een groot aantal bedrijfsgegevens op één kaart zou kunnen weergeven. Toegegeven, grafiek is veel flexibeler dan de rigide hiërarchische of relationele benaderingen van bedrijfsgegevensmodellen die in het verleden nooit konden worden geschaald. Maar hoewel grafiek een flexibeler middel is om gegevens in kaart te brengen, is het altijd de vraag hoe goed opgeruimde concepten in de echte wereld zullen schalen.
De nieuwe functies zijn bedoeld om de uitdagingen aan te gaan die gepaard gaan met het brengen van de onderliggende mapping en definitie van schema naar, letterlijk een grotere wereld. Beschouw het als een overgangsrite voor GraphQL.
Big Data
De staat van AI in 2021: taalmodellen, gezondheidszorg, ethiek en AI-agnosticisme Google Cloud Volgende: voldoen aan de onderneming waar het leeft AI ziet meer geld, maar heeft meer mensen en betere data nodig De beste carrières die je kunt starten met een informatica-diploma Data Management | Digitale transformatie | Robotica | Internet der dingen | Innovatie | Bedrijfssoftware