I uge 38 og 39 har en stor del af mit arbejde med QuestGame været rettet mod mit læringsmål inden for databaser og datalagring, men backendudvikling har også fyldt en del.
Jeg har blandt andet arbejdet med at opnå en dybere forståelse for og anvendelse af vores backendarkitektur, Entity Framework Core, Code First, PostgreSQL, PostGIS, datamodellering og dataadgang. Undervejs har jeg oplevet, hvordan min forståelse har udviklet sig gennem arbejdet.
I uge 38 begyndte jeg mere bevidst at bruge Kolbs læringscyklus til at betragte denne proces. I Tanker om den cykliske læringsproces beskrev jeg de fire faser som eksperiment, erfaring, eftertænksomhed og begrebsdannelse.
Når jeg ser tilbage på de to uger, kan jeg se, at arbejdet med QuestGame har ført mig gennem denne cyklus flere gange.
Eksperiment – de første tekniske valg
Uge 38 handlede mest om at etablere det tekniske fundament.
På databasesiden arbejdede jeg blandt andet med valget af PostgreSQL. QuestGame har et stort behov for geografiske data, og muligheden for at udvide PostgreSQL med PostGIS var derfor vigtig.
I min status på databaser og datalagring i uge 38 arbejdede jeg med idéen om at repræsentere GPS-positioner som den spatiale datatype Point. Det åbner blandt andet for, at databasen kan udføre geografiske forespørgsler frem for blot at fungere som lager for latitude og longitude.
På backendområdet arbejdede vi samtidig videre med en feature-baseret Vertical Slice Architecture. I Status: Backendudvikling – uge 38 beskrev jeg vores valg som noget, der skulle afprøves i praksis.
I stedet for på forhånd at antage, at arkitekturen var den rigtige, blev spørgsmålet derfor, hvordan den fungerede, når vi begyndte at implementere konkrete use cases.
Det samme gjaldt EF Core og Code First. I Code First set fra et backend-perspektiv undersøgte jeg blandt andet entities, relationer, DbContext og migrations.
Eksperimentet bestod altså ikke kun i at få teknologien til at fungere, men i at se hvilke konsekvenser den havde for struktur og ansvarsfordeling.
Erfaring – når modellen møder QuestGame
Efter de første valg begyndte problemstillingerne hurtigt at blive mere konkrete.
Det blev eksempelvis tydeligt, at det ikke er nok at vælge EF Core og PostgreSQL. Vi skal også tage stilling til, hvordan vores domænemodel skal repræsenteres i databasen.
QuestGame har forskellige typer af elementer, der deler fælles egenskaber. Det førte til overvejelser om forskellige strategier til tilknytning af objektorienterede arv-hierarkier (klasser der arver fra hinanden), og det har jeg skrevet om i mit indlæg om Valg af inheritance mapping: TPH, TPT eller TPC?.
Her kunne jeg tage et konkret problem fra projektet og undersøge flere mulige løsninger. Valget af inheritance mapping er ikke blot et EF Core-valg. Det påvirker også tabeller, relationer og de forespørgsler, backend skal udføre.
På samme måde blev arbejdet med geografiske data mere konkret. Det førte videre til spørgsmålet om, hvorvidt PostGIS-data bør lagres som geometry eller geography.
Det interessante ved disse problemstillinger er, at de først for alvor bliver forståelige, når de kobles til vores eget system, hvor vi kan evaluere om valgt praksis er bæredygtig og fremtidssikret.
Eftertænksomhed – ikke kun hvad der virker
I uge 39 oplevede jeg, at mine spørgsmål i højere grad bevægede sig fra “kan det lade sig gøre?” til “er det den rigtige løsning?”
Et godt eksempel er datahentning med Entity Framework Core.
I Projection vs. Include i Entity Framework Core undersøgte jeg forskellen mellem at hente komplette entiteter med deres relationer og kun hente præcis de felter, en use case har behov for.
Begge løsninger virker teknisk.
Men hvis kortet i QuestGame kun skal bruge et ID, en position, en type og en status, er det ikke nødvendigvis hensigtsmæssigt at hente hele objektgrafer fra databasen.
Dermed bliver spørgsmålet om dataadgang også et spørgsmål om ansvar og intention: Hvad har den konkrete feature faktisk brug for?
Den samme refleksion opstod omkring billeder.
Et billede kan gemmes som byte[] i C# og som bytea i PostgreSQL. Men i Billeder i databasen – byte[] eller ekstern filestorage? blev spørgsmålet netop, om det faktum, at databasen kan gemme billeder, også betyder, at den bør gøre det.
Det er en vigtig forskel, da det har betydning for systemets hastighed og resourceforbrug.
Mine læringsmål handler ikke kun om at kunne implementere noget. De handler i høj grad om at kunne begrunde, hvorfor jeg vælger én løsning frem for en anden.
Begrebsdannelse – nogle principper begynder at gå igen
Når jeg samler erfaringerne fra uge 38 og 39, begynder nogle overordnede principper at tegne sig.
Det første er, at use casen bør være udgangspunktet for designet.
Det passer godt til vores arbejde med Vertical Slice Architecture, som jeg også har beskrevet i Vertical Slice Architecture vs. Clean Architecture. I stedet for først at bygge en stor generel arkitektur arbejder vi med konkrete use cases og ser, hvilke behov de skaber.
Det andet er, at backend og database ikke kan betragtes isoleret.
En ændring i en C#-entity kan påvirke databaseskemaet. Valget af inheritance mapping påvirker forespørgsler. Projection påvirker den SQL, EF Core genererer. Og spørgsmålet om billeder handler både om datalagring og systemarkitektur.
Det tredje er, at der sjældent findes én løsning, som altid er bedst.
TPH, TPT og TPC har forskellige egenskaber. Projection og Include() løser forskellige problemer. PostgreSQL kan gemme billeder, men object storage kan være mere hensigtsmæssigt i andre situationer.
Opgaven er derfor i højere grad at forstå konsekvenserne og vælge ud fra systemets konkrete behov.
Cirklen starter forfra
Det mest interessante ved Kolbs læringscyklus er for mig, at begrebsdannelsen ikke afslutter processen.
Den skaber nye eksperimenter.
Valget af PostgreSQL førte til PostGIS. PostGIS førte til nye spørgsmål om geografiske datatyper og forespørgsler. Code First førte til spørgsmål om datamodellering og inheritance mapping. EF Core førte videre til Projection og Include. Og datamodellen førte til overvejelser om, hvor forskellige typer data egentlig bør lagres.
Dermed bliver min dokumentation heller ikke kun en samling af teknologier, jeg har arbejdet med.
Den viser forhåbentlig også en udvikling fra at kunne få en løsning til at fungere til i højere grad at kunne undersøge, vurdere og begrunde de valg, der ligger bag den.
Næste skridt bliver at afprøve flere af disse beslutninger gennem komplette features i QuestGame. Her vil det vise sig, om de valg, der på nuværende tidspunkt virker fornuftige, også holder, når en use case føres hele vejen gennem backend og database.
Hvis ikke, vil jeg fortsætte med at afsøge nye muligheder og tage ved lære af dem.