Accentsconagua
Share
Hva du skal skapeI disse veiledningene vil jeg vise deg hvordan du lager og samhandler med en GraphQL-database ved hjelp av AWS AppSync og React Native. Denne appen har funksjonalitet i sanntid og frakoblet, noe vi kommer ut av esken med AppSync. I dette innlegget kommer vi til å begynne med å sette opp back-end med AppSync.
En god ting om AppSync er at den bruker GraphQL-en åpen standard og et kraftig nytt paradigme for web og mobil back-end. Hvis du vil lære mer om GraphQL, hvordan det skiller seg fra REST APIer, og hvordan det kan gjøre jobben din som en apputvikler enklere, sjekk ut noen av GraphQL-innholdet her på Envato Tuts+.
I disse innleggene skal vi bygge en reiseprogram som heter Cities. Har du noen gang sett på et show på favorittmatskanalen din og sett en fantastisk matbil, eller snakket med en venn som nettopp kom tilbake fra en tur og var veldig spent på Owl Bar hun besøkte? Vel, ikke mer, vi skal bygge en app for deg å holde tritt med alle de kule stedene du vil besøke, så vel som byene der de befinner seg.
Denne appen vil demonstrere og implementere all funksjonalitet du trenger for å bygge en real-world, full-stack React Native og GraphQL-applikasjon.
Ta en titt på eksempelprosjektets GitHub repo for å se den fullførte appen og følge med.
AppSync tilbyr en enkel måte å komme seg opp i med en skalerbar grafikkserver i sanntid uten å måtte opprette og vedlikeholde alt på egen hånd.
Innenfor AppSync-konsollen vil vi gjøre alt fra å lage vårt GraphQL-skjema for å levere vår database og resolvere. Konsollen har også Graphiql satt opp, slik at vi kan teste og spørre vår database uten ekstra oppsett.
Vi vil implementere denne konfigurasjonen på klienten vår, som vil gi oss en sømløs måte å samhandle med GraphQL endpoint på!
AppSync vil tillate deg å bruke en av tre resolvertyper rett ut av esken: DynamoDB, Elasticsearch eller AWS Lambda. Vi vil bruke DynamoDB i denne opplæringen.
Det første vi må gjøre er å opprette et nytt AppSync-program og legge til vårt grunnleggende skjema.
Vår søknad må lagre to datasett - en liste over byer og en liste over steder vi vil knytte til enkelte byer i listen - slik at vårt skjema vil ha to hoveddatatyper (by og plassering).
For å komme i gang med AppSync, gå til AWS Console og velg AWS AppSync innen tjenester nedtrekksmenyen.
Når vi er i AppSync-dashbordet, må vi klikke på Opprett API knapp:
Nå har vi muligheten til å gi søknaden et navn (jeg ringer til min TravelApp), og velg typen av skjema (tilpasset eller prøve). Vi vil velge tilpasset skjema alternativet, og klikk deretter Skape.
Den neste skjermen vil være dashbordet for den nye applikasjonen. Vi får se litt nyttig informasjon med en gang, inkludert nettadressen for appen vår, samt autorisasjonsmodusen. På venstre side ser du noen få lenker: skjema, spørringer, Datakilder, og innstillinger.
Ta en titt på alternativene her før du går videre til neste trinn.
Den neste tingen vi skal gjøre er å lage skjemaet vi ønsker å bruke til vår søknad. Igjen vil skjemaet ha a By og plassering skriv inn for å starte.
Fra redaktøren klikker du på skjema kategorien, og opprett følgende grunnleggende skjema med to typer og ett spørsmål og klikk Lagre:
type by id: id! Navn: String! Land: String! steder: [Sted] Skriv Sted id: ID! cityId: ID! Navn: String! info: String type forespørsel fetchCity (id: ID!): City skjema spørring: Query
Nå som vi har et grunnleggende skjema opprettet, må vi legge ved dette skjemaet til en database!
AppSync gjør dette ekstremt enkelt. Klikk på Opprett ressurser knappen til høyre på skjermen. Vi trenger to databasetabeller: en for å holde våre byer og en annen for å holde plasseringene våre.
Velge By, godta alle standardinnstillingene, og klikk Skape. Du vil legge merke til at dette automatisk vil legge til noen nyttige spørringer, mutasjoner og abonnementer på skjemaet vårt!
Gå videre og gjør det samme for plassering ressurs. Vi har nå opprettet to databasetabeller som følger med skjemaet vårt, og også noen grunnleggende søk, mutasjoner, abonnementer og resolvere som vil kartlegge skjemaet til disse tabellene (vi vil utforske resolverne i neste avsnitt).
La oss nå se på hva som ble opprettet. Klikk på på menyen til venstre Datakilder.
Du bør nå se de to datakildene vi nettopp har opprettet!
Nå som vi har nye mutasjoner og abonnementer opprettet i vårt skjema, la vi legge dem til vår Schema-definisjon.
For å gjøre det, bla til bunnen av skjemaet og oppdater skjemadefinisjonen til følgende:
skjema spørring: spørringsmutasjon: mutasjonsabonnement: abonnement
Deretter kan vi teste alt ut ved å opprette en mutasjon og deretter en spørring. I spørringer tab, opprett følgende mutasjon:
mutasjon createCity createCity (input: id: "00001" navn: "Seattle" land: "USA") id
Dette vil legge til en post for Seattle til bybordet, med et ID på 00001.
Deretter oppretter du en forespørsel for å hente dataene:
forespørsel getCity getCity (id: "00001") id navn land
Når du klikker på oransje spillknappen, kan du velge å utføre createCity mutasjon eller getCity spørsmål. Kjør dem begge, og du bør se Seattle City-data hentet og utdata på høyre side av skjermen.
Hvis du vil se hvordan disse dataene er representert i databasen, kan du utforske DynamoDB bytabellen koblet fra Datakilder tab.
Du lurer kanskje på hvordan spørringen kartlegger databasen så sømløst. Svaret er resolvere!
Hvis du ser på høyre side av AppSync dashbordet skjema fanen, vil du se en tittel med tittelen Datatyper. Dette viser alle datatyper i vårt Schema. Til høyre for hvert felt ser vi en overskrift merket resolver.
Resolvere er i utgangspunktet grensesnittet mellom skjemaet og databasen som vi bruker for øyeblikket. Vi kan bruke resolvere for alt fra grunnleggende gjenfinning av elementer til komplekse handlinger som finkornet tilgangskontroll.
Resolvers er skrevet i en DSL kalt Velocity Templating Language (VTL). AppSync vil automatisk gi grunnleggende resolvere ved datakildeoppretting, men de er svært konfigurerbare. På dette punktet trenger vi ikke å endre mye i våre resolvere, men la oss se på tre hovedtyper av resolvere som du sannsynligvis må jobbe med i den virkelige verden. Disse er knyttet til følgende grunnleggende operasjoner:
I Datatyper kategorien, ved siden av skjemadefinisjonene, finner du getCity under Spørsmål, og klikk på CityTable.
Dette bør ta deg til resolver-konfigurasjonsskjermen. Fra denne skjermen ser du at det er tre hovedstykker til en resolver:
De datakilde er bordet som du ønsker å samhandle med.
De Be om kartleggingskalenderen beskriver hvordan databasen håndterer forespørselen.
Her kan du skrive din egen kartleggingsmaler eller velge mellom et utvalg prepopulated maler for grunnleggende handlinger som å få eller sette et element, blant annet.
Her ser du malen for å få et element.
De respons kartlegging mal beskriver hvordan du håndterer svaret fra databasen.
I vår responsmal, er vi i utgangspunktet bare tilbake context.result og pakker den inn i $ utils.toJson verktøyfunksjon. Dette er bare en av mange hjelpeapparater som vil abstrahere noen av VTL-kjeleplaten. Se den komplette listen over bruksmetoder i den offisielle dokumentasjonen.
Når søknaden din blir mer komplisert, blir nøkkelen til å bli dyktig på AppSync komfortabel med å jobbe med disse kartleggingsmalene. Det tok meg noen timer å vikle hodet mitt rundt hvordan det hele virket, men etter å ha eksperimentert med det for en kort stund kunne jeg se hvor kraftig det er.
Vi har ikke plass her for å komme inn på alle detaljer i resolver mapping maler, men du kan sjekke ut referansemalen Referanse og kartleggingskabel for Resolver Mapping Template for å lære mer om dem.
For nå vil vi fortsette og fullføre vårt skjema.
Vi har fullført vårt skjema, men vi har ett siste skritt før vi kan begynne å samhandle med vårt nye GraphQL-endepunkt fra vår React native-applikasjon!
Fordi vi skal lagre alle våre steder i ett bord, men spørre dem basert på byen vi ser på, må vi opprette en sekundær indeks slik at vi effektivt kan spørre steder med en bestemt cityId.
For å opprette en sekundær indeks, gå til Datakilder og klikk på Plasseringstabell hyperlink.
Dette bør ta deg til DynamoDB-tabellvisningen for plasseringstabellen. Her klikker du på indekser kategorien og opprett en ny indeks med en partisjonstast på cityId.
Du kan senke lese- og skrivekapasitetsenhetene til 1 i forbindelse med denne opplæringen.
Deretter må vi oppdatere vår listLocations spørre om å godta dette cityId Som et argument, oppdater så søket etter listLocations til følgende:
skriv forespørsel // alle tidligere søk utelatt listeLokeringer (cityId: ID !, først: Int, after: String): LocationConnection
Nå må vi oppdatere vår listLocations resolver å bruke denne nye cityId index! Husk at vi egentlig bare vil ha listLocations å returnere en rekke steder for byen vi ser på, så listLocations resolver vil ta cityId som en parameter og bare returnere steder for den byen.
For å få dette til å virke, la oss oppdatere forespørselskartemalen for listLocations å være følgende:
"versjon": "2017-02-28", "operasjon": "Spørring", "indeks": "cityId-index", "spørring": "uttrykk": "cityId =: cityId", "expressionValues" : ": cityId": "S": "$ ctx.args.cityId", "grense": #if ($ context.arguments.limit) $ context.arguments.limit #else 10 #end, "nextToken": #if ($ context.arguments.nextToken) "$ context.arguments.nextToken" #else null #end
I denne opplæringen har vi opprettet back-end for en React Native app med eget GraphQL endpoint. Vi så også på hvordan du oppretter og oppdaterer resolvere og arbeider med AppSync-skjemaet.
Nå som vi er ferdige med å konfigurere alt i konsollen, kan vi gå videre og opprette vår React native klient! I neste innlegg dykker jeg inn i mobilnøkkelen React Native og viser deg hvordan du kobler React Native opp til AppSync.
I mellomtiden kan du sjekke ut noen av våre andre innlegg om React native app development!
Noen bilder brukt med kreditt fra Amazon Web Services, Inc.
