Skip to content

Instantly share code, notes, and snippets.

@nicohvi
Last active February 28, 2018 19:26
Show Gist options
  • Save nicohvi/fc15ce28c538dff4a1a7905dc11f7e42 to your computer and use it in GitHub Desktop.
Save nicohvi/fc15ce28c538dff4a1a7905dc11f7e42 to your computer and use it in GitHub Desktop.

Utkast

Problemet

Veldig ofte i utviklingsprosjekter velger man å gå for en single page-applikasjon selv om det ikke nødvendigvis gir mening. Selv om man lager sider med mye statisk informasjon som ikke nødvendigvis har noe med hverandre å gjøre samler man alt i en JS-smøle fordi "det er sånn man gjør ting".

Problemet med denne approachen er at man da samler kompleksitet (domene og applikasjon), og dette gjør ting vanskelig å resonnere rundt. I tillegg til at applikasjonsflyten blir vanskeligere å forholde seg til låser man seg også mye mer til teknologivalg.

Backend-teknologi man velger er veldig vanskelig å bytte ut nettopp på grunn av dette (kilde: https://medium.com/sketchdeck-developer-blog/what-i-wish-i-knew-when-i-became-cto-fdc934b790e3). Den store fordelen med frontend-utvikling er at man har så mange muligheter å velge mellom, og "best practices" endrer seg fra uke til uke.

Jo større applikasjoner man bygger i JS-land jo mer låser man seg fast til en applikasjonsstruktur og rammeverk som kanskje ikke lenger er "best practice" (MobX, Cycle.js, Elm) i tillegg til at man samler kompleksitet i store JS-monolitter. Det blir også mye vanskeligere for nye utviklere å sette seg inn i koden.

Man ender også opp med en stor JS-bundle som potensielt kan føre til lange byggetider og lav developer happiness.

Løsningen

Ved å dele opp JS-monolitten din i flere små-apper, som alle dreier seg om sitt eget domene, med sine egne APIer, sin egen store, og sine egne komponenter, gjør man frontend-koden:

  1. Lettere å resonnere rundt
  2. Lettere å feilsøke
  3. Lettere å teste
  4. Raskere å bygge

Ved å benytte seg av fordelene ved å kjøre i nettleseren (caching, historikk, navigasjon) gjør man også utviklingstiden dramatisk raskere da man ikke trenger 5+ år med React/Redux-erfaring for å kunne bidra. Mindre applikasjoner med mindre avansert arkitektur gjør at overheaden for en ny utvikler blir mindre og han/hun kan bidra mye raskere.

Case-studie

Skal vise slides av hvordan jeg har bygget opp en login-løsning med validering, "glemt passord", 2faktor, lenke til registreringsskjema, og "husk meg"-funksjonalitet med React-komponenter som styres av reaktive strømmer.

Caveats

Single Page-applikasjoner har selvfølgelig sine fordeler også, og det gir helt klart mening å lage det dersom domenet man opererer i krever high-fidelity app-funksjonalitet. Eksempler er tekstredigeringsprogram, mediaspillere, spill, saksbehandlingssystem med høy cohesion mellom funkasjonalitet.

Jeg ser dog liten grunn til å lage hele nettsiden din som en single page-app dersom det er en nettside du lager. Lag heller flere, mindre SPAer, og knytt de sammen der det gir mening. For eksempel kan en brukerprofil være delt opp i flere SPAer (èn for profildetaljer, èn for e-postinstillinger, èn for avatar-tilpasning) som senere kan kobles sammen med f.eks. React-router.

Deretter kan man ekstrahere state fra de forskjellige appene i en rot-store.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment