Efter ett revolutionerande 2015 med full satsning på React och React Native ställdes vi 2016 inför nästa stora utmaning: hur hanterar man komplex datastruktur och state i stora, snabba applikationer?
2016 blev året då vi, på We ahead, formellt gjorde vår första standardisering av hantering av data och kommunikation.
Med en stor React-kodbas blir det snabbt svårt att veta var data lagras och hur den flödar. Vi behövde ett pålitligt system för att hantera state.
Vi, och många andra, valde Redux (och dess principer) som vår standard för state management. Genom att introducera en enda källa till sanning och en strikt process för dataförändringar fick vi kontroll över även de mest komplexa applikationer.
Detta var avgörande för att kunna förbättra hanteringen av data i våra React Native-appar och stora SPAs, vilket säkrade att apparna kunde underhållas och var förutsägbara när de växte i storlek.
Node.js-mikrotjänsterna från 2014 var effektiva, men att bygga REST-API:er för varje enskild dataförfrågan var ibland ineffektivt. Vi hade sneglat på GraphQL under slutet av 2015 men det var först nu i 2016 som vi började introducerade det i våra projekt.
GraphQL tillät våra React-frontends att exakt specificera vilken data de behövde, och få det serverat. Detta löste problemet med att hämta för mycket data, kallat “over-fetching”, vilket snabbar upp apparna, särskilt över mobila nätverk.
GraphQL fungerade i vissa lägen som ett utmärkt API-lager som kunde sammanställa data från flera av våra Node.js-mikrotjänster i en enda förfrågan, vilket förenklade arkitekturen för frontend-utvecklarna i de fallen.
Vi inledde stora projekt där vi använde plattformar som Contentful som ett dedikerat, headless innehållslager. Dessa blev ett av våra tidiga steg i att helt anamma "H" (Headless) i MACH, där innehåll och presentation separeras helt.
År 2016 var året vi för första gången fokuserade på hantering av data i applikationslagret. Vi enades runt Redux och GraphQL och vi formaliserade en uppsättning regler som vi till viss del fortfarande håller fast vid än idag. Det gjorde (och fortfarande gör!) att våra applikationer kunde växa från lyckade MVP:er till kompletta, robusta produkter.
