Milas Holsting
56c9cca016
Some checks failed
Build and Push Container Image / build-and-push (push) Failing after 3m31s
31 lines
1.3 KiB
Markdown
31 lines
1.3 KiB
Markdown
# 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.
|