Do you need help with setting up a simple custom server in Next.js? This trick will get you a long way!

For many frameworks it is necessary to create your own server that listens and handles user interactions with your application.

In Next.js, a server is automatically generated 🤯. And, so, for most, there is no need to think about creating your own server. However, sometimes, it might be necessary with a custom server. In particular, due to two main reasons:

Wanting to run some code before the Next.js application is running (a common issue)

Creating custom server patterns

The reason why I wanted to create a custom server was due to reason 1. After multiple attempts, I figured that one way to do it was to replicate the server that Next.js generated when building a standalone application. This is a bit “hacky”, but it is a lot easier than many of the other alternatives! In addition, it serves as a baseline for more complicated custom servers 📈

A standalone is just a smaller version of the application you are creating which only contains the necessary parts for running the application. You can create a standalone by adding output: ‘standalone’ to your config:



After having built the application (with yarn build or etc.), a standalone directory will be available in the root of your project. Inside it you will find ‘server.js’ which looks something like this:



An easy way to create a custom server would be to copy the file above. However, we can't do this as there is a super-duper-long config that we need to get from ‘required-server-files.json' 🤔. My trick for getting this was by using fs and JSON.parse. Hence, I ended up with a server file that looked like this:

It is important that the import path of ‘required-server-files.json’ is correct.

Tada! You now have a basic custom server that you can use and that you are free to edit it is as much as you like 👑.

Run your application with your new custom server by using the command below instead of next start:

That was all for now! Bye 👋

How to create a simple Custom Server in Next.js

Mange mener mye om designsystemer. Noe det ikke er så mye snakk om er hvordan designsystemer kan bidra til universell utforming, som jo er spesielt relevant nå som WAD trer i kraft og vi må rapportere hvordan alle løsningene våre dekker WCAG-kravene.

Prompt til Dall-E: "An oil painting in munch style of a design system"



Når jeg snakker om designsystemer tenker jeg i denne artikkelen på kombinasjonen av design guidelines, figma-komponenter og et komponentbibliotek i for eksempel React. Det er gjerne et team som er ansvarlige for et slikt system, og det brukes bredt ut i organisasjonen.

Så, hvordan kan designsystemer bidra til universelt utformede løsninger?

Designsystemet kan bli det faglige fyrtårnet for UU i en organisasjon

Designsystemet har en unik mulighet til bli det faglige fyrtårnet for UU, på grunn av kulturen og samfunnet et designsystem bidrar med i en organisasjon. Ofte har man faste møter mellom designere og utviklere, slack-kanaler for diskusjon og retningslinjer til bruk av komponenter. På alle disse områdene har man muligheten til å drive diskusjoner og synliggjøre UU. I tillegg kan teamet bak designsystemet prioritere utfordringer knyttet til universell utforming over for eksempel ny funksjonalitet.

Universelt utformede komponenter legger et solid grunnlag for god praksis

Når enkeltkomponenter er universelt utformet og testet grundig legger det et godt grunnlag for teamene som skal bruke designsystemet. Det gjør det rett og slett enklere for de ulike teamene å lage gode og universelt utformede løsninger. For eksempel kan designsystemet kreve ledetekster når man bruker seg av inputfelt, i form av varsler i koden hvis man ikke husker på å legge det inn. Designsystemer har i tillegg gjerne dokumentert hvordan man skal bruke en komponent på en universell utformet måte (se for eksempel Aksel). Dermed blir teamene støttet i å ta universelt utformede valg, også når man ikke kan få hjelp fra selve koden.

Teamene som bruker designsystemet sparer tid ved å kunne tenke på helheten og ikke enkeltkomponentene

Ved å slippe å bruke tid på å teste og utvikle enkeltkomponentene kan man bruke mer av tiden på å teste helheten. Designsystemteamet og deres bidragsytere burde dypdykke i hver komponent og sørge for at den er så tilgjengelig som mulig for en bred brukergruppe. Dette kan for eksempel gjøres ved å undersøke hvordan andre designsystemer har løst lignende problemstillinger, forstå WCAG-kravene og anvende dem på riktig måte i en komponent. Siden denne jobben da er gjort, kan det gjøre at de enkelte teamene heller kan bruke tid å sørge for at komponentene går godt sammen og teste kombinasjonene av komponentene.

Designsystemer oppfordrer til felles løsninger på like problemer, som gjør det enklere for brukere av skjermlesere til å benytte systemene

Et godt prinsipp innen universell uforming er at like ting skal oppføre seg likt (se f.eks. 3.2.4). Et designsystem løser dette ved at man benytter samme komponent konsekvent på tvers av systemet. I tillegg har man gjerne eksempler på bruk av en komponent som kan oppfordre til like og forutsigbare løsninger på tvers av organisasjonen, for eksempel hvilke komponenter som passer i hvilke situasjoner.

Det var de positive sidene, men hva med risikoene?

Alt er ikke perfekt selv om komponentene er universelt utformet

Kombinasjonen av ulike komponenter kan bli feil når man setter komponentene sammen med hverandre. Ta et helt tenkt eksempel som absolutt ikke har skjedd der jeg jobber: Et team tok i bruk designsystemet og la inn en dropdown i en tabell som igjen lå inni en modal. Denne kombinasjonen var ikke testet på forhånd, og ledet til tastaturfelle. Det er derfor viktig at teamene som bruker designsystemet ikke tenker at alt er fryd og gammen, men at man selv også bruker tid på å teste sidene man utvikler. Uansett hvor universelt utformet designsystemet er.

I tillegg må hvert team som tar i bruk komponenter fra designsystemet tenke gjennom valgene og sørge for at de benytter komponentene på riktig måte. For eksempel er det blitt vanlig at det som ser ut som knapper kan være enten en knapp eller en lenke – og vis versa. Men for en bruker som navigerer med tastatur oppfører ikke de elementene seg likt. På knapper kan man bruke space og enter for å trykke på, mens på lenker kan man kun bruke enter.

Det er ikke “bare-bare” å lage universelt utformede komponenter, og det er lett å gå i grøten selv med de beste intensjoner

Å lage universelt utformede komponenter er ikke en enkel oppgave. Det krever at man setter seg inn i standarden for hvordan komponenter utvikles, en standard som ofte ikke er særlig lett å finne når man jobber med mer komplekse komponenter. For eksempel brukte Slack over ett år på å forbedre og tilgjengeliggjøre en select for alle. Det krever altså tid og innsats for designsystem-gjengen og teamene som benytter seg av det for å lage gode og gjennomførte komponenter som svarer til lovkravene og forventningene til alle brukerne.

Totalt sett er designsystemer kjempeviktige i arbeidet med å lage universelt utformede løsninger. Så lenge man husker på at de ikke på magisk vis dekker absolut alt, er du good!

Designsystemet ditt kan bane vei for gode og universelt utformede løsninger

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk forteller om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips!

Hvem er jeg?

Linn her 👋

Utdannet grafisk designer fra Westerdals og Berghs School of Communication i Stockholm

Jobbet i byråverden i 13 år før jeg begynte i Bekk for 3 år siden

Jeg kommer fra en arkitekt- og kunstnerfamilie der jeg tidlig fikk innblikk i det skapende. I stedet for å følge i mine foreldres arkitektfotspor, søkte jeg min egen vei innenfor de kreative fagene. Jeg drives av å formidle visuelt, av det å skape ulike uttrykk for å gi merkevarer personlighet.

Hva gjør jeg (og hvordan)?

De siste 2,5 årene har jeg jobbet med Strim hos RiksTV. Strim er en utfordrer i TV-bransjen som tror på enkelhet og valgfrihet for kundene. Derfor samler Strim TV-kanaler og strømmetjenester i ett abonnement.  

I mitt team har vi ansvar for de kommersielle sidene på strim.no. Arbeidet består i å skape motivasjon for å prøve Strim, designe gode brukeropplevelser og utvikle Strims visuelle identitet på web. Det gjør vi gjennom å bygge en god redaktøropplevelse med CMSet Sanity.

Teamet har jobbet sammen i over et år. I tillegg til designere og utviklere, har vi webredaktør, SEO-spesialist og perfomance marketing-roller i teamet. Det er ordentlig kult å jobbe mot både potensielle sluttkunder og mot interne «kunder» i form av redaktører.

Det å være designer innen digital produktutvikling favner ekstremt bredt. Vi har titler som UX-designer, UI-designer, tjenestedesigner, interaksjonsdesigner, grafisk designer og så videre. I mylderet av opplevde forventninger, har det vært litt utfordrende å definere hva som er mine primære ansvarsområder som visuell designer. Vi designere har ulike perspektiver, og vi har alle viktige bidrag inn i den totale brukeropplevelsen. 

Hvilket tips ville jeg gitt meg selv i starten av oppdraget?

Husk på hva du har i bagasjen og hva du bringer med deg inn i prosjektet. Det kan være lett å bli dratt inn i det du tror andre forventer. Grip sjansen når du ser en mulighet og vis med handling hva du mener er riktig. Grove skisser er godt nok utgangspunkt for tverrfaglige diskusjoner.

Dagens designtips

Fornybare energikilder som vind og sol vil sannsynligvis spille en nøkkelrolle i framtiden energisystemer. Den store utfordringen er å sørge for stabil og forutsigbar tilgang på energi, dag og natt, alle dager, over hele verden. I denne luka ser vi på en forskningsartikkel på Long-Duration Energy Storage (LDES).

Fornybare energikilder som vind og sol vil sannsynligvis spille en nøkkelrolle i framtiden energisystemer. Den store utfordringen er å sørge for stabil og forutsigbar tilgang på energi, dag og natt, alle dager, over hele verden. Fossilenergi og kjernekraft har gjort denne jobben i alle år, og er dessverre nødvendig i overgangen til et stadig mer fornybart energisystem. Det er dessuten få land som har så mye regulerbar vannkraft som vi har i Norge.

Det forskes derfor mye på langvarig energilagring. I denne luka ser vi på en forskningsartikkel på Long-Duration Energy Storage (LDES) av Jesse Jenkins med flere (og tilhørende tweet-tråd).

Energi lagres når det er overproduksjon, og tilføres kraftnettet når det er for lite produksjonskapasitet.

Kostnadene for lagringssystemene må være lønnsomme for å være levedyktige.

Kapasiteten og effekten for oppladning og utladning må være tilstrekkelig.

Forfatterne har brukt 100 timers vedvarende utladning som definisjon på langvarig i artikkelen.

Elektrokjemiske batterier er en naturlig kandidat for LDES. Mellomlagring som hydrogen er også en kandidat, spesielt ettersom elektrolyse ser ut til å være underlagt Wright’s lov. Det forskes imidlertid på mange andre lagringssystemer, som komprimert luft, gravitasjon og varmelagring i keramiske elementer og flytende salt. Hvilke langvarige energilagringssystemer vil vi bruke om fem og femti år?

Forskningsartikkelen: The design space for long-duration energy storage in decarbonized power systems

Langvarig energilagring er kritisk i et fornybart energisystem

Java har lenge vært kongen på tronen i IT-Norge og blir brukt på utallige prosjekter. Miljøet rundt Java er modent og vi har gode rammeverk. Java er trygt og kjent, og Java Virtual Machine (JVM) er en god platform. Java og platformen fungerer.

Så hva er problemet? Java er teknisk gjeld og det er på tide å modernisere stacken.

Teknisk gjeld sa du?

Det finnes mange typer av teknisk gjeld og en av de vanligste er dårlig kode, men teknisk gjeld er så mye mer. Det er JavaScript appen som ikke er over på TypeScript, det er den bygg-serveren din som ikke har blitt modernisert på flere år, det er den testen du burde ha skrevet men ikke har fått gjort enda, og det er Java-koden din.

Teknisk gjeld er et kjempenyttig verktøy og uten teknisk gjeld vil det å utvikle gode løsninger ta mye lengre tid. Vi tar snarveier, tar opp et lån i form av teknisk gjeld, lager gode løsninger og vurderer om den gjelden vi har tatt opp må betales tilbake, eller om vi kan leve med litt gjeld. Ha et forhold til hvor mye teknisk gjeld som er greit for ditt prosjekt!

Vi har mye Java-kode og oppfordringen min er ikke å kaste den Java-koden vi bruker i dag.

Det å skrive en ny frontend-applikasjon i JavaScript og ikke TypeScript i dag er teknisk gjeld. Og det samme vil jeg si for Java. I dag finnes det et moderne alternativ til Java. Kotlin! Så min oppfording er: slutt å skriv ny Java-kode. Ta steget og skriv den nye koden din i Kotlin.

Så hvorfor Kotlin?

Den gode nyheten er at man kan bruke Java og Kotlin i samme prosjekt. Kotlin har ekstremt god interop med Java, og det vil si at man kan inneføre ny Kotlin-kode uten å måtte tilpasse den gamle Java-koden din. Man kan bruke Java-kode fra Kotlin, og Kotlin-kode fra Java som om det skulle vært samme språk.

Så hva er fordelen med å gå over til Kotlin og hva kan Kotlin tilby som Java ikke kan?

Digg syntaks. Kotlin introduserer mye syntakssukker. Default arguments, lambdas med implicit arguments, data classes, let/apply for å lage nye scopes, expression functions og extension functions. Det er rett å slett for mye til å liste. Sjekk Kotlin Syntax og Kotlin Idioms for eksempler.

Et bedre standard library. Standard-librariet til Kotlin inneholder en haug med funksjoner som gjør livet enklere. Jeg blir stadig overrasket over at akkurat den funksjonaliteten jeg trenger dukket opp på autocomplete. Liste-APIet inneholder blant annet associate, groupBy, chunked og mapIndexed for å nevne noen.

String templates. Ikke noe mer StringBuilder, i Kotlin har man muligheten til å bruke string-templates. Både for enkle tekster, men også for tekster som går over flere linjer. "Det er ${positivtOrd}!"

Smart-casting. Kotlin kompilatoren er smart. Når man har sjekket en type med if/when vil kompilatoren forstå det det vi jobber med er typen vi sjekket mot. Ikke noe unødvendig type-casting påkrevd.

Null-safety. Null-håndtering er innebygd i typesystemet og gjør det mye enklere å håndtere nullable-types. Ingen* flere NullPointerExceptions og try/catches for å håndtere null er en ting av fortiden. (* obs: man kan fortsatt få NPE når man jobber mot Java-kode)

Bedre støtte for generics. Kotlin kommer med bedre støtte for generics. Med inline reified types kommer man seg rundt problemet med type-erasure og man kan sjekke typer på generics i runtime som i Java ville vært borte.

Nye måter å strukturere koden på. Extension functions som et alternativ til utils-funksjoner som lar deg utvide funksjonalitet på kode utenfor kodebasen du er i. Funksjoner som first class citizens. Og ingen en-til-en relasjon mellom klasse og fil.

… og mye mere. Sjekk ut den offisielle dokumentasjonen for mer snacks!

Hva nå?

Ta steget. Tør å ta steget til å skrive ny kode i Kotlin og slutt med Java. Du kan fortsatt bruke de kjente bibliotekene, rammeverkene og den eksisterende Java-koden din. Læringskurven er lav og med Kotlin vil du få en mye bedre utviklingsopplevelse. Språket er moderne, platformen er den samme, syntaksen er digg og du vil få nye verktøy for å skrive vakker og lesbar kode.

Så hva venter du på? Start med Kotlin i dag.




13-Dec

Today's posts

How to create a simple Custom Server in Next.js

Designsystemet ditt kan bane vei for gode og universelt utformede løsninger

Dagens designtips

Langvarig energilagring er kritisk i et fornybart energisystem

Slutt med Java