Repository navigation
D‐cide 2
D-cide 2 lyftes under WebbUs kodstuga 17e november 2025 som en milestone inför vintermötet i februari. Planen är att i tydliga steg utveckla en kandidat som sedan kan byggas ut till nya medlemssidor och en ny backend. Av denna anledning utsattes en projektgrupp för att producera en tydlig roadmap och standarder inför projektet.
Frontenden bör fortsatt vara en SPA då den involverar stora mängder dynamisk data som ej bör cacheas av frontenden. I praktiken behövs inget framework men NextJS borde användas för att hålla samma standard som new.d-sektionen.se. TypeScript bör användas. ESLint och Prettier bör användas med tydliga GitHub-workflows för att påtvinga linting och formatting. PostCSS-moduler räcker till styling, men ett stilspråk bör tas fram i formen av CSS-variabler. SWR är bra för att synkronisera data, men bör användas främst genom wrapper-hooks. Docker-compose bör användas som dev-miljö så att det räcker med docker compose up för att få igång en lokal miljö med rimliga defaults.
Använda pnpm eller bun för snabbare package management
Jag har inte superstarka åsikter kring backenden, dock tror jag det är viktigt att fokusera på att hålla backend-apit så enkelt som möjligt så det blir mindre att lära sig. I mitt huvud innebär detta ett barebones HTTP bibliotek - fördelaktigen Express (TypeScript) eller FastAPI (Python). Viktigt att stabil type hinting, opinionated auto-formatting och linting finns tillgänglig precis som för frontenden. Migration kan göras med exempelvis umzug eller dbmate och jag tycker vi i grunden bara kör rena SQL-statements med wrapper-funktioner som ger rätt typer, en ORM känns som overhead med den typen av queries vi vill göra. Vi måste också sätta upp en standard för hur api-routes ska se ut, tror SWR föredrar att man inte använder querystrings till APIt utan kör t.ex /api/events/1 istället för /api/events?id=1; väljer vi att använda querystrings får vi etablera att vi använder till exempel qs-bibliotekets syntax. Docker-compose bör användas som dev-miljö så att det räcker med docker compose up för att få igång en lokal miljö med rimliga defaults.
Jag håller för det mesta med Malte om att en FastAPI backend skulle passa bra men jag skulle vilja se strikt linting och typechecking med ruff och based-pyright (eller MyPy) samt att kräva att alla funktioner har docstrings. Detta kan vi göra med github action och pre-commit. Det är välldigt svårt att förstå vad vissa funktioner gör på backenden idag och detta skulle förhoppningsvis hjälpa med det
Asyncpg verkar vara ett bra bibliotek för att interagera med postgres från Python men jag vet inte vad som skulle användas för migrations, kanske bara ett externt verktyg som är obundet till Python?
Typescript har bättre typechecking än vad som går att åstakomma med hjälp av Python, men då så blir väl frågan om vi bara ska använda NextJS för fullstack?
Jag instämmer med föregående om att en ny backend för D-Cide - separerad från den befintliga - är gynnsam. Att börja med en ny backend för D-Cide ger en grund som kan expanderas till en komplett backend som motsvarar den vi har nu då det redan tvingar definition av funktioner för att nå exempelvis User för att fungera. Jag anser att hela backenden tillslut bör vara skriven i samma tech stack.
Utöver följande anser jag att standards för linting, typning samt docstrings bör utvecklas. Hur dessa ska se ut har jag ingen direkt åsikt kring, sålänge dem finns.
-
Problemet med vår nuvarande backend ligger inte i Django. Det ligger i att för många av Djangos verktyg används inkonsekvent och med bristande förståelse för vad Django faktiskt gör åt oss. Backenden är i min mening en serie speciallösningar staplade på varandra som inte tar hänsyn till den roll verktygen är ämnade att ha om de används i ett projekt. Det här bidrar till mystik kring vad som faktiskt händer.
Ett exempel på detta är att vi använder Djangos routing modul, men sedan definierar flera egna routes själva. Routingmodulen skapar en specifik URL-struktur (kopplad till osynliga ViewSets) som följer en viss standard, medans vi sedan definierar efter en annan samt skriver egna Views. Utöver att detta skapar förvirring gällande användning av API så överkompliceras backenden, och tvingar alla som jobbar på den att lära sig Django på en alldeles för djup nivå.
-
Att introducera ny teknologi till våran tech stack anser jag vara negativt, då vi riskerar att ha så många olika teknologier att ingen kandidat till WebbU realistiskt sett kommer att ha tid att sätta sig in i allt hen behöver för att aktivt kunna bidra till projektet. Om vi skiftar till ny tech och inte blir klara med migrering av hela backend i år har vi en dubbel tech stack för nästa års utvecklare att lära sig.
Mitt förslag är att vi skriver en ny backend, men behåller Django. Vi definierar en lista med tillåtna moduler:
Ska vi använda routing (och därav ViewSets, Serializers och en viss URL-struktur) eller ska vi använda egendefinierade routes och vanliga Views (ger mer granulär kontroll men kräver mer skrivande och kodupprepning)? etc.
Innan utveckling påbörjas bör ett dokument med tillåtna teknologier samt moduler inom valda teknologier ritas upp av en grupp om minst två personer. Detta anser jag borde vara ett krav för alla nya projekt, eller tillägg på projekt (så som expansion av backend, nya sidor på frontend etc.).
Att jobba på detta sätt gör att vi inte hamnar i en situation där vi har en produkt med total avsaknad av dokumentation eller en överkomplicerad tech-stack. Även om vi inte skulle behålla Django anser jag att ovan arbetssätt är relevant.