work
This commit is contained in:
30
docs/technical-decisions.md
Normal file
30
docs/technical-decisions.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Tekniske Valg
|
||||
|
||||
## Hvad jeg byggede
|
||||
En SvelteKit-baseret produktivitetsapp med login, projekter, tasks, issue-overblik og live opdateringskanal.
|
||||
|
||||
## Hvorfor SvelteKit
|
||||
- Server `load` gør det enkelt at hente data tæt på routen.
|
||||
- Form actions passer godt til mutationer uden tung klientlogik.
|
||||
- SSR giver hurtig første render og bedre default UX.
|
||||
- SSE passer til lette live-opdateringer uden fuld websocket-kompleksitet.
|
||||
|
||||
## Hvordan det virker i praksis
|
||||
- Brugeren logger ind.
|
||||
- Dashboardet henter projekter, tasks og issues server-side.
|
||||
- Brugeren kan oprette projekter og tasks via actions.
|
||||
- Projekter kan opdatere status og beregnet progress.
|
||||
- En SSE-endpoint kan sende opdateringer til klienten.
|
||||
|
||||
## Hvad der virkede godt
|
||||
- SvelteKit gjorde dataflowet kort og tydeligt.
|
||||
- Server actions holdt mutationerne samlede.
|
||||
- Drizzle passede godt til schema-drevet udvikling.
|
||||
|
||||
## Hvad der var udfordrende
|
||||
- Realtime sync fra GitHub/Gitea kræver API-specifik integration.
|
||||
- Progress bør helst beregnes robust i databasen eller via en service.
|
||||
- SSE er nemt til énvejskommunikation, men websocket kan blive nødvendig senere.
|
||||
|
||||
## Professionel brug
|
||||
Løsningen kan bruges som intern project tracker, support-overblik eller developer dashboard med integrerede issues og statusopdateringer.
|
||||
Reference in New Issue
Block a user