Tidligere denne uken publiserte kode24 en kommentar om vår opplevelse av rammeverket Gatsby, og da spesielt den negative opplevelsen med GraphQL.
Gatsby er fantastisk, bortsett fra GraphQL
I kommentaren nevner vi blant annet at vi slet med integrasjonen av CMS-et Sanity i GraphQL, og at vi hadde vært i dialog med Knut Melvær i nettopp Sanity om saken.
Vi skriver blant annet at "Ulempen med valget av GraphQL er at det har en bratt læringskurve, og mange tredjeparter er i startgropen med å støtte det».
På formiddagen samme dag tikket det inn en e-post fra Knut Melvær, om nettopp denne påstanden, som var så god at vi spurte om å få trykke den.
Svaret fra Melvær
Jeg er delt her. Jeg vil ikke anta at noe som helst innenfor utvikling er "enkelt", men samtidig er dette en smule misledende om vi kun snakker om det å bruke GraphQL når man koder opp frontend. For det første har du et selvdokumentert API, for det andre slipper du "rund-dansen" som du ofte har med REST, og for det tredje så gjør GraphQL det mer transparent hvilken datastruktur du faktisk koder opp mot.
- GeoCities var punk!
Nå er Ukas Koder Martin Menneske Gammelsæter Jacobsen hekta på Sanity, React og Gatsby.
Jeg er ganske sikker du kommer mye lengre mye raskere som frontender i startgropa med GraphQL sammenlignet med et RESTful API. (Ikke minst pga all toolingen — som Apollo — rundt som bare fikser greier som caching osv). Det å bygge et GraphQL API selv kan være en smule vanskeligere, eller uvant, fordi du må spesifisere alle datatypene. Men det er jammen meg mye tooling rundt det også (f.eks sanity graphql deploy).
Så, hva er greia med Gatsby og GraphQL og hvorfor føles det ikke helt 100%?
Det Gatsby har gjort er egentlig genialt. De har laget et mellomlag som gjør det mulig å skrive "source plugins" som oversetter eksterne data (filer og API-er) og samler dem til ett internt API. Det API-et er i GraphQL som gir supermye mening. Det betyr at du kan koble på Sanity, markdown filer, Instagram feeden din, og til og med NASAs bildearkiv, og all dataen tilgjengelig på samme måte inni appen din. Og ikke bare tilgjengelig, men også dokumentert (man kan finne all dataen man har tilgjengelig på http://localhost:8000/___graphql – hvor man også kan bygge spørringene). Det er skikkelig skikkelig snedig.
Hva er greia med GraphQL?
Vi stiller de dumme spørsmålene om API-er uten REST.
Men! Det er nettopp i denne oversettelsen av ekstern data til Gatsbys GraphQL API det har vært litt gruff. Siden GraphQL er typet, så har man måtte “anta” hvilke datatyper som kommer inn basert på dataen selv. Det har to konsekvenser: Det er ikke alltid Gatsby har fikset den biffen (pga komplekse datastrukturer osv), og du risikerer å miste typer i GraphQL API dersom det plutselig ikke er noe innhold for det. For ca en måned siden shippet Gatsby muligheten for source plugins og også eksplisitt lage disse typene slik at dette problemer forsvinner. Det er dette de fleste source plugin forfatterne jobber med å implementere i dag. Vi hadde allerede skrevet vårt egen implementasjon som gjorde det samme i forkant, men shippet med den offisielle metoden ca 20 minutter etter Gatsby slapp denne oppdateringen.
Slik som vår plugin fungerer gjør vi tre ting når du spinner opp Gatsby i utviklingsmodus:
Wes Bos til kode24: - Disse teknologiene velger jeg!
Vi ba den kjente kursholderen skissere sitt drømmeoppsett.
- Vi henter GraphQL skjema definisjonen fra ditt Sanity projekts GraphQL API og forteller Gatsby om alle typene den skal ha tilgang på (uavhengig om det finnes innhold for dem ennå)
- Vi setter opp en lytter som ser på om det publiseres endringer i Sanity som den kan oppdatere Gatsby’s interne API med (du kan gi den en nøkkel slik at dette skjer i sanntid – som er veldig tøft – og vi er de eneste som kan gjøre dette per i dag).
- Vi heller inn (via en node-stream) alle dokumentene dine via eksport-APIet vårt. Det betyr at du kan ha 10 000 sider på nettstedet ditt, med alt innholdet i Sanity, og bruker kun disse 3 API kallene på å bygge nettsiden din (to når du er i produksjon)
Vi vil også ha full støtte for Gatsby Preview, også som en av de få – om ikke eneste – som har sanntids forhåndsvisning på enkelt-tast-nivå.
Der vi ser mange snuble når de utvikler sider med Gatsby, er at Gatsby er veldig på å mellomlagre data. Dette er forståelig fordi det kan være kostbart å bygge alt på nytt når du sitter lokalt og utvikler. Det er dog ikke alltid Gatsby klarer å oppdatere cachen med nye endringene fra gang til gang. Det er også sånn at du er nødt til å restarte utviklingserveren hver gang du gjør endringer med selve datamodellen.
Dette er er lett å glemme / ikke være klar over, slik at man sitter og klør seg i hodet fordi man ikke ser de nye endringene man har gjort i innholdet uten videre. Vi har forsøkt å motvirke dette ved å legge inn gatsby clean i oppstarten på eksempel-prosjektene, fordi byggingen med Sanity uansett er dødskjapp.
Server-Side Rendering i React skal bli bedre
Hint fra Ambramov, Material-UI v4, react-testing-library 7 og Facebook-redesign.