Fullstack-utvikling

Hva: DNS, IP-adresser, pakker, klient-server-modellen.

Hvorfor: Uten dette blir feilsøking av nettverksfeil ren gjetting.

Bør kunne: Forklare hva som skjer fra du taster en URL til siden vises.

Prosjektforslag: Tegn og forklar reisen til en HTTP-forespørsel, trinn for trinn.

Hva: Metoder, statuskoder, headere, TLS-kryptering.

Hvorfor: Alt webkommunikasjon går over HTTP(S) — API-er, sider, alt.

Bør kunne: Kjenne forskjellen på GET/POST/PUT/DELETE og vanlige statuskoder.

Prosjektforslag: Inspiser nettverksfanen i DevTools på en side du bruker daglig.

Hva: Rendering, DOM, hvordan en server svarer med HTML/JSON.

Hvorfor: Gir grunnlaget for å forstå SSR vs. CSR senere.

Bør kunne: Forstå forskjellen på server-rendret og klient-rendret innhold.

Hva: Semantisk markup, skjemaer, tilgjengelighetstre.

Hvorfor: Dårlig HTML gir dårlig tilgjengelighet og SEO, uansett hvor bra CSS/JS er.

Bør kunne: Skrive semantisk korrekt HTML uten unødvendige div-er.

Prosjektforslag: Bygg en personlig profilside kun med HTML og CSS.

Hva: Boksmodell, selektorer, spesifisitet, Flexbox og Grid.

Hvorfor: Layout og design bygger på dette, uansett hvilket rammeverk du senere bruker.

Bør kunne: Lage responsive layouter uten å måtte gjette deg frem.

Hva: Variabler, funksjoner, DOM-manipulasjon, events, async/await.

Hvorfor: Språket alt frontend-arbeid til slutt kompileres til eller kjører som.

Bør kunne: Skrive JavaScript uten å måtte lene deg på et rammeverk for enkle ting.

Prosjektforslag: Bygg en kalkulator med ren HTML, CSS og JavaScript.

Hva: Versjonskontroll, commits, branches, pull requests.

Hvorfor: Alt profesjonelt utviklingsarbeid foregår gjennom Git.

Bør kunne: Bruke branches og løse merge-konflikter uten panikk.

Hva: Navigasjon i filsystemet, kjøre skript, miljøvariabler.

Hvorfor: Terminalen er verktøyet du bruker mest som utvikler.

Bør kunne: Være komfortabel uten å måtte google hver eneste kommando.

Hva: Statisk typing på toppen av JavaScript.

Hvorfor: Fanger feil før kjøretid og gjør store kodebaser håndterbare.

Bør kunne: Skrive typede funksjoner, interfaces og generics.

Hva: Komponentbasert UI-bibliotek med en virtuell DOM.

Hvorfor: Fundamentet Next.js og store deler av moderne frontend bygger på.

Bør kunne: Bygge komponenter med props, state og hooks fra bunnen.

Prosjektforslag: Bygg en to-do-app med lokal state.

Hva: React-rammeverk med filbasert routing, SSR og App Router.

Hvorfor: Gir struktur, ytelse og produksjonsklare mønstre rett ut av boksen.

Bør kunne: Vite forskjellen på Server og Client Components og når hver skal brukes.

Prosjektforslag: Bygg denne roadmap-siden.

Hva: Gjenbrukbare UI-byggeklosser.

Hvorfor: Reduserer duplisering og gjør UI konsistent.

Bør kunne: Dele opp UI i små, komponerbare enheter.

Hva: Dataflyt inn i komponenter (props) og internt (state).

Hvorfor: Kjernen i hvordan React-applikasjoner henger sammen.

Bør kunne: Vite når data skal løftes opp og når den kan holdes lokalt.

Hva: useState, useEffect, useMemo og egendefinerte hooks.

Hvorfor: Standardmåten å håndtere state og sideeffekter i moderne React.

Bør kunne: Skrive egne hooks for gjenbrukbar logikk.

Hva: Komponenter som rendres på serveren uten JavaScript til klienten.

Hvorfor: Reduserer bundlestørrelse og gir direkte datatilgang uten API-lag.

Bør kunne: Vite når en komponent bør være Server fremfor Client.

Hva: Komponenter som kjører i nettleseren og kan bruke state/interaktivitet.

Hvorfor: Nødvendig for alt som krever interaktivitet eller nettleser-API-er.

Bør kunne: Markere komponenter riktig med "use client" kun der det trengs.

Hva: Kontrollerte og ukontrollerte input-felter, Server Actions.

Hvorfor: De fleste applikasjoner samler inn data fra brukeren på et tidspunkt.

Bør kunne: Bygge tilgjengelige skjemaer med god feilhåndtering.

Prosjektforslag: Bygg et skjema med validering og tydelige feilmeldinger.

Hva: Klient- og serverside-validering, f.eks. med Zod.

Hvorfor: Data fra brukere kan aldri stoles på uten validering.

Bør kunne: Validere både i UI og på serveren, aldri kun i UI.

Hva: ARIA, tastaturnavigasjon, kontrast, skjermlesere.

Hvorfor: En nettside som ikke er tilgjengelig ekskluderer brukere.

Bør kunne: Teste egne sider med kun tastatur.

Hva: Layouter som fungerer fra mobil til stor desktop.

Hvorfor: Trafikk kommer fra svært ulike skjermstørrelser.

Bør kunne: Designe mobil-først og teste på ekte breddepunkter.

Hva: JavaScript-kjøretid utenfor nettleseren.

Hvorfor: Lar deg bruke samme språk i backend som i frontend.

Bør kunne: Forstå event loop og asynkron kjøring.

Hva: Arkitekturstil for API-er basert på ressurser og HTTP-verb.

Hvorfor: Den mest brukte API-stilen for webapplikasjoner i dag.

Bør kunne: Designe konsistente, forutsigbare endepunkter.

Hva: Kobling mellom URL-er og handlere.

Hvorfor: Grunnlaget for hvordan et API organiseres.

Bør kunne: Strukturere routes etter ressurs, ikke etter handling.

Hva: Bekrefte hvem brukeren er.

Hvorfor: Nødvendig for alt som ikke skal være offentlig.

Bør kunne: Forstå forskjellen på sesjoner, JWT og OAuth.

Hva: Bestemme hva en autentisert bruker har lov til å gjøre.

Hvorfor: Autentisering uten autorisering betyr at alle innloggede kan gjøre alt.

Bør kunne: Implementere rollebaserte tilgangskontroller.

Hva: Konsistente feilresponser og try/catch-strategier.

Hvorfor: Uhåndterte feil krasjer servere og lekker informasjon.

Bør kunne: Returnere forutsigbare feilformater med riktige statuskoder.

Hva: Strukturert logging av hendelser og feil.

Hvorfor: Uten logger er feilsøking i produksjon nesten umulig.

Bør kunne: Logge nok til å feilsøke, uten å logge sensitive data.

Hva: Konfigurasjon utenfor kildekoden.

Hvorfor: Skiller hemmeligheter og miljøspesifikk config fra koden.

Bør kunne: Aldri committe .env-filer med ekte verdier.

Hva: Input-sanering, CORS, sikre headere, avhengighetssårbarheter.

Hvorfor: Backend er der ekte data og forretningslogikk lever.

Bør kunne: Kjenne OWASP Top 10 og hvordan de gjelder egne API-er.

Hva: Begrense antall forespørsler per klient.

Hvorfor: Beskytter mot misbruk og overbelastning.

Bør kunne: Sette fornuftige grenser per endepunkt.

Prosjektforslag: Bygg et lite REST-API med autentisering og rate limiting.

Hva: Spørrespråk for relasjonsdatabaser.

Hvorfor: Fortsatt standarden for strukturert databehandling.

Bør kunne: Skrive joins, aggregeringer og subqueries selv.

Hva: Robust, åpen kildekode relasjonsdatabase.

Hvorfor: Industristandard for produksjonsapplikasjoner.

Bør kunne: Sette opp og designe skjema for en ekte applikasjon.

Hva: Filbasert databasemotor uten egen serverprosess.

Hvorfor: Perfekt for lokale verktøy og mindre applikasjoner.

Bør kunne: Vite når SQLite er nok og når man trenger Postgres.

Hva: Strukturert lagring av rader og kolonner.

Hvorfor: Grunnenheten i enhver relasjonsdatabase.

Bør kunne: Designe tabeller med riktige datatyper og constraints.

Hva: Én-til-mange og mange-til-mange mellom tabeller.

Hvorfor: Data henger nesten alltid sammen på tvers av tabeller.

Bør kunne: Modellere relasjoner uten unødvendig duplisering.

Hva: Unik identifikator for hver rad.

Hvorfor: Grunnlaget for pålitelige relasjoner og oppslag.

Bør kunne: Velge fornuftige nøkkelstrategier (auto-increment vs. UUID).

Hva: Datastrukturer som gjør oppslag raskere.

Hvorfor: Uten riktige indekser blir spørringer trege ved vekst.

Bør kunne: Identifisere hvilke kolonner som bør indekseres.

Hva: Versjonskontrollerte endringer i databaseskjema.

Hvorfor: Lar team endre skjema trygt og sporbart over tid.

Bør kunne: Skrive reverserbare migrasjoner.

Hva: Objekt-relasjonsmapping mellom kode og database.

Hvorfor: Reduserer boilerplate SQL for vanlige operasjoner.

Bør kunne: Vite når ORM-en hjelper og når rå SQL er bedre.

Hva: Moderne TypeScript-ORM-er for Node.js.

Hvorfor: Gir typesikker databasetilgang i fullstack-prosjekter.

Bør kunne: Sette opp skjema, migrasjoner og spørringer i én av dem.

Prosjektforslag: Bygg en budsjettoversikt med data i en ekte database.

Hva: Filsystem, prosesser, brukere, pakkebehandling.

Hvorfor: Nesten all serverdrift skjer på Linux.

Bør kunne: Navigere og administrere en server uten GUI.

Hva: Egen virtuell server du har full kontroll over.

Hvorfor: Gir forståelse for drift som skjulte plattformer tar bort.

Bør kunne: Sette opp og herde en ny server fra bunnen.

Hva: Containerisering av applikasjoner og avhengigheter.

Hvorfor: Gjør "virker på min maskin" til et ikke-problem.

Bør kunne: Skrive egne Dockerfiles for applikasjonene dine.

Hva: Orkestrering av flere containere sammen.

Hvorfor: De fleste applikasjoner består av flere tjenester.

Bør kunne: Definere en full stack i én compose-fil.

Hva: Reverse proxy og webserver.

Hvorfor: Ruter trafikk til riktig tjeneste og håndterer TLS.

Bør kunne: Sette opp reverse proxy for flere subdomener.

Hva: Oversetting av domenenavn til IP-adresser.

Hvorfor: Nødvendig for at noen skal finne applikasjonen din.

Bør kunne: Sette opp A- og CNAME-oppføringer selv.

Hva: Kryptert kommunikasjon mellom klient og server.

Hvorfor: Standard krav for enhver produksjonsside i dag.

Bør kunne: Forstå hvordan sertifikater fornyes automatisk.

Hva: Gratis, automatiserte TLS-sertifikater.

Hvorfor: Gjør HTTPS tilgjengelig uten kostnad eller friksjon.

Bør kunne: Sette opp certbot med automatisk fornyelse.

Hva: Regelmessig sikkerhetskopiering av data.

Hvorfor: Data uten backup er data du vil miste før eller siden.

Bør kunne: Ha automatiske, testede backup-rutiner.

Hva: Overvåking av oppetid og ytelse.

Hvorfor: Du vil vite om noe er nede før brukerne sier ifra.

Bør kunne: Sette opp varsling ved nedetid.

Hva: Selvhostet verktøy for oppetidsovervåking.

Hvorfor: Gir full kontroll over egne varsler uten tredjepartsavhengighet.

Bør kunne: Overvåke alle egne tjenester med varsling til Telegram.

Hva: Automatisert testing og utrulling.

Hvorfor: Reduserer manuelle feil og gjør utrulling forutsigbar.

Bør kunne: Sette opp en enkel pipeline som bygger og deployer automatisk.

Prosjektforslag: Deploy en fullstack-app til egen VPS med Docker Compose og nginx.