Utforming av WebConfig

“Tech stack”

Backend: Python, FastAPI, Github API, SMTP, Koyeb (Hosting)

Frontend: Javascript, React, Vite, Tailwind CSS, Firebase (Hosting)

Bakgrunn for løsningen

Sommeren 2024 satte jeg i gang med frilans for meg selv. Jeg har alltid lurt på hvordan det ville vært å jobbe selvstendig med kunder, og med erfaringen som kom fra bacheloroppgaven, følte jeg meg rustet nok til å kunne ta på meg egne oppdrag.

Under lufting av idéen om å prøve meg som frilanser blant venner fikk jeg høre av en venn av meg, Eivind Haugejorden Schau, at han var i ferd med å starte sitt eget foretak innen PR og kommunikasjon. Det ble starten på et samarbeid hvor jeg har fått lov å være med å hjelpe med både design og utvikling av hjemmesiden til hans nye prosjekt kalt Schriv.

Det ene ledet til det andre og etter å ha samarbeidet med Eivind en stund ble jeg også kontaktet av Erlend Ingebritsen, gründeren bak Ekte Kommunikasjon, som var på jakt etter en utvikler for hans nye bedrift ved navn Tinde Advise. Dette er en bedrift med fokus på PR og kommunikasjon, med gode erfaringer fra mange tidligere klienter som store og små bedrifter, og kjente offentlige personer.

Planlegging

Veldig tidlig i kommunikasjonen med Tinde kom det frem at den løsningen de tidligere hadde tatt i bruk gjennom en annen leverandør ikke var tilstrekkelig for hva de ønsket av en nettside. De hadde tidligere brukt en leverandør som tok i bruk Webflow for å lage nettsiden. Problemstillingen her var at løsningen for å foreta endringer i innhold var for komplisert beskrevet, noe som gjorde at de ble avhengig av leverandør for å kunne gjøre endringer. Dette gjorde ofte at det tok tid før endringer ble gjort, og at de gjerne kostet mer enn de burde da de måtte betale leverandør for deres tid.

Det ble tydelig for meg at jeg måtte utvikle en egen løsning for dette. Fra tidligere av, og basert på mine samtaler med Eivind, var det fra før av tenkt at endringer kunne skje gjennom kundenes egen Github konto. Planen var da at jeg skulle opprette en organisasjon, der jeg la in prosjektet, og at de deretter kunne opprette egen konto hvor jeg da kunne overføre all eierskap til kunden selv. For Eivind hørtes dette ut som en grei nok løsning, og han synes måten var enkel nok for hans bruk. Etter praten med Tinde derimot skjønte jeg at jeg måtte finne en bedre løsning for kundene mine. Dersom jeg i fremtiden skulle tatt på meg flere frilans oppdrag burde de kunne forvente en enda enklere og visuell løsning for endringer. Det ble til en god del skissering og tankekart på hvordan dette kunne løses, hvor jeg til slutt endte opp med å ta inspirasjon fra min egen Bacheloroppgaven, kombinert med Wix/Wordpress og liknende.

Bachelor løsning

For bachelor oppgaven hadde vi som oppgave å lage en nettside for Ignist AS. Jeg hadde ansvar for kontroll/admin panel, samt backend, database osv. Det vi gikk for av løsning der var å lagre spesifikke felt på nettsiden i NoSQL database. Det kunne da veldig visuelt hentes og endres. For å diskutere noen av problemstillingene rundt en slik løsning som er noe jeg har tatt selvkritikk på i etterkant, vil jeg nevne noen fordeler og ulemper.

Fordeler

• Enkelt å endre
• Lett å sette opp visuelt
• Forståelig for andre utviklere som kommer etter
• Ingen downtime ved endring/endring skjer i santid

Ulemper

• Dyrt
• Avhengig av kobling til database
• Kan sette grenser for frihet i endringer
• Kan ikke standariseres/utvides for andre kunder

For å takle disse problemene bestemte jeg meg for å se nærmere på løsningen knyttet opp mot Github. Den største fordelen ved å bruke Github er at en ikke trenger å ha noe database som nettsiden må kobles opp mot, og endringer vil derfor bli gratis å foreta (innenfor visse grenser). Oppsettet jeg tenkte meg frem til ble derfor å koble opp en løsning hvor en kan gjøre endringer i et repository men med en annen mer visuell interface. Ut av dette ble løsningen WebConfig født.

Modeller

Overfladisk

Løsningen WebConfig er en sammensatt løsning av frontend som har hovednavnet WebConfig, og tilhørende backend med API, som jeg har valgt å kalle FreelanceAPI. Modellen for hvordan de forskjellige delene hører sammen, veldig overfladisk ser slik ut:

Som en da ser på figuren over er det koblet opp som at en da henter data fra Github repository på WebConfig, via backend, og da gjør endringer og commiter disse til WebConfig. Det gjør at hver commit vil sette i gang en ny deployment av nettsiden. Dette kan i utgangspunktet komme med egne problemstillinger, så jeg kjapt vil adressere de største nå. Dersom endringer feiler vil deployment feile, og derfor vil ikke endringene lastes opp. Nettsiden i seg selv kjører da på tidligere endringer og blir ikke påvirket av feilen. Dersom feil skjer, bes kunden kontakte meg og jeg vil rulle tilbake til tidligere commit og fikse endringer. Det vil også etterhvert komme en oversikt hvor en kan se om kjøringen feilet eller ei. Hver endring skaper en ny commit, det vil derfor ta tid før alle endringer kommer på plass. Dette er en av de største ulempene en kan også ses på som en fordel da det gjør at det er enkelt å se hvor feilen skjer dersom en feil skulle oppstå. Jeg har til dels kommet unna problemet med mange commits ved at endringer i tekst kan gjøres flere steder for så å lagres felles som ved når du manuelt klikker lagre i et Word-dokument.

Sekvensdiagram

Når en bruker logger inn i WebConfig er de først nødt til å be om kode. Dette gjøres ved å skrive inn epost og be om kode. Det vil da lagres en kode opp mot epost adressen som er blitt brukt. Denne koden er gyldig i 2 timer fra registrering.Bruker blir så omdirigert til side for innlogging hvor en skriver inn koden sammen med epost adresse. Ved innsending av innloggingsinfo vil det bli sjekket hvilke sider bruker har tilgang til. Dette er for å unngå unødvendige kall på backend senere. Når en bruker klikker inn seg på en nettside de har tilgang til fra sitt skrivebord blir det gjort kall til backend som igjen sjekker at koden ikke er utgått og at bruker enda har tilgang til nettsiden, før det sendes tilbake info om nettsiden, som innhold. En forenklet versjon av alt sammen kan ses i diagrammet under. Her hopper diagrammet over at innhold hentes fra Github, men viser hvordan endringer sendes.

Utvikling

Løsningen WebConfig er utviklet med FastAPI og Python for backend og React + Vite med Javascript for frontend. Dette er en moderne stack som er rask og effektiv å jobbe med. Backend tar seg av alt av logikk som å lagre kode, sende epost, hente innhold i filer, og lagre endringer. Frontend har en visuell gjennskaping i Javascript av de ulike nettsidene og gjøre at det er enkelt for bruker å se hvor endringer gjøres. Det blir også gitt en egen manual til hver kunde for gjennomgang av endringer.

For å bevare potensielt sensitiv kode og data har jeg skapt min egen autentiseringsløsning som generer en kode som fungerer som innlogging. Jeg deler dessverre ikke repository til verken API eller frontend av sikkerhetsmessig årsak, men hvis du har noen spørsmål rundt liknende prosjekter, ta gjerne kontakt!

Resultat

Løsningen WebConfig er blitt tatt godt imot av kundene mine, og det er allerede blitt gjort endringer gjennom siden. Resultat av løsningen kan ses på webconfig.solli.dev.