Cloud Nine forklarer hodeløs: Er hodeløs rett for nettstedet mitt?

I denne bloggserien diskuterer jeg konseptet hodeløs og svarer på noen spørsmål som jeg ofte blir stilt i min rolle som utvikler. Vi har tidligere definert og fremhevet noen av fordelene med hodeløs, og i dette innlegget skal vi snakke litt mer om hvorfor du vil ha et hodeløst nettsted og noen ting du bør vurdere hvis du vil gå den veien.

Ja, hodeløs er fortsatt aktuelt

I nettsammenheng har hodeløs hengt rundt som en klar trend en god stund nå, og det har ikke vist noen tegn til å avta. Her i Cloud Nine har det vanligvis vært vi som har forsøkt å forklare hva det er og hvorfor det er bra, men i det siste har det også begynt å dukke opp som et krav fra kundesiden tidlig i diskusjoner. Det viser at det er en bredere kunnskap om hodeløs og hva det kan bringe, og det betyr igjen at denne trenden trolig bare vil fortsette å vokse seg sterkere i fremtiden.

Mitt syn er at det fremfor alt er et par ting som gjør at hodeløse tiltrekker interesse utenfor utviklerkretser, kanskje først og fremst fleksibilitet og utskiftbarhet. Rett og slett at du ser verdi i å kunne gjøre endringer. Både ved at små endringer kan gjøres raskere takket være et løsere koblet system, men også at man teoretisk sett kan bytte ut ganske store byggeklosser i systemet uten å måtte gjøre en så stor overhaling generelt. Det blir sett på som en mer fremtidssikker måte å jobbe på, med mindre risiko for å male seg inn i et hjørne.

En annen faktor som ikke bør undervurderes er at mange moderne nettsider tilbyr en veldig hyggelig opplevelse ved å bruke et av de store Javascript-rammeverket, med React i spissen. Fordelene i opplevd hastighet, sømløs navigasjon og større frihet ved utforming av interaksjoner på denne typen nettsteder appellerer til mange. For å oppnå dette godt for et større nettsted, er hodeløs nok til å bli ansett som et krav.

Avgjørende faktorer for å velge hodeløs

Så si at du synes alt det ovennevnte høres bra ut. Det er tydelig at du ønsker fleksibilitet, raskere endringer og et hip React-sted. Men hvis det er det du vil ha ut av nettstedet ditt, hva må du oppfylle for at det skal bli implementert? I prinsippet kreves det ikke noe spesielt, men du bør huske at det er en litt annen tankegang enn den mer tradisjonelle nettsiden. Det kan ha innvirkning på en rekke ting, hvor det er greit å ha litt innsikt fra starten om blant annet følgende:

Har utviklingsteamet hodeløs erfaring? Ikke et absolutt krav, selvfølgelig, men det kan hjelpe deg å unngå noen fallgruver. Det er ganske enkelt å “tilfeldigvis” bygge din hodeløse løsning etter nøyaktig samme tankesett som en tradisjonell nettside, hvorpå du mister noen av fordelene med fleksibilitet.

Er de som skal jobbe med innholdet på nettsiden om bord? Ofte kan det være en litt annen oppgave å jobbe med innhold når det ikke er knyttet til en spesifikk presentasjon, for eksempel kan det føles litt mindre fritt, da alt annet enn det mest grunnleggende designet generelt styres av kode i stedet for av redaktører (ledende til en konsistent presentasjon av alt innhold).

Har du valgt en (eller flere) plattformer som passer for hodeløse? De fleste større CMS- og e-handelsplattformer har i dag en eller annen form for støtte for headless, men det er fortsatt verdt å huske på. Det trenger ikke å være en “deal-breaker”, men hvis plattformen din ikke er klar for det eller ikke har god nok støtte, bør du være klar over at det kan kreve ekstra utvikling, eller det i verste fall I tilfelle må du kanskje revurdere ditt valg av plattform. Det bør også huskes at det kan være ting som oppfattes som innebygd i en plattform, men som ikke automatisk tas med når man bygger en frakoblet applikasjon. Det siste gjelder i hovedsak plattformer som ikke er bygget for hodeløse fra grunnen av.

Oppsummert kan man nok enkelt si at hodeløs innebærer en litt annen måte å tenke på, både i utviklingsarbeidet og for de som skal jobbe med det ferdige produktet. Jeg vil imidlertid si at de fleste, kanskje med unntak av en oppstartsfase, blir mer greie når man først er i gang, takket være den klare ansvarsfordelingen.

I neste innlegg skal jeg se nærmere på «microservice architecture», som ofte nevnes sammen med headless, samt nevne noen korte tanker om fremtiden på disse to områdene.

/Ronnie Hillgren, systemutvikler