Om KravNav
Det här är en containeriserad prototyp för målbilden.
Frontend består av en lättviktig statisk webb byggd i HTML, CSS och JavaScript, med Nginx som webbserver.
Backend är ett Python-baserat REST-API byggt i FastAPI, med SQLAlchemy mot PostgreSQL 16.
Applikationen körs i Docker Compose med tre separata tjänster för webb, API och databas.
Lösningen är byggd för att vara enkel att förstå och för att visa koncept, struktur och arbetsflöden, snarare än att vara en slutlig produktionsarkitektur.
Frontend
Frontenddelen är byggd som en statisk webbapplikation i vanlig HTML, CSS och JavaScript. Det betyder att den inte använder något större frontend-ramverk som React, Vue eller Angular. För ett utvecklingsteam innebär det att användargränssnittet är relativt direkt och lätt att läsa, men också att mer av strukturen och beteendet ligger manuellt i klientkoden.
För den här prototypen har det varit en medveten fördel. Lösningen blir liten, överskådlig och snabb att förstå, vilket passar bra när syftet främst är att visa arbetsflöden, vyer och funktionella idéer snarare än att bygga ett fullskaligt frontend-landskap.
Nginx
Nginx används här som webbserver för frontenddelen. Dess uppgift är att leverera de statiska filerna, alltså HTML-sidor, JavaScript, CSS och bilder, till användarens webbläsare.
I den här lösningen har Nginx en enkel roll. Den innehåller ingen avancerad affärslogik och inget eget applikationslager, utan fungerar främst som ett snabbt och stabilt sätt att presentera frontendfilerna. För ett utvecklingsteam är det därför bäst att se Nginx som ett tunt leveranslager för webbgränssnittet, inte som en central del av domänlogiken.
JavaScript i klienten
JavaScript används för att göra gränssnittet interaktivt. Det hanterar till exempel inloggning, hämtning av data från API:t, rendering av kravlistan, filtrering, öppning av detaljvyer och olika användarinteraktioner i gränssnittet.
Eftersom det inte finns något större frontend-ramverk ligger mycket av logiken nära själva sidorna. Det gör prototypen lätt att felsöka och förstå i liten skala, men ett framtida utvecklingsteam kan vilja avgöra om samma struktur ska behållas eller om klienten på sikt bör formaliseras mer.
FastAPI
FastAPI är det Python-ramverk som används för backend och API. Det ansvarar för att definiera applikationens HTTP-endpoints, ta emot anrop från frontend, validera indata, returnera JSON-svar och hålla ihop backendlogiken.
I praktiken är det FastAPI som gör att klienten kan hämta krav, skapa nya poster, uppdatera befintliga krav, hantera statusövergångar, läsa historik och arbeta med kommentarer och användarrelaterade funktioner. För utvecklingsteamet är det alltså FastAPI-lagret som motsvarar applikationens tjänsteskikt på serversidan.
Uvicorn
Uvicorn är den applikationsserver som kör FastAPI-appen. Den gör det möjligt att faktiskt exponera Python-applikationen som en körbar webbtjänst.
Det är alltså inte Uvicorn som innehåller affärslogik, utan den fungerar som driftlagret för själva API-processen. Ett utvecklingsteam behöver normalt inte lägga mycket verksamhetsfokus på Uvicorn, men bör känna till att det är den komponent som kör backendapplikationen i runtime.
SQLAlchemy
SQLAlchemy används som databaslager och ORM. Det innebär att backendkoden kan arbeta med Python-objekt och modeller i stället för att manuellt skriva all databaslogik som rå SQL för varje operation.
I KravNav används SQLAlchemy för att beskriva modeller som användare, krav, kommentarer, historik och kopplingar mellan krav och tillämpningsområden. För ett utvecklingsteam är detta viktigt, eftersom SQLAlchemy-lagret i praktiken beskriver hur domänmodellen är mappad mot databasen och hur data läses, skapas och uppdateras.
Pydantic
Pydantic används för datamodellerna i API:t, särskilt för in- och utgående payloads. Den hjälper backend att validera att inkommande data har rätt struktur och typ, och den används också för att forma de svar som skickas tillbaka till klienten.
Det gör att API-kontraktet blir tydligare och mindre felkänsligt. För ett utvecklingsteam betyder det att mycket av gränsytan mellan frontend och backend redan är explicit uttryckt i kod, vilket underlättar vidareutveckling, testning och eventuell dokumentation.
PostgreSQL 16
PostgreSQL är den relationsdatabas som används för persistent lagring. Det är där den faktiska applikationsdatan finns, till exempel kravposter, statushistorik, kommentarer, användare och roller.
Valet av PostgreSQL gör prototypen betydligt mer realistisk för fortsatt utveckling än om datan bara hade legat i filer eller minne. För ett övertagande team är detta en viktig signal, eftersom lösningen redan har en riktig databasmotor och en tydlig modell för långlivad lagring.
psycopg2
psycopg2 är Python-drivern som används för att ansluta till PostgreSQL. Den ligger under SQLAlchemy och sköter själva databaskommunikationen mellan Python-applikationen och databasmotorn.
Utvecklare arbetar sällan direkt mot psycopg2 i den här typen av lösning, men den är ändå viktig att känna till eftersom den är den tekniska länken mellan backend och databasen.
Autentisering och behörighet
Lösningen innehåller ett enkelt auth-lager där inloggning och sessioner hanteras med token-baserad autentisering. Biblioteken passlib och python-jose används för lösenordshashning respektive tokenhantering.
Det innebär att prototypen inte bara visar datahantering, utan även grundläggande åtkomstkontroll. För ett utvecklingsteam är detta ofta intressant eftersom det visar hur roller, användare och skyddade operationer är tänkta att fungera konceptuellt, även om implementationen senare kan komma att ersättas eller vidareutvecklas.
Docker Compose
Docker Compose används för att definiera och starta applikationens olika tjänster som en sammanhängande lösning. I KravNav betyder det att webb, API och databas körs som separata men samverkande komponenter.
För ett utvecklingsteam är detta värdefullt eftersom arkitekturen redan är uppdelad i tydliga lager. Det gör det lättare att förstå ansvarsfördelningen mellan komponenterna och skapar en naturlig grund för vidare utveckling, testning och framtida ompaketering om teamet väljer en annan målmiljö senare.