GraphQL REST-aurantissa

Maukas esittely GraphQL: ään

On keskiviikkoilta, toinen suosittu tapahtuma järjestetään suosikkini tapahtumatilassa: REST-aurantti.

Keskustelujen jälkeen osallistujat voivat saada erilaisia ​​ruokia eri reiteillä.

Eri reittejä salaattien tai hampurilaisten saamiseksi REST-aurantissa.

Heillä on yleensä samat kaksi vaihtoehtoa: avokadosalaatti ja katkarapuhampurilainen. Avokadosalaatti ja katkarapuhampurilainen. Mutta mitä minä todella nälän, on katkarapuisalaatti! Mutta valitettavasti ei ole GET / salaatteja? With = katkarapuja reittiä. Joten mitä voin tehdä?

Saan katkarapuja hampurilaisista, tietysti!

Joten menen GET / salaatit-reitille ja jonotan sitten hakea kolme hampurilaista GET / hampurilaisista. Menen vapaalle istuimelle pöydässä, poistan katkaravut hampurilaisista ja heitän loput pois. Ja poika olen onnellinen siitä, että saan katkarapuisalaattini.

Ali- ja liikahaku

Sen jälkeen kun olen saanut katkarapuisalaattini valmiiksi, olen surullinen. Ei vain tuhlannut aikaa seisomaan rivillä kahdesti sijasta, että vietin aikaa ystävien kanssa, vaan piti heittää pois paljon ruokaa.

Mutta ainakin minulla on nyt hieno esimerkki selittää ali- ja ylimääräisten käsitteiden käsitteet. Tehdään koodaus!

(Löydät kaikki koodiesimerkit osoitteesta github.com/gr2m/restaurant-graphql)

Tässä on yksinkertainen Node.js-palvelin, joka on rakennettu expressillä, ja se paljastaa kaksi reittiä salaateille ja hampurilaisille. Molemmat palauttavat oletuksena yhden salaatin / hampurilaisen ja hyväksyvät valinnaisen? Count kyselyparametrin hakeaksesi useamman kuin yhden yhdellä pyynnöllä

const express = vaadi (“express”);
const app = express ();
// määrittele salaatti ja hampurilainen
const-salaatti = {avokado: 1, mango: 1, tomaatti: 0,2, koriste: totta, sipuli: totta};
const hampurilainen = {pullat: 2, katkarapu: 1, muna: 1, salaatti: 2,5, mayo: totta};
// määrittele 100 kpl taulukot
const-salaatit = uusi Array (100) .täyttö (salaatti);
consthampurilaiset = uusi ryhmä (100) .täyttö (hampurilainen);
// määritä reitit valinnaisella laskukyselyparametrilla
app.get (“/ salaatit”, ({kysely: {count}}, res) => res.json (get (salaatit, count)));
app.get (“/ burgers”, ({kysely: {count}}, res) =>
 res.json (hanki (hampurilaiset, laske))
);
// auttajamenetelmä, jotta saadaan osio taulukosta laskennan perusteella
const get = (mitä, laske) => mitä.splice (0, parseInt (count) || 1);
// Käynnistä palvelin localhost: 4000
app.listen (4000);

Avaaminen http: // localhost: 4000 / salaatit näyttää tältä

Firefox näyttää JSON-vastaukset mukavasti oletuksena

Vaihtaminen asiakaspuolelle.

(Huomaa: jos saat selaimessa virheen, kokeile Chromea, koska sillä on paras async-tuki / odota, mikä tekee koodiesimerkeistä paljon yksinkertaisempia)

// auttajatoiminto GET-pyynnön lähettämiseen tietylle reitille
toiminto get (polku) {
  paluu (odota hakemista (`$ {location.protocol} // $ {location.host} $ {path}`)). json ()
}
anna [salaatti] = odottaa saavansa ("/ salaatit");
// salaatti: {"avokado": 1, "mango": 1, "tomaatti": 0,2, "arugula": totta, "sipuli": totta}
poista salad.tomato;
// TODO: Pyydä joukkuetta luettelemaan tomaatti suolareittivalikkoon!
anna hampurilaisten = odottaa saavan ("/ hampurilaiset? laskee = 3");
// hampurilaiset: [
// {"pullat": 2, "katkarapu": 1, "muna": 1, "salaatti": 2,5, "mayo": totta},
// {"pullat": 2, "katkarapu": 1, "muna": 1, "salaatti": 2,5, "mayo": totta},
// {"pullat": 2, "katkarapu": 1, "muna": 1, "salaatti": 2,5, "mayo": totta}]
Object.assign (salaatti, {
  katkaravut: burgers.reduce (
    (numShrimps, burger) => numShrimps + burger.shrimp,
    0
  )
});
// salaatti: {"avokado": 1, "mango": 1, "arugula": totta, "sipuli": tosi, katkarapu: 3}

Saan salaatin hakemalla GET / salaatit-reitin. Tämän ensimmäisen pyynnön jälkeen minusta puuttuu edelleen aineosia, joten minun on lähetettävä uusi pyyntö. Tätä kutsutaan alahakuksi.

Sitten noutaan 3 hampurilaista GET / hampurilaiset? Count = 3. Sen jälkeen vähennä hampurilaiset katkarapujen kokonaismäärään. Tarvitsin 3 katkarapuja katkarapuisalaattilleni, mutta sen sijaan sain 3 hampurilaista kaikilla ainesosilla. Tätä kutsutaan liikahakuksi.

Yhteenvetona

  1. Under-fetching
    GET / salaatit saivat minut salaatiksi, mutta ei katkarapuja
  2. Yli-fetching
    GET / hampurilaiset? Count = 3 sai minulle katkaravut, mutta minun on heitettävä loput hampurilaiset pois.

Esittelyssä GraphQL

REST-aurinkoinen tiimi on erittäin ystävällisiä ja ympäristöystävällisiä ihmisiä. He eivät halua, että ruoka menee hukkaan, ja tutkimuksen jälkeen he saavat tiedon GraphQL: stä, joka näyttää ratkaisevan ongelman täydellisesti.

Seuraavaa kokousta varten joukkue perustaa kolmannen reitin: POST / graphql.

GraphQL: lle ei tarvita kirjallista valikkoa, sen sijaan he perustavat terminaalin, jossa on sulautettu dokumentaatio, jota osallistujat voivat käyttää kyselyn kirjoittamiseen ja lähettämiseen. He kutsuvat sitä GraphQL Query-aitor 3000: ksi!

GraphQL Query-aitor 3000 on vain hieno nimi GraphiQL: lle (huom. I), yksinkertainen verkkolomake lähettää GraphQL-kyselyitä sisäänrakennetulla automaattisella täydennyksellä. GraphiQL on vaikea ääntää, jos et tiedä sitä, joten ihmiset antavat sille erilaisia ​​nimiä, kuten GitHubin tutkija. Se lausutaan muuten kuin “graafinen” :)

GraphiQL-verkkosovellus

Graphiql näyttää kaikki käytettävissä olevat vaihtoehdot kirjoittaessasi. Ei enää tarvitse arvata, ei enää etsiä omaisuuden nimiä ja mikä tärkeintä, ei enää synkronointidokumentaatiosta, koska dokumentaatio luodaan samasta kaavasta, jota palvelin ja asiakkaat käyttävät. Esimerkiksi näet “tomaatti” automaattisen täydennyksen pudotusvalikossa GraphiQL: ssä, vaikka sitä puuttui GET / salaatit-reitin valikosta.

Täydellinen kysely kaikkien ainesosien, paitsi tomaatin, pyytämiseksi yhdestä salaatista ja vain 3 kattohampurilaisen katkarapuja näyttää tältä

{
  salaatit {
    avokado
    rucola
    mango
    sipuli
  }
  hampurilaiset (lukumäärä: 3) {
    katkarapu
  }
}

Palvelimen vastaus seuraa kyselyni puurakennetta, ja se sisältää juuri sen, mitä pyysin, ei vähemmän, enempää.

{
  "data": {
    "salaatit": [{"avokado": 1, "arugula": totta, "mango": 1, "sipuli": totta}],
    "hampurilaiset": [{"katkarapu": 1}, {"katkarapu": 1}, {"katkarapu": 1}]
  }
}

GraphQL: tarvitsemasi on mitä saat.

Tässä on muutama tosiasia GraphQL: stä:

  • Kuten REST, myös GraphQL on määritys, ei työkalu.
  • Se on kieliagnostinen sekä palvelimille että asiakkaille
  • GraphQL API on rakennettu skeeman ympärille
  • Kaavio on yksinkertainen tekstiasiakirja, jota käytetään asiakkaan ja palvelimen välillä.

Hyödynnämme mallin sovellusohjelman GraphQL-skeemassa minuutissa. Haluan kuitenkin korostaa, että GraphQL on kielen agnostiikka, koska sitä nähdään yleensä yhdessä Reaktin ja Node.js: n kanssa. Syynä on, että sekä React että GraphQL ovat Facebookin hankkeita. Vaikka React on todellinen JavaScripti-kirjasto, GraphQL on vain määritelmä, toteutuksia on jo jo monilla ohjelmointikielillä.

Luokaamme nyt yksinkertainen tekstitiedosto nimeltä schema.graphql. GraphQL-skeeman on noudatettava mainitun GraphQL-määrityksen syntaksia. Esimerkki-sovelluksessamme koko skeema on vain 20 riviä pitkä:

kirjoita kysely {
  hampurilaiset (lukumäärä: Int = 1): [hampurilainen]
  salaatit (määrä: Int = 1): [salaatti]
}
tyyppi hampurilainen {
  pullat: Int!
  katkarapu: Kellu!
  muna: kellu!
  salaatti: Boolean!
  mayo: Boolen!
}
tyyppinen salaatti {
  avokado: Kellu!
  mango: Kellu!
  tomaatti: Kellu!
  arugula: Boolen!
  sipuli: Boolen!
}

Kyselytyyppi määrittelee sen, mitä voi pyytää juuri, tässä tapauksessa se on salaatteja ja hampurilaisia. Valinnainen lukumäärä kokonaisluku voidaan siirtää. Sen oletusarvo on 1. Voit nähdä, että se heijastuu yllä esitetyssä GraphQL-kyselyssä.

salaatit palauttaa taulukon tyyppisillä salaatilla. Salaattityyppi määrittelee kaikki sen ainesosat. Esimerkiksi avokado on kelluva numero, joka sallii desimaalin tarkkuuden. Sama mangon, kurkun ja tomaatin kanssa. Sipuli on boolean, se voi olla joko totta tai vääriä.

Burgeripullot ovat tyyppiä Int, koska kuka haluaa hampurilaisen, jolla on puoli pullaa? Katkarapu ja muna ovat kelluvia, salaatti ja mayo ovat boolaisia.

Palvelimella koodin lisäykset ovat seuraavat.

const {readFileSync} = vaadi ("fs");
const bodyParser = vaatia ("body-parser");
const {graphqlExpress, graphiqlExpress} = vaadi ("apollo-server-express");
const {makeExecvableSchema} = vaadi ("graphql-tools");
const schema = makeExecvableSchema ({
  typeDefs: readFileSync ("schema.graphql", "utf8"),
  päättäjät: {
    Kysely: {
      salaatit: (_, {count}) => hanki (salaatit, laske),
      hampurilaiset: (_, {count}) => saa (hampurilaiset, laske)
    }
  }
});
app.use ("/ graphql", bodyParser.json (), graphqlExpress ({schema}));
app.use ("/ graphiql", graphiqlExpress ({endpointURL: "/ graphql"}));

Voit nähdä koko koodin osoitteessa github.com/gr2m/restaurant-graphql/tree/master/02-graphql.

Suurimman osan työstä suorittavat kaksi ensin asennettavaa npm-moduulia: apollo-server-express ja graphql-tool.

Schema.graphql on muutettava JavaScript-esitykseksi, jotta sitä voidaan käsitellä / graphql-reittinkäsittelyohjelmassa. Luin raa'an tiedoston ja siirrän sen typeDefs-ominaisuutena makeExecvableSchema-toimintoon.

Toinen ominaisuus, resolvers, määrittelee kyselyratkaisut, jotka toimivat samalla tavalla kuin reitinkäsittelijät. Käytän tämän viestin alussa ensimmäisessä server.js-koodissa näkyvää get helperia palauttaaksesi viipaletta salaatteja tai hampurilaisia, valinnaisen count-argumentin perusteella.

Sitten lopuksi määrittelen GraphQL-väliohjelmiston, joka paljastaa POST / graphql-reitin, sekä GraphiQL-verkkosovelluksen osoitteessa / graphiql.

Lähetä kysely JSON-objektin `kysely`-avaimen` / graphql` -päätepisteeseen.

// auttajatoiminto, joka lähettää POST-pyynnön tietylle reitille
async-toiminnon viesti (polku, data) {
  palaa (odota noutaa (`$ {location.protocol} // $ {location.host} $ {path}`, {
    menetelmä: 'post',
    runko: JSON.stringify (data),
    otsikot: {
      'Sisältötyyppi': 'sovellus / json'
    }
  })). Json ()
}
anna {data: {salaatit: [salaatti], hampurilaiset}} = odota viestiä ('/ graphql', {
  kysely: `{
    hampurilaiset (lukumäärä: 3) {
      katkarapu
    }
    salaatit {
      avokado
      rucola
      mango
      sipuli
    }
  } `
})
// salaatti: {"avokado": 1, "mango": 1, "arugula": totta, "sipuli": totta}
// hampurilaiset: [{"katkarapu": 1}, {"katkarapu": 1}, {"katkarapu": 1}]
Object.assign (salaatti, {
  katkaravut: burgers.reduce ((numShrimps, burger) => numShrimps + burger.shrimp, 0)
})
// salaatti: {"avokado": 1, "mango": 1, "arugula": totta, "sipuli": tosi, katkarapu: 3}

Vastaus palauttaa tarkalleen tarvitsemani ainesosat, minun on vain vähennettävä hampurilaiset kolmeksi katkarapuksi ja osoitettava se salaattiesineelle.

Yhteenvetona

  • GraphQL API on yleensä vain toinen REST-päätepiste, esim. POST / kuvaaja
  • Kysely purkaa tietopuun saadaksesi tarkalleen mitä tarvitaan
  • palvelimen vastaus vastaa kyselyn puurakennetta

Jee! Voin nauttia avokado-katkarapuisalaattistani hyvässä omatunnossa.

Pysyvät kyselyt

Seuraavassa kokouksessa kaikki haluavat kokeilla GraphQL Query-aitor 3000: ta. Tuloksena on erittäin pitkä rivi

Pitkät viivat GraphQL-päätteessä

Saadaksesi tarkalleen mitä haluamme, on hienoa, mutta kyselyn kirjoittaminen kestää joka kerta paljon kauemmin kuin vain hampurilaisen hakeminen GET / hampurilaisilta. Ja lähetettyään POST / graphql-pyynnön, palvelimen on käsiteltävä uusi tilaus paikan päällä.

REST-aurant -tiimi kokoontuu taas yhteen ja pohtii ratkaisua, jolla GraphQL-kyselyjen postitus ja käsittely voidaan tehostaa. Ja he keksivät ratkaisun: kysymysten muistaminen! Aina kun joku lähettää kyselyn, häneltä kysytään, haluavatko se muistaa seuraavan kerran ja saada vastineeksi viitetunnuksen.

Tiimi lähettää myös sähköpostin ennen seuraavaa tapahtumaa, jossa pyydetään osallistujia ennakkorekisteröimään kyselyt. Tällaisen ennakkotiedon avulla joukkue voi jo valmistaa osan ruoasta, mikä myös lyhentää käsittelyaikaa.

Pysyvät kyselyt ovat kyselyjonoja, jotka on tallennettu yksilöllisellä tunnuksella avain- / arvovarastoon. Palvelinesimerkissäni luon persistent-queries.js, joka määrittelee yhden kyselyn tunnuksella 1:

module.exports = {
  1: `{
  hampurilaiset (lukumäärä: 3) {
    katkarapu
  }
  salaatit {
    avokado
    rucola
    mango
    sipuli
  }
} `
};

Palvelimella minun on lisättävä muutama rivi ladataksesi persistent-queries.js-tiedoston ja lisätä väliohjelmisto, joka tarkistaa, onko id-ominaisuus postitettu.

const persistentQueries = vaadi ("./ jatkuva kysely");
app.use ("/ graphql", bodyParser.json (), (req, res, next) => {
  if (jatkuneetQueries [req.body.id]) {
    req.body.query = pysyvätQueries [req.id];
  }
  Seuraava();
});

Jos tunnus on postitettu ja jos on olemassa pysyvä kysely, jolla on läpäissyt tunnus, aseta kysely tälle tunnukselle pysyvien kyselyjen varastosta ja jatka kyselyn käsittelyä kuten aiemmin.

Minun ei enää tarvitse lähettää kyselyä, vaan postitan vain tunnukseni, joka on yksi. Jotta saan saman tuloksen kuin yllä selaimessa on esitetty, minun ei enää tarvitse lähettää täydellistä kyselyä:

anna {data: {salaatit: [salaatti], hampurilaiset}} = odottaa viestiä ('/ graphql', {
  tunnus: 1
})

Tulos on sama kuin aiemmin, mutta pyynnön koko on minimaalinen verrattuna. Tällä voi olla suuria suorituskykyvaikutuksia, koska GraphQL-kyselystä voi tulla erittäin monimutkainen ja siksi pyynnöstä tulee suuri. Ja ylävirtayhteys on yleensä paljon huonompi kuin myös alavirtayhteys.

REST-aurant -tiimille on hienoa tietää kyselyitä etukäteen. Kyselyt voidaan esitäyttää ja tiedot voidaan välimuistiversioissa paremmin. Jotkut GraphQL-sovellusliittymät jopa estävät pysymättömät kyselyt kokonaan turvallisuuden parantamiseksi ja tehokkuuden maksimoimiseksi.

Yhteenvetona

  • Pysyvät kyselyt eivät ole osa GraphQL-määritystä, mutta yleisiä toteutustietoja
  • Pysyvät kyselyt tallennetaan palvelimelle, asiakkaat lähettävät vain kyselytunnuksia
  • Vain tunnuksen lähettäminen monimutkaisen kyselyn sijaan pienentää pyynnön kokoa
  • Pysyvät kyselyt voidaan esikääntää palvelimella
  • Turvallisuuden parantamiseksi pysyvät kyselyt voidaan poistaa kokonaan käytöstä

mutaatiot

REST-aurantin suosio kasvaa ja useimmiten tapahtumasta loppuu ruoka ennen kuin kaikki voisivat purra. Toistaiseksi ateriapalvelu on toimittanut 100 salaattia ja 100 hampurilaista, mutta joukkue päättää, että he palkkaavat kokkausryhmän, joka voi luoda lisää hampurilaisia ​​ja salaatteja kasvavan kysynnän tyydyttämiseksi.

Mutaatiot ovat osa GraphQL-eritelmää ja ne on määritettävä
GraphQL-skeemassa. Se on vain 4 ylimääräistä riviä

tyypin mutaatio {
  addBurgers (määrä: Int = 1): Int
  addSalads (määrä: Int = 1): Int
}

Lisää ensin mutaatio salaattien lisäämiseksi. Mutaatio hyväksyy valinnaisen laskentaperusteen, joka on oletusarvo 1. Mutaatio tuottaa kokonaisluvun, joka on käytettävissä olevien salaattien kokonaismäärä. Sama hampurilaisilla.

GraphQL-kysely, joka lisää salaattia ja 3 hampurilaista, näyttää tältä:

mutaatio {
  addSalads
  addBurgers (määrä: 3)
}

Mutaation on alkava mutaation avainsanalla. Voit lähettää useita mutaatioita yhdessä pyynnössä, mikä on toinen etu REST-sovellusliittymiin nähden. Et voi yhdistää mutaatiota kyselyyn, mutta voit määritellä mutaatiovasteen, jos haluat.

Edellä olevalle kyselylle vastaus näyttää tältä

{
  "data": {
    "addSalads": 1,
    "addBurgers": 3
  }
}

Asetimme palvelinkoodissa salaatit ja hampurilaiset tyhjiksi taulukkoiksi ja muokkaamme resolversio-objektia Mutaatio-ominaisuudella:

// aloita tyhjillä salaatti- ja hampurilarakenteilla nyt
const-salaatit = [];
const hampurilaiset = [];
// lisää mutaation ratkaisijat
const schema = makeExecvableSchema ({
  typeDefs: readFileSync ("schema.graphql", "utf8"),
  päättäjät: {
    Kysely: {
      salaatit: (_, {count}) => hanki (salaatit, laske),
      hampurilaiset: (_, {count}) => saa (hampurilaiset, laske)
    },
    Mutaatio: {
      addSalads: (_, {count}) => {
        salaatit.push (... uusi Array (määrä) .täyttö (salaatti));
        palauta salaatit.pituus;
      },
      addBurgers: (_, {count}) => {
        hampurilaiset.push (... uusi taulukko (määrä) .täyttö (hampurilainen));
        paluuhampurilaiset.pituus;
      }
    }
  }
});

AddSalads- ja addBurgers-funktiot kutsutaan count-argumentilla, jonka oletusarvo on 1, kuten kaaviossa on määritelty. Lisää yksi tai useita salaatteja / hampurilaisia ​​laskentaperusteen perusteella. Molemmat toiminnot palauttavat sitten vastaavan taulukon pituuden.

Mutaation lähettäminen selaimesta on hyvin samanlainen kuin kyselyn lähettäminen:

odota viestiä ('/ graphql', {
  kysely: `mutaatio {
    addSalads
    addBurgers (määrä: 3)
  } `
})

Yhteenvetona

  • Mutaatioita käytetään tietojen luomiseen, päivittämiseen tai poistamiseen.
  • Useita mutaatioita voidaan lähettää yhdellä pyynnöllä. Ne käsitellään peräkkäin.
  • Mutaatioita ei voida yhdistää kyselyihin, mutta mutaatiovasteet voidaan suodattaa

GraphQL-tilaukset

Kun REST-aurantti ei ole salaattia tai hampurilaisia, on melko ärsyttävää olla linjan edessä ja kysyä toistuvasti: ”Voiko salaatti vielä olla?”. Sen sijaan haluan palvelimen ilmoittavan minulle, kun saatavilla on tarpeeksi ruokaa kyselyni täyttämiseksi. Tämä on yksi yleinen tapaus tilauksiin.

Tilaaminen on GraphQL: n kolmas operaatiotyyppi. GraphiQL on sisäänrakennettu
tuki verkkokaupoissa oleville tilauksille, ne voidaan lähettää samalla tavalla
kuten kyselyt ja mutaatiot. Kun lähetys on suoritettu, palvelin vastaa, että tiedot näkyvät muutoksen tapahtuessa. Joten tehdään muutokset!

Vasemmalla tilaus näyttää päivitykset oikealla olevista mutaatioista.

Jätän tilauksen sellaisena kuin se on selaimessa, kun taas POSTing mutaatioita toisessa. Heti sen jälkeen kun olen postittanut mutaatiot, numerot ovat päällä
ensimmäinen ikkuna muuttuu vastaavasti.

Katsotaanpa, miten toteutus näyttää.

Schema.graphql: n lisäykset ovat jälleen melko yksinkertaisia:

tyyppi Tilaus {
  foodAdded: Tilastot
}
tyyppi Tilastot {
  hampurilaiset: Int
  salaatit: Int
}

FoodAdded -tilausta kutsutaan tyyppitilastoilla, joilla on kokonaislukuominaisuudet käytettävissä olevien salaattien ja hampurilaisten kokonaismäärälle.

Palvelimen lisäykset ovat hieman monimutkaisempia:

// lataa tilauksiin tarvittavat ylimääräiset kirjastot
const {suorita, tilaa} = vaadi ("graphql");
const {SubscriptionServer} = vaadi ("Subsmissions-transport-ws");
const {PubSub} = vaadi ("graphql-tilaukset");
const pubsub = uusi PubSub ();
const getStats = () => ({salaatit: salaatit.pituus, hampurilaiset: hampurilaiset.pituus});
const schema = makeExecvableSchema ({
  typeDefs: readFileSync ("schema.graphql", "utf8"),
  päättäjät: {
    Kysely: {
      salaatit: (_, {count}) => hanki (salaatit, laske),
      hampurilaiset: (_, {count}) => saa (hampurilaiset, laske)
    },
    Mutaatio: {
      addSalads: (_, {count}) => {
        salaatit.push (... uusi Array (määrä) .täyttö (salaatti));
        // julkaise ruokaLisätty ja lähetä tilastot
        pubsub.publish ("foodAdded", {foodAdded: getStats ()});
        palauta salaatit.pituus;
      },
      addBurgers: (_, {count}) => {
        hampurilaiset.push (... uusi taulukko (määrä) .täyttö (hampurilainen));
        // julkaise ruokaLisätty ja lähetä tilastot
        pubsub.publish ("foodAdded", {foodAdded: getStats ()});
        paluuhampurilaiset.pituus;
      }
    },
    // lisää Tilaus-ominaisuus skeeman ratkaisijoihin
    Tilaus: {
      ruokaLisätty: {
        tilaa: () => pubsub.asyncIterator ("foodAdded")
      }
    }
  }
});
// lisää subscriptionsEndpoint / graphiql-väliohjelmaan
app.use (
  "/ Graphiql",
  graphiqlExpress ({
    endpointURL: "/ graphql",
    subsmissionsEndpoint: "ws: // localhost: 4000 / tilaukset"
  })
);
// Luo uusi palvelin-ilmentymä sovelluksen.listen (4000) sijasta
const-palvelin = createServer (app);
server.listen (4000);
// ... joka voidaan siirtää SubscriptionServer-rakentajalle
uusi SubscriptionServer (
  {kaava, suorita, tilaa},
  {polku: "/ tilaukset", palvelin}
);

Voit nähdä koko koodin osoitteessa https://github.com/gr2m/restaurant-graphql/tree/master/05-graphql.

GraphQL-tilaus työntää tietoja asiakkaalle, kun muutos tapahtuu sen sijaan, että asiakas veisi sitä muutoksen odottamiseen tarkoitetun aikavälin perusteella. Toteutuksen ytimessä ovat moduulit tilaukset-kuljetus-ws ja graphql-tilaukset. Jälkimmäinen antaa meille PubSubin, jota käytämme foodAdded-tapahtuman julkaisemiseen molemmissa mutaatioissamme. Sitten Palautamme tilauksenratkaisussa asynkronisen iteraattorin, joka työntää siirretyn datan foodAdded-tapahtumaan avoimen verkkopistorasian kautta. Välitämme kootun kaavion uudelle SubscriptionServer-palvelimelle, joka toteuttaa verkkoyhteyden reitin.

Tiedän, että siellä on melko paljon ottamista, mutta se on myös hella viileä, kun se toimii :)

Yhteenvetona

  • Kun odotat muutoksia, tilaat tietovirran sen sijaan, että pyydät tietoja aikavälin perusteella.
  • Palvelin julkaisee tiedot heti, kun ne ovat saatavilla.

Nälkäinen?

  • Tarkastele ja sekoita esimerkkisovellusta häiriöiden avulla
  • Katso tämä viesti näytönohjauksena live-koodauksella
  • Tutustu lähdekoodiin
  • Seuraa minua twiitissä saadaksesi lisää GraphQL-herkkuja