Anders testet Blazor for første gang på et kundeprosjekt

Nå gir han bort sine beste tips. - Vi gikk et par runder frem og tilbake før vi landet på om Blazor egnet seg.

Anders Marschsteiner i Bouvet Norge testet Blazor for første gang på et ekte prosjekt. 📸: Privat
Anders Marschsteiner i Bouvet Norge testet Blazor for første gang på et ekte prosjekt. 📸: Privat Vis mer

Vi testet Blazor for første gang i utviklingen av en ny portal for en kunde. Her kan du lese mer om erfaringene fra vårt første møte med den «hete» teknologien.

Blazor blir ofte omtalte som det nye, store innen kodeverden. Stadig flere etterspør Blazor, antagelig fordi det løser litt av utfordringen med et uoversiktlig frontend-landskap som mange backendutviklere ikke er komfortable med.

Nylig fikk vi inn en kundeforespørsel fra et større britisk mediehus. De ønsket en ny og moderne webløsning, og med en kort tidsfrist for utvikling. Dette ble en god anledning til å endelig sette fingrene i Blazor. Tidligere har vi ofte brukt React, TypeScript og nodejs, men Blazor erstattet alle disse i dette oppdraget.

Mindre kode ga høyere effektivitet

Vi gikk et par runder frem og tilbake før vi landet på om Blazor egnet seg til vårt bruk. En risiko ved å velge en ny teknologi, som Blazor, er dårlig støtte fra komponentbiblioteker og manglende «best practice» for utvikling.

En positiv opplevelse som vi raskt oppdaget med Blazor, er hvor lettvint det er å skrive .NET-kode direkte i nettleser. Dette gjorde det enkelt å dele kode mellom backend og frontend, noe som førte til minde kode og høyere effektivitet.

Det kom godt med gitt den stramme tidsplanen.

Valg av komponentbibliotek

Den første risikoen ved Blazor som vi måtte luke ut, var valg av komponentbibliotek.

Kundeportalen vi skulle lage skulle fungere som en bro mellom moderne teknologi, og samtidig støtte formater som PDF- og Excel-filer.

For å løse dette trengte vi en god PDF-viser og et datagrid med funksjoner, sammenlignbart med de du får i Excel. Vi testet ulike leverandører, men landet til slutt på komponentbiblioteketet til det bulgarske softwareselskapet Telerik. De hadde den mest ferdige og feilfrie komponentpakken.

De var også gode på ytelse, noe som var viktig i dette prosjektet for å kunne behandle store datamengder.

Utfordringer med “state management”

Vi trengte en god og testbar arkitektur, hvor applikasjonens “state” ble håndtert for å hjelpe oss utviklerne med å holde disiplinen. Den største utfordring vi støtet på ved bruk av Blazor viste seg å være manglende “state management”.

Blazor, som framework, har ingen standard-implementert arkitektur for “state management”, som Flux eller Redux. For å løse dette prøvde vi ut forskjellige biblioteker, og endte opp med å bruke Blazor-State og Fluxor.

Disse bibliotekene ga oss muligheten for “state management”, men implementasjonen av arkitekturen ble overlatt til disiplin.

Søkte inspirasjon fra JavaScript

For å finne best-practices for .NET-utvikling til nettleser, søkte vi inspirasjon fra de mer veletablerte frameworksene.

Til tross for at .NET til WebAssembly er relativt ny teknologi, er .NET til JavaScript veletablert gjennom teknologi som Fable og WebSharper.

Elmish + Blazor = Bolero

Vi ønsket å bruke Elmish som framework, ettersom at plattformen har den arkitekturen vi var på utkikk etter.

Dessverre oppdaget vi at denne ikke var skrevet med hensyn til Blazor, men basert på JavaScript. For å løse dette brukte vi frameworket Bolero. Bolero er et rammeverk som implementerer Model View Update (MVU) ved hjelp av Elmish og Blazor sammen.

Dette er en veletablert måte å utvikle webløsninger til WebAssembly - en perfekt match.

Summa summarum

Utviklingen av løsningen i Bolero gikk i grunn veldig bra. Bolero har god støtte for interop med JavaScript, der vi hadde behov for det. Det har vært enkelt å utvikle testdrevet. Det er også et relativt stort community rundt Elmish, noe som gjorde det enklere å søke etter løsninger på problemer vi støtet på underveis.

Det er viktig å ha i bakhodet at Blazor fortsatt er en ny teknologi, og i enkelte situasjoner måtte vi derfor bruke JavaScript. Men Blazor som teknologi mot WebAssembly er absolutt klar til primetime.

Et tips for å få god arkitektur i en SPA med Blazor, er å bruke et framework, som for eksempel Bolero. Summa summarum, hadde vi en god opplevelse med å bruke Blazor i dette prosjektet.

Vi sparte mange kodelinjer på å kunne dele all forretningslogikk i frontend og backend. Dette gjorde testdrevet utvikling veldig enkelt å få til. Vi leverte løsningen til tide, til budsjett og til en veldig tilfreds kunde.