Independent degree project - first cycle
Datateknik
Computer Engineering
En React-baserad CMS-lösning med moderna frontend-tekniker Yamo Gebrewold
MITTUNIVERSITETET
Avdelningen för informationssystem och teknologi
Examinator: Mattias Dahlgren, mattias.dahlgren @miun.se Handledare: Mikael Hasselmalm, mikael.hasselmalm @miun.se Författare: Yamo Gebrewold, yage1800 @student.miun.se Kurs: DT140G, Datateknik B-nivå, Självständigt arbete 15 hp Utbildningsprogram: Webbutveckling, 120 hp
Huvudområde: Datateknik Termin, år: VT, 2020
Sammanfattning
Den här uppsatsen handlar om ett arbete som gjordes åt konsultbolaget GESHDO Now AB där en lösning byggdes för att underlätta
innehållshanteringen på deras webbplats med moderna frontend-tekniker.
Grundkraven var att skapa en form av editor, eller en JAMstack-applikation med en klar separering mellan layouten och innehållet. Dessutom ska
prestandan vara så hög som möjligt. Lösningen ska publiceras med hjälp av en molntjänst. Ett huvudsakligt syfte med lösningen är att frigöra resurser på företaget, så att anställda som saknar kodkunskaper ska enkelt kunna hantera webbplatsens innehåll utan att behöva ta hjälp utav utvecklarna.
Tekniker som React, Gatsby, GraphQL och TinaCMS har använts för att skapa ett användarvänligt gränssnitt som lever i en skyddad miljö där man enkelt kan hantera webbplatsens innehåll i realtid. När ändringarna sparas, så reflekteras de på webbplatsens liveversion.
Projektet har byggts med enkelhet, återanvändbarhet, skalbarhet och enkelt underhåll i åtanke, och det är möjligt att utvidga lösningen och skräddarsy den utifrån framtida behov.
Nyckelord: JavaScript, React, Gatsby, GraphQL, TinaCMS, CMS, JAMstack
Abstract
This essay is a documentation of the work that was made for the consultancy company GESHDO Now AB in which a solution was built to facilitate content management of the company’s website with modern frontend technologies. The basic requirement was to create a web-based editor, or a JAMstack-based project with a clear separation between the content and the layout. The requirement was to achieve the highest performance possible. The solution should be deployed with the help of a cloud service.
A primary goal in this project is to liberate resources at the company, so that employees who lack coding skills can easily manage the content of the website without having to ask for help from the developers.
Technologies such as React, Gatsby, GraphQL and TinaCMS have been used to create a user-friendly interface which lives in a protected environment in which it is easy to manage the content of the website in realtime. When the changes are saved, they will be immediately reflected on the website in production.
The project has been built based upon the ideas of simplicity, reusability, scalability and easy maintenance, as well as the possibility to extend the solution and customize it for future needs.
Keywords: JavaScript, React, Gatsby, GraphQL, TinaCMS, CMS, JAMstack
Förord
Jag vill tacka min chef på GESHDO Now AB, Robert Sargéus, som hittade ett lämpligt projekt åt mig, samt gav mig en kompetent handledare och erfaren utvecklare, Axel Forsberg.
Jag vill även tacka min lärare och examinator, Mattias Dahlgren, som har varit till enorm hjälp under de här två åren, och inspirerat mig till att bli bättre på programmering och utforska webbutveckling på en djupare nivå.
Innehållsförteckning
Sammanfattning...iii
Abstract...iv
Förord...v
Terminologi...viii
1 Introduktion...1
1.1 Bakgrund och problemmotivering...1
1.2 Övergripande syfte...1
1.3 Avgränsningar...2
1.4 Detaljerad problemformulering...2
1.5 Företagets kravspecifikation...2
1.6 Översikt...3
1.7 Författarens bidrag...3
2 Teori...4
2.1 Biblioteket React...4
2.2 Teknikkonceptet JAMstack...4
2.3 Statiska sidgeneratorn Gatsby...5
2.3.1 Styling i Gatsby...6
2.3.2 Datahantering i Gatsby...7
2.4 Frågespråket GraphQL...8
2.5 TinaCMS...10
3 Metod...12
4 Konstruktion...14
4.1 Klona kodbasen...14
4.2 Sätta upp den lokala miljön för den befintliga kodbasen...14
4.3 Initiera det nya Gatsby-projektet...14
4.4 Planera den nya projektstrukturen...15
4.5 Uppsättning av komponentarkitekturen...16
4.6 Utmaningar vid datahanteringen i Gatsby...17
4.7 Integrationen av TinaCMS i Gatsby-projektet...17
4.7.1 En säker editeringsmiljö med TinaCMS...18
4.7.2 Uppsättning av TinaCMS-miljön lokalt...19
4.7.3 Bygga om delar av komponentarkitekturen i efterhand för att matcha TinaCMS...19
4.7.4 Tänka om gällande återanvändbarheten...19
4.7.5 Synkroniseringen med Git-repositoryn...19
4.7.6 TinaCMS flexibla formulärsystem...20
4.7.7 Nya önskemål från företaget...21
4.8 Återanvändbarhet i mindre omfattningar...21
4.9 Användartest...22
4.10 Tekniskt prestandatest...23
5 Resultat...25
6 Slutsatser...26
6.1 Projektets största utmaningar...26
6.2 Förslag på förbättringar...27
6.3 Diskussion om etik...28
Källförteckning...29
Bilaga A: Responsen för en GraphQL-fråga...34
Bilaga B: Installera Hugo lokalt...35
Bilaga C: Hämta återanvändbar data med GraphQL...36
Bilaga D: TinaCMS-ikonen och den färdiga uppsättningen...37
Bilaga E: Ett skräddarsytt TinaCMS-formulär i kod...38
Bilaga F: Fältet group-list i TinaCMS...39
Bilaga G: Fältet blocks i TinaCMS...40
Terminologi
Akronymer/Förkortningar
JAMstack JavaScript, APIs, Markup
API Application Programming Interface
CMS Content Management System
AWS Amazon Web Services
GCP Google Cloud Platform
SSG Static Site Generator
UI User Interface
SEO Search Engine Optimization
SPA Single Page Application
HTTP Hyper Text Transfer Protocol
REST Representational State Transfer
CRUD Create, Read, Update, Delete
CLI Command Line Interface
PWA Progressive Web Application
SDK Software Development Kit
HTML Hyper Text Markup Language
CSS Cascading Style Sheets
SASS Syntactically Awesome Style Sheets
NPM Node Package Manager
BEM Block Element Modifier
HOC Higher Order Component
SSR Server-Side Rendering
IDE Integrated Development Environment
YAML YAML Ain't Markup Language
1 Introduktion
1.1 Bakgrund och problemmotivering
Mjukvaruutveckling är tänkt att ge människor lösningar till vardagliga problem och göra livet enklare. Därför växer behovet ständigt för robusta,
användarvänliga programlösningar. Ett sådant behov har identifierats utav konsultföretaget GESHDO Now AB, som det här examensarbetet görs åt.
GESHDO Now AB är ett Malmöbaserat konsultbolag som erbjuder tjänster i form utav programvaruutveckling och underhåll av mjukvarusystem.
Konsulterna är specialiserade i allt från backend- och frontendutveckling till molnbaserad systemadministration. Företagets främsta kunder idag är IKEA, Ikano Bank och Securitas. Det läggs extra mycket betoning och fokus på att använda molnbaserade lösningar och hjälpa kunder migrera sina gamla system till molntjänster som AWS, GCP och Microsoft Azure.
Ett utav de initiala kraven är att migrera deras nuvarande kodbas för
webbplatsen från plattformen AWS till GCP. GCP ska enligt handledaren vara lite enklare att hantera, och det är inte lika svårt att sätta upp en miljö som i AWS. I och med att tiden inte tillåter detta att ske, så läggs fokuset istället på att bygga en robust frontend-lösning som går att utvidga för framtida behov.
Ett annat krav är att underlätta innehållshanteringen på webbplatsen. I och med att företaget ständigt expanderas och människor som inte är tekniska anställs, så vill man ge dem en enkel lösning att kunna redigera innehållet på webbplatsen utan att behöva lära sig skriva kod.
Lösningen som byggs ska separera innehåll från layout och förenkla
innehållshantering, så att anställda på företaget som saknar kodkunskap ska kunna uppdatera webbplatsens innehåll. Lösningen är JavaScript-baserad och använder biblioteket React tillsammans med den kända statiska sidgeneratorn GatsbyJS med vilken man kan skapa snabba men effektiva webbplatser.
1.2 Övergripande syfte
Syftet med arbetet är att bygga en välfungerande frontend-lösning som ger företaget möjligheten att frigöra resurser som utvecklare fick ta på sig tidigare, och låta rekryterare och dylikt sköta innehållshanteringen på webbplatsen.
Lösningen ska vara byggd med en modern JavaScript-teknik som är stabil och flexibel. Applikationen ska ha hög prestanda och vara användarvänlig.
Förhoppningen är att lösningen ska kunna sättas i bruk i en molnbaserad miljö, så att företagets anställda kan navigera till en skyddad miljö på webben och sköta innehållshanteringen där.
1.3 Avgränsningar
Arbetet är avgränsat till utveckling av frontendapplikationen som kommer användas för att ge stöd för innehållshantering utav webbplatsen. Det innebär allt från att sätta upp det nya projektet, skriva om den gamla koden med den nya valda tekniken.
Arbetet kommer inte att innehålla migreringen av kodbasen från Amazon Web Services till Google Cloud Platform. Det kommer inte heller innehålla
uppsättningen av molnmiljön där editeringen kan ske säkert och som endast företagets anställda har behörighet till.
1.4 Detaljerad problemformulering
Den befintliga koden för webbplatsen www.geshdo.com ska skrivas om med JavaScript-biblioteket React. I och med att den nya kodbasen ska vara baserad på den statiska sidgeneratorn Gatsby, så kommer ett helt nytt Gatsby-projekt startas.
Sektionerna och delarna av webbplatsen ska göras om till React-komponenter.
TinaCMS, ett Gatsby-baserat system för att redigera en Gatsby-sidas innehåll i realtid, ska integreras in i Gatsby-projektet och på så sätt ge möjlighet till att dels styra innehållet på webbplatsen men även förutbestämda delar av layouten.
Den nya applikationen ska ha samma utseende och beteende som den befintliga.
Det enda som egentligen ändras är den underliggande koden, med syfte att underlätta vidareutveckling för utvecklarna samt göra det enkelt för andra än utvecklarna att bidra med nytt innehåll och underhålla webbplatsen utan några kodkunskaper som helst.
Tekniska tester ska göras för att mäta den nya webbplatsens prestanda.
1.5 Företagets kravspecifikation
Kravspecifikationen från företaget går att summera i följande punkter:
• Lösningen ska vara serverless och köras i Google Clouds tjänst
”CloudRun”.
• Lösningen ska vara multicloud – med det menar man att den använder flertal molntjänster, då AWS-tjänsten CloudFront kommer behållas sen tidigare.
• Frontendapplikationen ska vara enkel att editera innehåll med.
Lösningen är valfri, det kan räcka med att separera innehållet från designen, ha en editor eller liknande.
• Prestandan på webbplatsen ska ha 100/100 i Chromes Lighthouse Audit- test i alla kategorier förutom PWA.
• Den ska även ha 100/100 i Google PageSpeed-testet för både mobil och desktop.
• Det ska finnas stöd för preview eller livebyggen med olika URL:er.
• Frontend-ramverket är valfritt (Gatsby, React, Vue, Hugo, Svelte) så länge koden är välstrukturerad och enkel att bygga vidare på.
Längre fram i rapporten kommer en utvärdering göras huruvida dessa kraven har uppfyllts eller inte.
1.6 Översikt
Kapitlet ”Introduktion” beskriver projektets bakgrund och problemmotivering.
Det beskriver även syftet med projektet, företagets kravspecifikation samt de konkreta målen som är tänkta att uppnås.
Kapitlet ”Teori” förklarar teorin bakom projektets olika tekniker och går bland annat in på frontendutvecklingens moderna tekniker och varför de är så
relevanta och användbara idag.
Kapitlet ”Metod” beskriver vilka verktyg och tekniker som används för att förverkliga projektets mål.
Kapitlet ”Konstruktion” är en dokumentation av de tekniska stegen som tas under projektets gång.
Kapitlet ”Resultat” är en sammanställning utav de konkreta målen som är uppnådda efter projektets slut.
Kapitlet ”Slutsatser” är en sammanfattning utav det som går bra eller dåligt efter projektets slut, samt ger förslag på förbättringar.
1.7 Författarens bidrag
Jag fick tillgång till GESHDO:s befintliga kodbas genom min handledare Axel Forsberg. Under projektets gång så fick jag även hjälp utav utvecklare från TinaCMS-teamet för att kunna lägga till viss funktionalitet som efterfrågades av min handledare.
2 Teori
För att förstå hur alla JavaScript-tekniker och koncept hänger ihop i projektet, så är det lämpligt att gå in på vad varje teknik handlar om, och därefter ägna en del av det här avsnittet åt att förklara varför de här teknikerna är så populära och använda idag, och de återkommande problemen som dessa tekniker löser.
2.1 Biblioteket React
I och med att projektet bygger på biblioteket React, så kan det vara nämnvärt att förklara vad det egentligen är, samt vad dess syfte är. Den troligtvis bästa definitionen av React är den som Reacts egna utvecklingsteam delar på deras officiella webbplats, som helt enkelt är – ett JavaScript-bibliotek för att bygga användargränssnitt [1].
Som namnet React intalar, så ger biblioteket en webbapplikation reaktivitet.
Webbapplikationer använder data som hämtas genom en server från en databas, och datan kan uppdateras beroende på olika händelser och interaktioner som användaren gör. I en gammaldags applikation skriven med ren JavaScript, så måste utvecklaren tänka på att dels hämta datan och se till att den är färsk och stämmer överens med vad som finns på serversidan, och dels synkronisera gränssnittet (det som användaren ser) med den inkommande datan. Att sköta detta manuellt är svårhanterligt, men det medför även risken att man glömmer att manuellt uppdatera gränssnittet varje gång, och på så sätt kan gränssnittet reflektera fel data. Biblioteket React sköter synkroniseringen med UI:et åt en, så att utvecklaren inte själv behöver tänka på det. När applikationsdatan - eller det som kallas för state i React-terminologi – ändras, så uppdaterar React
gränssnittet automatiskt på de ställena där en ändring har skett [2].
Andra fördelar som React-biblioteket ger, är att man kan skapa återanvändbara komponenter för att bidra till ett konsekvent gränssnitt där alla delar ser ut samt fungerar på ett förväntat sätt.
2.2 Teknikkonceptet JAMstack
Bokstäverna ”JAM” i JAMstack står för JavaScript, APIs och Markdown. Det är ett nytt begrepp inom webbutveckling som får väldigt mycket
uppmärksamhet idag. Med den här teknikstacken använder man JavaScript för att köra webbapparna som vanligt, men man sköter kommunikationen mellan applikationen och datakällorna genom API:er. Datakällorna brukar vara
Markdown-filer som är ett enkelt språk att skapa innehåll på en webbplats med.
Några fördelar med JAMstack är [3]:
1. Det är väldigt lätt och billigt att hosta på webben. Man skriver ingen
serverbaserad programmering, förutom om man sätter upp egna API:er. Även i det fallet kan man använda serverless-alternativ som AWS Gateway med vilken man enkelt kan skapa molnbaserade API:er. I och med att man i grund och botten endast serverar statisk data, så kan en statisk hosttjänst som AWS S3 räcka, då du endast hostar HTML, CSS och JavaScript.
2. Man behöver endast använda grundläggande kunskap om frontend- utveckling för att kunna utveckla en JAMstack-applikation. Man skriver en frontend-applikation som renderas i förväg med HTML, CSS och JavaScript.
3. Man behöver ingen kunskap om innehållshanteringssystem (CMS:er). Det är bara Markdown-filer. Allt innehåll lever i Markdown-filerna, som man läser in genom sidgeneratorer, eller genom ett API som man bygger. Man använder statiska sidgeneratorer (SSG:er) som har färdiga plugins för att läsa in
Markdown-filer. Markdown som språk är väldigt enkelt att lära sig, då det har en väldigt enkel syntax.
4. Flexibilitet. Man har flera statiska sidgeneratorer att välja mellan, som Hugo, Jekyll och Gatsby.
5. Man får bra stöd för sökmotoroptimering (SEO).
6. JAMstack-baserade webbplatser brukar vara väldigt snabba.
2.3 Statiska sidgeneratorn Gatsby
Gatsby är ett ramverk baserat på öppen källkod som bygger på React och används för att generera snabba webbsidor och applikationer [4].
Flera fördelar med Gatsby är:
1) Det är snabbt. Gatsby genererar sidorna åt en i förväg. Det innebär att man inte behöver vänta på servern att köra någon serverbaserad kod, utan det går mycket snabbare att interagera med en Gatsby-webbplats.
2) Säkerhet. Gatsby-sidor är säkra, i och med att Gatsby enbart genererar HTML. Om en hacker skulle få åtkomst till servern så finns det ändå bara HTML-sidor på servern och ingen databas eller underliggande WordPress- system som lagrar känslig data.
3) Bekvämlighet för utvecklaren. Det är mycket bekvämt att utveckla i Gatsby med det rika ekosystemet, den färdiga mallen som man får. Gatsby har en stor community och väldigt utförlig dokumentation, och därför blir det enkelt att utveckla med Gatsby.
Gatsby har sin egna CLI (Command Line Interface) som man kan skapa ett nytt projekt med [5].
Man kan använda Git som backend för att lagra data i Markdown-filer. För att skapa blogginlägg till exempel, så kan man skapa Markdown-filer som
representerar dessa inlägg. För att få Gatsby att läsa in Markdown-filerna, så behöver man bland annat pluginet gatsby-source-filesystem vars uppgift är att möjliggöra kommunikation med datorns filsystem, så att man kan hämta data från filerna. Detta plugin är förinstallerat om man skapar ett nytt Gatsby-projekt med Gatsbys egna CLI.
Sidgeneratorer löser problemet som SPA:er (Single Page Applications) har med SEO (Search Engine Optimization). Sökmotorer läser webbplatsers innehåll som består av HTML, men problemet med SPA:er som en React-applikation till exempel är att de i grund och botten bara består utav en tom div-tagg med id:et
”app” eller ”root”. Det säger inte mycket till en sökmotor. Men med en sidgenerator så genererar den ut HTML i förväg, så att sökmotorer kan identifiera webbplatsens innehåll och på så sätt ranka den. Så fort användaren går in på webbplatsen så tar SPA-tekniken, som React, över och sköter allting dynamiskt med JavaScript. Man får alltså det bästa utav båda världar – sökmotoroptimering som är nödvändigt idag för att kunna synas på webben, och den snabba reaktiviteten som SPA-ramverken och biblioteken React, Vue och Angular ger oss [6].
Ordet ”statisk” kan vara missvisande, för man menar inte att webbplatsen saknar dynamik, utan att det finns stöd för att servera statiskt innehåll i och med att HTML-koden renderas i förväg. Det är fullt möjligt att lägga till dynamik på en sida som genereras av en statisk sidgenerator, som till exempel
kommentarfält där kommentarerna lagras på en server. JavaScript i sig är ett ytterst dynamiskt programmeringsspråk, och man kan lägga till hur mycket dynamisk funktionalitet som helst med det.
2.3.1 Styling i Gatsby
Styling är en viktig del av alla frontend-projekt, och därför är det inte konstigt att det finns flera vägar att gå som alla har sina för- och nackdelar och passar olika typer av projekt. Gatsby har stöd för flera populära CSS-tekniker. För att förstå varför dessa tekniker har utvecklats för något som egentligen är väldigt enkelt – tekniken CSS – så måste man titta på det stora problemet med CSS som utvecklare tackar dagligen; nämligen att stilreglerna är globala per standard. Detta innebär att det är väldigt lätt för CSS-regler att kollidera med varandra, speciellt när applikationen växer, flera utvecklare bidrar till samma kodbas, och många regler läggs till. Detta har man valt att lösa på olika sätt, som Gatsby även har stöd för, och några av dessa sätten är:
1. CSS-in-JS [7]. Denna teknik går ut på att tillföra dynamik och logik i CSS.
Det är ett JavaScript-bibliotek, eller en rad olika bibliotek, där varje JavaScript- komponent bundlas tillsammans med CSS-regler och beroenden. Alltså har man inget berorende utav en CSS-fil, utan all CSS skrivs i JavaScript-kod.
Med CSS-in-JS-sättet så skriver man CSS isolerat i JavaScript-filer, vilket betyder att man aldrig behöver oroa sig för CSS-kollisioner mellan regler. Man
kan vara helt säker på att en ändring på en komponents stilmall inte kommer påverka en annan komponent. Om man raderar en komponent, så raderas stilreglerna för den också. Vissa CSS-in-JS-bibliotek är specifika för ett ramverk, medan andra går att integrera med vilka ramverk som helst. Ett exempel på ett React-ramverk för just denna CSS-arkitektur är biblioteket Radium [8]. Bibliotek som Radium skapar så kallade inline styles som är specifika för ett specifikt element. Inline styles i CSS har sina begränsningar, och har ej stöd för vissa CSS-regler som pseudoseleketorer eller så kallade browser states som ”:focus”, ”:hover” och media queries, även om Radium till exempel har alternativ till dessa begränsningar och lösningar till dessa problem.
2. En variant av komponentisolerad CSS är så kallade CSS Modules, som påminner lite om föregående lösning i avseendet att unika selektorer genereras på varje element. Skillnaden är att i det här fallet skriver man helt vanlig CSS i separata CSS-filer, men när man sedan importerar CSS-filerna i en React- komponent så tilldelar man klasserna komponenter som i sin tur kommer injektera dessa unika klassnamn på elementen. Gatsby stödjer CSS Modules per standard utan att man behöver aktivera något plugin.
3. En annan teknik som inte garanterar säkerhet från globala kollisioner är SASS, som Gatsby givetvis har stöd för. Man behöver däremot installera ett NPM-paket för att få det att fungera [9]. Pluginet rekommenderas av Gatsby och det går att integrera på nolltid. Detta i kombination med en CSS-arkitektur som exempelvis BEM (Block Element Modifier) [10] kan ge det som man efterfrågar i ett stort projekt – då man får en modern CSS-utvecklingsmiljö samtidigt som man får säkerhet från globala CSS-kollisioner.
2.3.2 Datahantering i Gatsby
Att flytta över kod, skapa komponenter och bygga om en befintlig layout är en relativt tydlig uppgift. Men sättet som Gatsby hanterar datainläsning på är lite speciellt, då GraphQL är tekniken som används i bakgrunden. Man ställer frågor mot en datakälla, som kan vara allt från ett API till Markdown-filer, och så hämtar man ut den datan som man är intresserad utav.
Det är här Gatsby-alternativet i projektet skiner. Ett huvudsakligt mål av företaget var att kunna separera sidans innehåll från layouten, och det är precis det som Gatsby erbjuder. En webbplats består utav styling, dynamisk logik, men även data, som härstammar från en källa. Gatsby definierar data som
”allting som lever utanför en React-komponent”, alltså allt som inte är elementens struktur, styling och grundlogik [11].
Ett exempel på när inhämtningen av data på GraphQL/Gatsby-sättet blir väldigt gynnsamt är om man till exempel vill dela en sidtitel med flera sidor. Om man skulle göra det på det statiska sättet, så hade man behövt ändra texterna på alla ställen om man gör en uppdatering längre fram i tiden. Om man istället sparar titeln på en plats, som i gatsby-config.js-filen, och sedan refererar till den genom att hämta datan – som även illustreras i Bilaga C - så kan man hämta titeln med hjälp av GraphQL. Man kan använda en så kallad page query, för att
lägga till titeln. Detta visar hur mäktigt GraphQL är. Man specificerar sin data och hämtar bara ut det som man behöver.
2.4 Frågespråket GraphQL
I och med att Gatsby bygger på GraphQL, så kan det vara en bra idé att utforska hur GraphQL egentligen fungerar och vad som gör tekniken så speciell.
GraphQL är en specifikation som bygger runt HTTP gällande hur man får data från en server. GraphQL är ingen komplicerad t eknik, utan det är bara ett verktyg som används för att hantera verktyg som vi redan har.
Vanligtvis använder man REST ändpunkter (endpoints) för HTTP-anrop med olika metoder som GET, PUT och så vidare. GraphQL slänger iväg dessa ändpunkter och låter en arbeta med en enda ändpunkt istället. Man får tillbaka olika typer av data beroende på vad man tar med i sin GraphQL-fråga till ändpunkten.
För att förstå vad GraphQL är, så hjälper det att titta på skillnaden mellan GraphQL och REST med hjälp av ett exempel. Om vi föreställer oss att vi har en applikation med böcker och författare, och varje resurs kan ha flera fält, som
”namn”, ”beskrivning”, ”ISBN”, ”år” och så vidare, så kan REST-ändpunkterna till ett API som man kan få ut alla författare eller böckerna av en viss författare se ut på följande vis:
1. /authors – för att få alla författare.
2. /authors/:id/books – för att få alla böcker av en viss författare.
Om vi bara vill ha boktitlarna för varje författare, så behöver vi först hämta alla författare, så vi kan få deras ID och namn. På vägen får vi massa information om författarna som vi inte behöver. När vi sedan har fått all information om författarna, så behöver vi göra ett nytt anrop för att få boktitlarna för varja författare. Med fem författare behöver vi göra fem anrop, och få all information om böckerna trots att vi bara är intresserade av titeln.
Med ett REST-baserat API har vi alltså två stora problem:
a) Vi behöver anropa API:et ett onödigt antal gånger.
b) Vi får extra information i responserna som vi inte behöver.
Med GraphQL däremot så ställer man en fråga med den exakta datan man vill ha. I Figur 1 illustreras en GraphQL-fråga som hämtar ut namnet på varje författare, samt boktiteln för varje författare.
query {
authors {
name
books {
title
}
} }
Figur 1: Exempel på en GraphQL-fråga
Med den här frågan säger man att man vill ha namn på alla författare, och sen boktitlarna för varje författare. Frågan skickas till GraphQL-servern som skickar tillbaka en lista med alla författare och deras namn, samt en lista på böckerna för varje författare. En respons kan likna det som framgår i Bilaga A.
Man får alltså bara informationen som man frågade om. Det är den stora fördelen med GraphQL, då man bara gör ett enda anrop till servern.
I och med att GraphQL bygger på det ordinarie HTTP-protokollet, så behöver man inget nytt för att sätta igång med GraphQL. Det finns bibliotek för olika programmeringsspråk som använder GraphQL.
Med GraphQL kan man även manipulera data på en server – alltså skapa, uppdatera och radera, eller det som är känt som CRUD-operationer (Create, Read, Update, Delete). Man kan specificera vad man vill få tillbaka från servern. Man kan lägga till en bok, och bara få tillbaka namnet och ID:et.
GraphQL har också stöd för felhantering. Det blir mycket lättare att kommunicera med servern från frontend med GraphQL.
Med GraphQL börjar man se på datan som en graf, där man har olika nivåer av objekt. Man kan till exempel ha en Root Query som förälderobjekt, som har flera barn i form av ”Book Query” och ”Author Query”.
Det blir väldigt enkelt att skapa ändpunkter med GraphQL, då man arbetar med frågor eller queries och specificerar vad man vill få tillbaka från servern.
Istället för HTTP-verben POST, PUT och DELETE, så använder man så kallade mutations i GraphQL.
GraphQLs arkitektur är till stor del byggd på typade objekt som är definierade i GraphQL-biblioteket. Det är väldigt enkelt att med få rader kod skapa ett fungerande och flexibelt GraphQL-API. Det är också väldigt enkelt att på klientsidan konsumera API:et och få det att hämta olika typer av data med väldigt strikta frågor utan att behöva göra flertal anrop [12].
I ett Gatsby-projekt så får man tillgång till ett verktyg som heter ”GraphiQL”.
Det är ett gränssnitt med vilket man kan ställa GraphQL-frågor till en datakälla, som exempelvis Markdown-filer i datorns filsystem. Gränssnittet illustreras i Figur 2.
Figur 2: Gränssnittet GraphiQL
Man får då ut resultatet på högra sidan i JSON-format. Det är en bra plats att designa sina GraphQL-frågor på innan man applicerar dem i själva koden.
Men att läsa in information om filer med GraphQL är bara första steget. Det andra steget är att installera ett så kallat plugin vid namnet gatsby-transformer- remark som transformerar den råa datan till något läsbart [13].
2.5 TinaCMS
Namnet TinaCMS kan vara lite missvisande. Vid ett första intryck kan man få för sig att det verkligen är ett innehållshanteringssystem, men vissa utvecklare väljer att inte definiera det som ett sådant, utan att det egentligen bara är ett editeringsverktyg [14]. Ett CMS brukar kräva en databas, vilket TinaCMS inte gör. TinaCMS arbetar alltså med versionshanteringssystemet Git som en backend. Det kan exempelvis vara en repository på GitHub som man gör ändringar på med hjälp av TinaCMS. På den officiella webbplats definieras TinaCMS som ett öppen källkod-baserat editeringsverktyg för Reactbaserade sidor som Gatsby och Next.js [15].
I grund och botten verkar det vara en definitionsfråga bland utvecklare. Om verktyget hanterar innehåll på ett systematiskt sätt så kan det klassas som ett CMS.
I skrivande stund så har TinaCMS bara stöd för React-baserade ramverk som Next.js, Gatsby och liknande. Teamet har som mål att ge stöd till Vue i framtiden.
Tina är ett så kallat middleware mellan frontend och datakällan (som vanligtvis är Markdown-filer). Man kan se på verktyget som ett stort formulär med fält.
Varje fält i verktyget har ett motsvarande fält i källfilen. När man editerar värdet
i gränssnittet så tar det nya värdet över det gamla värdet i källfilen. Om man klickar på ”Spara”, så skrivs källfilen över med de nya värdena, och eventuellt sparas i Git-repositoryn.
3 Metod
Man kan dela upp arbetets olika tekniker i två delar – teknikerna som det gamla projektet (den befintliga kodbasen) använder sig utav, och teknikerna som det nya projektet kommer byggas med. Anledningen varför det gamla projektets tekniker spelar roll är att de utgör grunden för det som ska bli den nya kodbasen. Det gamla projektet är byggt i de grundläggande
webbutvecklingsteknikerna som är HTML, CSS och JavaScript. Dessutom används den statiska sidgeneratorn Hugo, som är byggd med
programmeringsspråket Go Lang.
För att få tillgång till kodbasen, så behövs Amazon Web Services och de verktygen som plattformen erbjuder, som deras SDK (Software Development Toolkit) för att kunna klona Git-repositoryn [16]. I och med att repositoryn ligger på företagets AWS-konto, så behöver man först tillgång till kontot. Nästa steg är att installera Amazon Web Services SDK (Software Development Kit) som nämns i Metod-avsnittet. Det är en hel del konfigurering som behövs för att kunna peka mot rätt Git-repository som hostas genom AWS
versionshanteringstjänst CodeCommit [17]. Därtill kan man få ett problem om man råkar ha installerat Git på Windows och valt att inkludera Credential Manager. Då kan man behöva installera om Git på nytt, för att det ska vara möjligt.
När man skriver om en kodbas, så måste man först veta hur den fungerar.
Genom att studera projektets arkitektur och olika sektioner så kan man utifrån det planera hur man ska skriva om det med en annan teknik, som i det här fallet är React och Gatsby. Omskrivningen av projektet innehåller inget nytt beteende eller utseende på webbplatsen, och därför kan man enkelt skapa en projektplan eller en Kanban-bräda (projektverktyg för att hålla koll på uppgifter) som man stegvis fyller med uppgifter.
Projektverktyget som kommer användas i arbetet är Trello, där kort kommer skapas för att hålla koll på vilka uppgifter som behöver göras, vad som görs för stunden, samt vad som har gjorts klart. Anteckningar kommer skrivas på korten som stöd för den här rapporten. Trellobrädan illustreras i Figur 3.
Kommunikationen med handledaren sker antingen genom mejl med Outlook, eller genom Discord.
Figur 3: Trello-brädan för det självständiga arbetet
För att bygga den nya kodbasen så kommer JavaScript-biblioteket React användas först och främst. I och med att projektet kommer initieras som ett nytt Gatsby-projekt som i sig bygger på React, så kommer dessa tekniker vara hårt ihopkopplade. Det första kodmässiga steget är alltså att skapa ett nytt Gatsby- projekt med Gatsbys CLI. Där ska webbplatsens befintliga sektioner
konverteras om till Reactbaserade, återanvändbara komponenter.
När Gatsby-projektet har fått sin form, så kommer TinaCMS integreras in i kodbasen. Det kommer kräva en del konfigurering och justering för att synka ihop webbplatsens innehåll med redigeringsverktyget.
En pågående utvärdering kommer göras huruvida kravspecifikationen kommer att uppfyllas eller inte. När ett krav har uppfyllts så dokumenteras det.
Likaså kommer en utvärdering av de använda teknikerna göras, där slutsatser kommer dras gällande teknikernas för- och nackdelar.
Programmeringen kommer ske främst i Visual Studio Code. Gatsbys lokala utvecklingsserver kommer att användas under utvecklingsskedet för att ge hot reloading, samt starta GraphiQL-gränssnittet där GraphQL-frågorna kommer designas.
Som i alla webbprojekt så behöver en webbläsare användas, och den primära målwebbläsaren är Google Chrome och därför kommer den användas, tillsammans med webbläsarens värdefulla utvecklingsverktyg.
När webbplatsen är färdigutvecklad så kommer tekniska tester att utföras gällande prestanda, tillgänglighet, SEO (sökmotoroptimering) och det som kallas för best practices. Det kan innebära att ändringar kommer behöva göras för att försöka matcha kravspecifikationen om att optimera webbplatsen så mycket som möjligt.
4 Konstruktion
I det här avsnittet dokumenteras stegen som togs samt hur de beskrivna verktygen i Metod-avsnittet användes för att uppnå de önskade målen.
4.1 Klona kodbasen
Det absolut första konkreta steget vid projektstarten var att klona Git- repositoryn av den existerande kodbasen som ska skrivas om. I och med att repositoryn ligger på företagets AWS-konto, så behövdes tillgång till det kontot först. Dessutom behövdes AWS SDK (Software Development Kit) för att kunna interagera med en AWS CodeCommit-repository genom den lokala maskinen.
Konfigurering i config- och credentials-filerna i den lokala .aws-katalogen behövdes för att kunna ansluta till rätt repository.
Projektets första problem uppstod redan vid detta skede, då Git Credential Manager krävde autentisering. Enligt AWS-dokumentationen så är detta ett känt problem som uppstår när man har installerat Git på Windows tillsammans med Git Credential Manager, i och med att den inte fungerar ihop med AWS CLI [18]. Lösningen var att installera om Git och skippa Git Credential Manager i installationsalternativen. Detta löste problemet delvis, men ett 403-
felmeddelande dök upp vid varje försök att klona repositoryn. Till slut fick överlämningen av kodbasen ske manuellt då handledaren delade koden i ZIP- format.
4.2 Sätta upp den lokala miljön för den befintliga kodbasen
För att kunna påbörja omskrivningen av koden i det nya projektet, så behövdes en lokal uppsättning av det gamla projektet. I och med att projektet använder den statiska sidgeneratorn Hugo, så var det första naturliga steget att installera Hugo. För att installera Hugo, så behövdes pakethanteraren Chocolatey för Windows [19]. När Chocolatey var färdiginstallerat lokalt, var det möjligt att installera Hugo lokalt [20], vilket även illustreras i Bilaga B.
Med Hugo installerat, så var det så enkelt att starta den lokala servern som att ställa sig i projektkatalogen, köra kommandot hugo server och sedan öppna webbplatsen och navigera till localhost:1313 för att se webbplatsen.
Med detta på plats, var det möjligt att initiera Gatsby-projektet.
4.3 Initiera det nya Gatsby-projektet
Målet är att integrera TinaCMS, och det fungerar smidigast när man redan har en befintlig Gatsby-sida. Därför blev nästa steg att skapa det nya projektet med hjälp av Gatsbys CLI. CLI:et är välutvecklat och man får redan väldigt mycket hjälp bara genom att köra kommandot gatsby -help i terminalen.
För att skapa ett nytt projekt i Gatsby, så kör man kommandot gatsby new {projektnamn} {sökväg till starter-repo)}. Detta skapar ett projekt i katalogen som man ställer sig i med en katalog som har det valda projektnamnet. När projektet är färdigbyggt, så kan man enkelt navigera in till katalogen genom terminalen och sedan starta utvecklingsservern med
kommandot gatsby develop.
En väldigt uppskattad bekvämlighet med den lokala utvecklingsmiljön är att Gatsby har satt upp lyssnare på filerna, och möjliggjort så kallad hot reloading så att man kan se ändringarna i filerna speglas direkt i webbläsaren utan att behöva ladda om den manuellt.
Beträffande den valda styling-tekniken med CSS, så blev valet att använda SASS genom att installera NPM-paketet ”gatsby-plugin-sass”. Som tidigare nämnt i Teori-avsnittet, så är detta plugin rekommenderat av Gatsby.
4.4 Planera den nya projektstrukturen
Om man tittar på hur den tidiga kodbasen såg ut, så kan man enkelt dela upp filerna i två kategorier:
1. Datakällor, alltså Markdown-filer som innehåller sidans innehåll, 2. Layout-filer, som är HTML-, CSS- och JavaScript-filer.
Den första kategorin är väldigt tydlig och enkel att förstå, men den andra kategorin är där det kan bli klurigt att behålla en ren arkitektur och samtidigt se till att projektet är skalbart.
Webbplatsen i sin essens är inte väldigt komplex. Den består utav flera
sektioner. Sektionerna i sig kan motsvara React-komponenter, som i sin tur kan behålla mindre UI-komponenter, som brukar kallas för ”dumma komponenter”
så de oftast bara är till för presentation av data, och inte innehåller någon logik i sig. Denna struktur illustreras i Figur 4:
Figur 4: Initial komponentstruktur för sidlayouten Layout-komponent
Sektion-komponent Sektion-komponent Sektion-komponent
UI-komponent UI-komponent UI-komponent
Sektion-komponent
4.5 Uppsättning av komponentarkitekturen
En stor utmaning i projektets initiala steg var just komponentarkitekturen. Med det menas hur en komponent ska delas upp, och hur datan ska distribueras genom komponenterna. Om man har flera ikonsektioner med text, ska ikonerna i sig vara komponenter eller ska de tillhöra en större komponent? Att definiera vad en komponent är kan vara en tolkningsfråga.
React-sättet att utveckla på tvingar utvecklaren att planera arkitekturen i förväg, i och med att React till stor del bygger på konceptet om återanvändbarhet.
Komponenter ska kunna återanvändas samt konfigureras så att de passar olika delar av applikationen. I och med att SVG-komponenter behövde renderas utifrån datan som kommer från Markdown-filerna, där vissa sektioner skulle ha vissa SVG-ikoner, som även illustreras i Figur 5, så fanns behovet för att rendera dynamiska komponenter med React. Den här artikeln var en viktig vägledare för att uppnå en liknande funktionalitet [21].
Figur 5: SVG-ikoner i en specifik sektion
En annan utmaning under transformeringen av Hugo-sidan till en React-sida med komponenter var att det fanns en del logik som fick översättas till React- kod, och det verkar inte finnas någon tydligt definierad ”bästa praxis” för det, utan React-communityn ger olika förslag på hur olika typer av funktionalitet och beteenden kan tillföras.
Ett annat exempel på hur man fick hitta egna lösningar, var att till exempel kunna slå ihop två style-objekt i ett enda objekt, med hjälp av ES6-funktionen i JavaScript ”spread operator”, som illustreras i Figur 6.
Figur 6: Slå ihop två style-objekt i ett med JavaScripts spread operator
Ett känt React-koncept som kom till god nytta var konceptet med HOC (Higher Order Components), som är komponenter som kan utföra operationer på andra komponenter eller till och med skapa andra komponenter. Konceptet användes för att skapa en så kallad ”image factory”, som kan ses som en fabrik som
producerar React-komponenter i form av bilder. En bild väljs från Markdown- filen, söks upp i de tillgängliga bilderna och renderar ut en bildkomponent.
En uttryckt önskan från företaget är att man ska kunna lägga till sina egna stories och artiklar längre fram. I och med att Gatsby har stöd för server-side rendering (SSR), och Gatsby gör det väldigt enkelt för en att utvidga en webbplats med flera sidor med hjälp av routing, samtidigt som den fortfarande är en SPA, så blir det en bra utgångspunkt att bygga vidare på längre fram.
Gatsbys egna Link-komponenter fick användas istället för de vanliga anchor- taggarna som finns i HTML. Dessa länkkomponenter är speciella då de agerar som länkar trots att det bara finns ett enda HTML-dokument och inget annat dokument att navigera till. Istället simulerar Gatsby-länken en länks beteende med den komponenten, samtidigt som den har routing inbyggd så att man får känslan av att man navigerar till en annan sida. I och med att webbplatsen bara har en sida, och allting renderas om dynamiskt av JavaScript, så sker allt väldigt snabbt – betydligt snabbare än om man skulle göra ett nytt anrop till servern och hämta information om ett helt nytt HTML-dokument med alla sina
beroenden. Hela React-tänket och arkitekturen bygger trots allt väldigt mycket på att ge webbapplikationer en mycket snabbare känsla, en ”appkänsla”, och inte den traditionella webbläsarkänslan där man behöver vänta på HTTP- responser för att se något nytt.
4.6 Utmaningar vid datahanteringen i Gatsby
När man ställer statiska GraphQL-frågor så kan man mötas av en begränsning i Gatsby. Den initiala förhoppningen var att kunna ställa flera frågor mot olika Markdown-filer som skickas ned som props till barnkomponenterna, men i Gatsby kan man bara använda en instans av Gatsby-hooken useStaticQuery i en enda JavaScript-fil. Detta är något som Gatsby själva har identifierat som en begränsning och som de för närvarande arbetar på att fixa [22].
Efter lite forskning i frågan, så blev lösningen att hämta data från flera filer i en enda GraphQL-fråga. Man specificerar alltså filnamnen, och det innehåll man vill ha från respektive fil, i en enda query. Detta framhävde verkligen
GraphQL:s flexibilitet [23].
4.7 Integrationen av TinaCMS i Gatsby-projektet
När hela framsidan och grundlayouten var färdig och layouten hade skrivits om i React, där all innehåll är separerat från layouten och all data lagras i
Markdown-filer, så var det dags att börja integrera TinaCMS, för att kunna styra redigeringen med ett verktyg istället för att ändra direkt i Markdown-filer.
Första steget var att installera två nödvändiga NPM-beroenden: gatsby-tinacms- remark och gatsby-tinacms-git. Tanken är att man ska kunna editera Markdown- filer direkt från gränssnittet, och med en Spara-knapp kunna ”committa”
ändringarna till Git-repositoryn [24].
Man kan koppla Markdown-editeringen till olika typer av komponenter med olika hooks; för funktionella komponenter där man använder statiska GraphQL- queries så använder man hooken useRemarkForm, medan man i page-
komponenter som använder page queries använder hooken remarkForm istället.
4.7.1 En säker editeringsmiljö med TinaCMS
När vi vet att TinaCMS går ut på att editera innehåll direkt i gränssnittet, så uppstår den naturliga frågan: vem ska få lov att editera innehållet, och hur håller man editeringen säker så att endast behöriga kan få tillgång till TinaCMS- verktyget?
I och med att man vill att redigeringspanelen endast ska finnas tillgänglig i en
”ickeproduktionsmiljö”, så måste man styra panelens tillgänglighet beroende på vilken miljö man är i. Som tur är så har TinaCMS detta inbyggt i
konfigureringen, så att panelen är gömd om miljön är en produktionsmiljö (när webbplatsen är live och tillgänglig för allmänheten). Detta sker med hjälp av en miljövariabel som illustreras i Figur 7.
Figur 7: Miljövariabel för att styra panelens tillgänglighet
Detta leder till nästa fråga, som är: i vilken miljö vill man tillgängliggöra TinaCMS? Hur ska de behöriga få tillgång till verktyget?
Generellt sett så verkar det finnas två populära sätt att hantera det på:
1) Antingen publicerar man inte verktyget alls, utan de som ska kunna editera innehållet får tillgång till Git-repositoryn, och editeringen sker på den lokala servern. Här kommer säkerheten vara beroende på Git-repositoryns säkerhet, d v s att enbart de behöriga har tillgång till den.
2) Eller så publicerar man en speciell, lösenordsskyddad editeringsmiljö med hjälp av en molntjänst till exempel, som enbart de behöriga får tillgång till. På så sätt har man säkerställt att endast behöriga användare kan se TinaCMS- panelen och göra ändringarna.
TinaCMS föreslår att man har en molnmiljö som man editerar i. Tina har en egen tjänst, TinaTeams, som erbjudar en lösenordsskyddad miljö. JAMstack- sidor ändrar vanligtvis Markdown-filer i realtid, och om man då använder Git som sin backend, så är det rekommenderat att man hostar sin master-branch på redigeringsmiljön, och låter alla commits deployas till sidan som är live. Eller, så kan man hosta en ”staging”-branch, som agerar som ett mellanting [25].
4.7.2 Uppsättning av TinaCMS-miljön lokalt
Med de nödvändiga NPM-paketen installerade, så ska man kunna se en ikon i form av en penna på webbplatsens vänstra sida när man startar den lokala sesrvern. Detta illustreras i Bilaga D. Ikonen är en indikation på att miljön är korrekt installerad, men Markdown-datan blir inte redigerbar förrän man integrerar det i själva koden.
4.7.3 Bygga om delar av komponentarkitekturen i efterhand för att matcha TinaCMS
En bra bit in i projektet uppstod ett arkitekturrelaterat problem. Problemet handlade om var GraphQL-frågorna ställdes. I början så hämtades all data in genom en väldigt stor GraphQL-fråga i en page-komponent, Index-
komponenten, som i sin tur skickar ner data från varje fil till respektive sektionskomponent genom props. Denna arkitektur passade inte in med
TinaCMS-uppsättningen, då TinaCMS kräver att man använder sig utav statiska queries och på så sätt använder useRemarkForms-hooken. Lösningen fick bli att skicka ner ett värde som avgör vilken statisk query som ska köras.
4.7.4 Tänka om gällande återanvändbarheten
TinaCMS och Gatsby tvingar en att tänka om gällande återanvändbarheten.
Gatsby vill att man skräddarsyr sina komponenter, och då blir det svårt att bibehålla återanvändbarheten. Å andra sidan vill TinaCMS att varje komponent ska ha en enda query, och en enda ”form” per query, vilket gör det hela svårare.
Istället för att ha en enda återanvändbar sektionskomponent som går att justera utifrån behov, så blev man tvungen att skapa separata komponenter för varje sektion.
4.7.5 Synkroniseringen med Git-repositoryn
Efter väldigt många om och men, och problem med integreringen av Git- pluginet, så fick sökvägen till repositoryn ställas in manuellt. Först då kunde man verkligen se att TinaCMS gjorde direkta ändringar i Markdown-filerna genom att endast påverka värdena från CMS-gränssnittet.
TinaCMS stagade och committade ändringarna i bakgrunden när man klickar på Spara i gränssnittet, men pushade inte ändringarna till repositoryn. Därför gick det inte att se några committade ändringar i versionshanteringsverktyget som kommer med IDE:n Visual Studio Code.
Detta gick däremot att ändra med en enkel justering i Git-pluginets
inställningar, nämligen att sätta inställningen pushOnCommit till Boolean- värdet true, och med detta så såg man att TinaCMS verkligen pushade ändringarna till GitHub. Detta visas i Figur 8.
Figur 8: Inställningen pushOnCommit i pluginet gatsby-tinacms-git
Denna inställning är otroligt kraftfull, för den innebär att man kan arbeta lokalt, göra ändringar i U:et, och sen skickas ändringarna över till den fjärrstyrda repositoryn. Om den repositoryn i sig är kopplad till ett produktionsbygge, som körs varje gång en ändring görs i Git-repositoryn, så kan man med lokal
utveckling påverka produktionsmiljön. Man behöver alltså inget publikt administrationsverktyg, utan man kan sköta allt lokalt.
4.7.6 TinaCMS flexibla formulärsystem
TinaCMS-verktyget kan i det stora hela visualiseras som ett stort formulär som har fält, där varje fält motsvarar en del av Markdown-filerna. Per standard så läser TinaCMS av Markdown-filerna och gör om varje Markdown-fält till ett input-fält i formuläret. Men i TinaCMS kan man även skräddarsy sitt formulär, och på så sätt utvidga formuläret och forma det dels för att göra fälten tydligare, men även för att göra om strukturen. Detta illustreras i Bilaga E, och visar återigen flexibiliteten i TinaCMS.
TinaCMS används primärt för att kunna ändra och styra en webbplats data (innehåll). Men efter forskning och frågor ställda till utvecklare av själva verktyget så visade det sig att man genom formulärsystemet även kan styra layouten. För att verkligen förstå hur man kunde utnyttja systemet för att ge möjlighet till layoutstyrning, så ställde jag en fråga till TinaCMS-utvecklarna på deras egna forum [26], där utvecklare från teamet gav vägledning i fråga.
Samma fråga ställdes på Stack Overflow, dock utan någon respons [27]. De gav förslag på en typ av formulär som kan användas för det specifika fallet,
nämligen möjligheten att påverka och justera en navigeringsmeny genom TinaCMS-verktyget.
Problemet i fråga var att kunna ha en lista, eller en array-liknande datastruktur i YAML-format i Markdown-filen, där datan representerar en navigeringsmeny.
På så sätt ska man genom att manipulera datan även styra menyns utseende.
TinaCMS, som innehåller en rad olika fält (fields) som kan läggas till i
formuläret, erbjuder ett speciellt fält som heter ”group-list” [28]. Fältet ”group- list” ger möjlighet att editera en lista i en Markdown-fil. Man kan lägga till, ta bort, uppdatera och även ändra ordningen på ett element i listan, som i det här fallet är ett menyalternativ, vilket illustreras i Bilaga F.
4.7.7 Nya önskemål från företaget
Agil utveckling handlar mycket om att anpassa sig till kundens behov. En bit i projektet kom nya önskemål in från företagets sida, som var:
1. Möjlighet att påverka menyn (lägga till/ta bort menyalternativ, uppdatera de befintliga menyalternativen). Det här önskemålet uppnåddes med TinaCMS- fältet ”group-list”.
2. Möjlighet att lägga till fördefinierade sektioner på sidan.
3. Möjlighet för bilduppladdning.
För att uppfylla det andra önskemålet så fanns ett annat TinaCMS-fält tillgodo, som även tipsades av utvecklarna i communityn i samma frågeställning, som heter ”blocks” [29]. Det här fältet definieras av TinaCMS som en representation av en lista med artiklar, likt ”group-list”-fältet, med skillnaden att varje entitet i listan kan ha en unik skepnad. Detta är exakt vad som efterfrågas i det här fallet, då varje sektion ska kunna ha en unik skepnad. Fältet i TinaCMS illustreras i Bilaga G.
Gällande det tredje önskemålet så stödjer TinaCMS bilduppladdning. De kräver dock att man arbetar med ett speciellt plugin, gatsby-image, för att injektera bilderna på sidan. Tanken är att man söker upp bilderna med GraphQL, samt gör bildtransformering med biblioteket Sharp [30]. Beroenden som behöver installeras är bland annat gatsby-source-filesystem, gatsby-plugin-sharp och gatsby-transformer-sharp. Man måste även konfigurera gatsby-source- filesystem så att det pekar rätt mot bilderna. Om man startar om
utvecklingsservern så kommer bilderna innkluderas i GraphQL-datalagret som imageSharpNodes.
Idén med bilduppladdning fick läggas på is, på grund av att det skulle innebära omskrivning av rätt så mycket kod för att få det att fungera, och skulle ta för lång tid att implementera.
4.8 Återanvändbarhet i mindre omfattningar
När projektet initierades i början så var förhoppningen att kunna återanvända alla tänkbara komponenter. Konceptet om återanvändbarhet är ett bra koncept
men inte alltid användbart i alla scenarion. I många fall krävs väldigt specifika, skräddarsydda komponenter för specifika behov, och då är det en bättre lösning att skräddarsy en komponent och skapa något specifikt istället för något
generellt.
Istället för att bygga stora, återanvändbara komponenter, så gick tanken över till att återanvända mindre komponenter, som UI-element som ofta upprepas på webbsidan med små justeringar, som olika typer av rubriker.
4.9 Användartest
En utav de mer inflytelserika utvecklarna på GESHDO Now gick med på att testa applikationen och ge feedback på den ur ett användarmässigt såväl som ett tekniskt perspektiv.
Rent användarmässigt så tyckte han att sidan såg identisk ut som den som gör i produktion idag, en ”en-till-en”-kopia. Han blev väldigt imponerad och tyckte att omskrivningen av projektet var väldigt lyckat ur den synvinkeln. Han blev väldigt förvånad utav hur enkelt det var att editera innehållet. Rent generellt sa han att detta kan ses som en proof of concept som fungerar och att om man filar på detaljerna så kan detta bli en väldigt användbar lösning. Det enda förslaget han kunde ge på förbättring, som även kan ses som ett drömscenario, var ifall man hade kunnat klicka direkt på texten och redigera den, istället för att behöva gå igenom en panel.
I och med att utvecklaren har en väldigt teknisk bakgrund, så följde han naturligtvis upp med en rad frågor gällande teknikerna bakom lösningen.
Frågorna som han ställde sammanställs nedan:
Fråga 1: Vad använde du för tekniker?
Svar: Teknikerna som användes var ReactJS, GatsbyJS och TinaCMS.
Fråga 2: Är Gatsby server-renderat?
Svar: Ja, Gatsby har inbyggd server-rendering.
Fråga 3: Vilken del lägger till menyn?
Svar: Layouten är byggd med TinaCMS i åtanke, och därför kan man styra menyns innehåll och sortering genom panelen.
Fråga 4: Var lagras datan, och hur läste den ut Markdown-filerna från React- sidan?
Svar: Datan lever i Markdown-filer, och Gatsby läser ut filerna på React-sidan genom GraphQL.
Fråga 5: Är lösningen realtidbaserad? Kan jag se ändringarna hos mig samtidigt sm du editerar innehållet?
Svar: Nej, den är inte realtidbaserad i det avseendet som du beskriver. Men den är delvis byggd på realtid, då ändringarna som sparas även lagras på Git-
repositoryn. I det stora hela däremot så måste du som ser produktionssidan ladda om webbläsaren för att se det editerade innehållet.
Fråga 6: Det känns märkligt att behöva skriva GraphQL-frågor i ren text. Finns det särskilda plugins för att designa GraphQL-frågor?
Svar: Verktyget jag använde för att designa GraphQL-frågorna var GraphiQL- gränssnittet som man får inbyggt när man skapar ett Gatsby-projekt med Gatsbys CLI. Jag vet inte om det finns något mer dynamiskt sätt att skriva GraphQL-frågor på.
Fråga 7: Det tog lång tid när du ändrade text på en header. Vad orsakade den långsamma svarstiden?
Svar: I och med att TinaCMS ändrar Markdown-filerna i realtid, och gör en förfrågan för att hämta filerna, så kan det dröja.
Slutligen diskuterade vi om TinaCMS som teknik i sig, hur kopplingen mellan den, Gatsby och GraphQL hör ihop. Det var en väldigt intressant teknik för honom som han inte hade hört om förut.
4.10 Tekniskt prestandatest
I och med att kravspecifikationen var att prestandan på webbplatsen ska ha 100/100 i Chromes Lighthouse Audit-test i alla kategorier förutom PWA, så gjordes ett test på den slutliga produkten. Att göra testet på
utvecklingsversionen kommer inte ge ett exakt resultat, då koden inte är optimerad. Därför är det optimala att man utför testet på den färdigbyggda, optimerade versionen [31].
Efter det första försöket då testet gjordes på den färdigbyggda versionen så blev resultatet som visas i Figur 9.
Figur 9: Första testförsöket
Gällande prestandan, så var de stora problemen främst relaterade till:
• Bildstorlekar och att bilderna inte var optimerade.
• Oanvänd JavaScript-kod, som har att göra med ramverkets olika beroenden.
Problemen relaterade till tillgängligheten, bästa praxis och sökmotoroptimering hade att göra med vissa HTML-element som saknade attribut. Det problemet är välkänt och därför finns lösningen redan på Gatsbys dokumentation. Det beror på att metadata saknas på webbplatsen. Paketet React Helmet löser problemet genom att erbjuda en så kallad component interface med vilken man kan hantera dokumenthuvudet. Genom att installera NPM-paketen gatsby-plugin- react-helmet och react-helmet, lägga till pluginsen i konfigureringsfilen för Gatsby, samt använda komponenten i rotlayouten, så ger man sidan nödvändig information som hjälper sökmotorer att förstå sidinnehållet bättre [32]. Det som gör en väsentlig skillnad för SEO-förbättringar är meta-taggarna som lätt kan försummas men som spelar väldigt stor roll för sökmotorer. På React Helmets GitHub-beskrivning kan man läsa en del om vilka HTML-taggar som finns tillgängliga [33].
De små ändringarna förbättrade Lighthouse-resultaten betydligt mer, speciellt SEO-mässigt. De nya resultaten illustreras i Figur 10.
Figur 10: Nytt testförsök efter optimering
Testresultaten kommer att diskuteras i avsnittet Slutsatser.
5 Resultat
De grundläggande kraven från företaget uppfylldes som förväntat. En fungerande frontend-lösning byggdes där man enkelt kan påverka och ändra webbplatsens innehåll.
Webbplatsen har skrivits om med nya tekniker. Lösningen är byggd med moderna frontend-tekniker som React, Gatsby, GraphQL och TinaCMS.
Webbplatsens innehåll är separerat från layouten, som kravspecifikationen antydde.
Webbplatsen har samma utseende och beteende som tidigare. Det som har ändrats är den underliggande koden, samt sättet att underhålla webbplatsen på för webbredaktörer såväl som utvecklare.
Webbplatsen uppfyller inte det efterfrågade prestandaresultatet som initialt var 100/100. Istället blev det slutliga resultatet för den färdigbyggda versionen som följande:
- Prestanda: 74/100.
- Tillgänglighet: 94/100.
- Bästa praxis: 92/100.
- SEO: 100/100.
Webbplatsen publicerades inte på en molntjänst som var ett krav i projektet. I och med att webbplatsen ej publicerades live, så var det inte heller möjligt att göra Google PageSpeed-tester på den.
6 Slutsatser
I det stora hela så kan man enkelt konstatera att lösningen som byggdes är hållbar, uppfyller de grundliga kraven, samt går att vidareutveckla. Det innebär inte att lösningen är perfekt, eller att det inte finns vissa problem eller buggar med den som behöver åtgärdas innan produkten släpps live.
Det som tog mest tid var integrationen av de olika teknikerna och få dem att fungera tillsammans. Det var en del konfigurering, många beroenden som fick installeras, och mycket arbete för att få ett fungerande arbetsflöde.
Prestandan på webbplatsen är trots allt rätt så bra, även om den också kan optimeras ännu mer. Resultaten från Chromes Lighthouse är i slutändan rena siffror, som inte lär säga särskilt mycket om hur webbplatsen verkligen kommer upplevas av användarna.
Med den här lösningen som troligen kommer tas över av själva företaget, så kan man vidareutveckla delar av den, modifiera den så att den passar företagets behov. Det viktigaste av allt är att man med den här lösningen kan frigöra resurser, så att utvecklarna inte behöver lägga sin tid på att editera webbplatsens innehåll, utan att det arbetet kan göras av webbredaktörer på företaget som inte är programmerare. Gränssnittet är så pass enkelt att hantera att vem som helst kan uppdatera information på webbplatsen utan större problem.
6.1 Projektets största utmaningar
En stor utmaning i projektet var att bestämma vilken arkitektur som ska följas.
Med facit i handen hade man föreslagit en mer anpassad layout med komponenter som passar Gatsby-miljön bättre. I och med att det är första gången som jag använder TinaCMS, så var det väldigt mycket man fick lära sig den hårda vägen, genom att misslyckas och försöka på nytt. Nu när jag har bildat mig en betydligt bättre uppfattning om vad tekniken egentligen gör och är kapabel till att göra, så hade det varit lättare att initiera ett nytt projekt med en stabil grund från första början.
Det är i många fall oundvikligt att skapa någon form av legacy-kod i ett projekt, som ofta beror på att man inte har helt koll på hur tekniken är tänkt att
användas.
Ett annat problem var att man fick tänka om flera gånger gällande
återanvändbarheten av React-komponenterna. Det som man trodde skulle förbli generiskt och återanvändbart blev istället väldigt nischat och specifikt för specifika ändamål.
En stor utmaning med att arbeta med väldigt nya tekniker, som Gatsby och TinaCMS, var att man inte hade mycket förberett stöd online. Mogna, populära tekniker brukar ha betydligt mer stöd av utvecklare, och de flesta frågorna gällande teknikerna har redan besvarats. Det som inte har besvarats kan man enkelt ta reda på genom de detaljerade dokumentationerna som finns
tillgängliga online. I fallet med TinaCMS så verkar tekniken vara så ny att den inte ens har en tagg på Stack Overflow. Utvecklarteamet fick hjälpa mig med ett par frågor som jag hade gällande vissa funktioner.
Gatsbys dokumentation var hjälpsam, men även den kunde stundtals vara obehaglig att läsa, då nivån ibland kunde vara för låg för den genomsnittliga utvecklaren. Vissa delar av dokumentationen verkar ha skrivits för nybörjare som har väldigt begränsad programmeringskunskap, och man förklarar koncept som egentligen är väldigt tydliga och inte behöver någon vidare förklaring.
6.2 Förslag på förbättringar
Till att börja med så är det viktigaste för att lösningen verkligen ska kunna användas på företaget att den publiceras live genom någon molntjänst. Det ska vara enkelt för behöriga att nå editeringsmiljön och uppdatera webbplatsens innehåll. Ändringarna ska kunna vara live på väldigt kort tid, och allt detta är fullt möjligt förutsatt att man konfigurerar miljön på rätt sätt.
Dessutom kan det vara värt att man tittar djupare på vissa funktioner som TinaCMS erbjuder men som tiden inte tillät att man implementerar, så som bilduppladdning till exempel. Det kräver att man ändrar på en del ställen där bilder används.
En annan potentiell förbättring är att optimera bilderna på webbplatsen för att öka prestandan samt tillgängligheten för användarna.
Gatsby ger goda förutsättningar för att skapa en bloggliknande sektion på webbplatsen, där behöriga kan skapa inlägg eller stories om det senaste nytt på företaget. Detta är något som har efterfrågats tidigare men som inte har
implementerats till fullo än.
När projektet växer i framtiden, så kommer man troligen vilja ha
automatiserade tester som säkerställer att beteendet fungerar som väntat och att man inte förstör existerande delar av systemet när ändringar görs.
För att öka kvaliteten på mjukvaran så kan det vara en lämplig idé att utföra användartester, dels på användarna som kommer att besöka webbplatsen som potentiella kunder till konsultföretaget, dels på anställda på företaget som troligen kommer börja använda verktyget i deras dagliga arbetsliv, och sist men inte minst utvecklarna som kommer arbeta vidare med produkten och utvidga dess funktioner.
6.3 Diskussion om etik
Denna typ av lösning till ett förekommande problem i vardagen, nämligen möjligheten att hantera innehåll på en webbplats säkert och utan krångel, kan tyckas vara bättre etiskt sett än att använda den traditionella metoden där man har ett typiskt WordPress-administreringsverktyg med en relationell databas.
WordPress-system brukar ofta lagra känslig data av användare, och det är inte sällsynt att dessa system attackeras av hackers som kommer åt information om användarna.
JAMstack-webbplatser är väldigt populära för sin säkerhet. Attacker mot dessa webbplatser kommer inte göra någon större skada, när det enda som servas är statisk data.
En annan väsentlig etisk diskussion är hur man lagrar personlig data i Markdown-filer. Här måste nog företaget hålla ett extra öga på vad som egentligen får lagras i filerna utav personlig information, och att de behöriga också är medvetna om var gränserna går.
Källförteckning
[1] Reacts officiella webbplats, ”React – A JavaScript library for building user interfaces”,
https://reactjs.org/
Hämtad 2020-07-19.
[2] Ibid.
[3] Videoklipp av Academind på YouTube, ”What is the JAMStack?”, https://www.youtube.com/watch?v=Y8PXMbr0Kqo
Publicerad 2018-12-19. Hämtad 2020-07-19.
[4] Gatsbys officiella webbplats, https://www.gatsbyjs.org/
Hämtad 2020-07-19.
[5] Videoklipp av Traversy Media på YouTube, ”Gatsby JS Crash Course”, https://www.youtube.com/watch?v=6YhqQ2ZW1sc
Publicerad 2018-04-12. Hämtad 2020-07-20.
[6] Videoklipp av Academind på YouTube, ”What is the JAMStack?”, https://www.youtube.com/watch?v=Y8PXMbr0Kqo
Publicerad 2018-12-19. Hämtad 2020-07-19.
[7] Artikel på EnvatoTuts+, ”An Introduction to CSS-in-JS: Examples, Pros and Cons”,
https://webdesign.tutsplus.com/articles/an-introduction-to-css-in-js- examples-pros-and-cons--cms-33574
Hämtad 2020-08-01.
[8] Radiums GitHub-repository,
https://github.com/FormidableLabs/radium
Hämtad 2020-08-01.
[9] Gatsby-pluginet ”gatsby-plugin-sass” på GitHub,
https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin- sass
Hämtad 2020-08-01.
[10] Informationssida om CSS-arkitekturen BEM, ”BEM – Block Element Modifier”,
http://getbem.com/
Hämtad 2020-08-01.
[11] Handledning på Gatsbys officiella hemsida, ”Data in Gatsby | GatsbyJS”,
https://www.gatsbyjs.org/tutorial/part-four/
Hämtad 2020-08-01.
[12] Videoklipp av Web Dev Simplified, ”Learn GraphQL In 40 Minutes”, https://www.youtube.com/watch?v=ZQL7tL2S0oQ
Publicerad 2019-03-02. Hämtad 2020-07-19.
[13] Handledning på Gatsbys officiella webbplats, ”Transformer plugins”, https://www.gatsbyjs.org/tutorial/part-six/
Hämtad 2020-07-20.
[14] Artikel på Bejamas, ”10 Headless CMS Options for your JAMstack Website”,
https://bejamas.io/blog/headless-cms/#tina
Publicerad 2020-03-31. Hämtad 2020-07-20.
[15] TinaCMS officiella webbplats, https://tinacms.org/
Hämtad 2020-07-20.
[16] AWS officiella webbplats, ”AWS SDK for JavaScript in Node.js”, https://aws.amazon.com/sdk-for-node-js/
Hämtad 2020-07-22.
[17] AWS officiella webbplats, ”AWS CodeCommit”, https://aws.amazon.com/codecommit/
Hämtad 2020-07-22.
[18] AWS dokumentation, ”Troubleshooting the credential helper and HTTPS connections”,
Hämtad 2020-07-30.
https://docs.aws.amazon.com/codecommit/latest/userguide/
troubleshooting-ch.html#troubleshooting-windowshttps
[19] Chocolateys officiella webbplats, ”Chocolatey Software | Installing Chocolatey”,
https://chocolatey.org/install
Hämtad 2020-08-01.
[20] Hugos officiella webbplats, ”Install Hugo | Hugo”, https://gohugo.io/getting-started/installing/
Hämtad 2020-08-01.
[21] Artikel på Storyblok, ”How to render dynamic component defined in JSON using React”,
https://www.storyblok.com/tp/react-dynamic-component-from-json
Publicerad 2019-09-26. Hämtad 2020-08-01.
[22] Artikel på Gatsbys officiella blogg av Sidhartha Chatterjee, ”Introducing useStaticQuery”,
https://www.gatsbyjs.org/blog/2019-02-20-introducing-use-static-query/
