Uge 37: Læringsmål

IT-sikkerhed

Fokus på backend-udvikling og API-design og modellering af projekt.

Videre plan

Se uge 38

---

Backend-udvikling og API-design

• System arkitektur: Microservice vs Monolithic architecture

• Kant-arkitektur: API Gateway vs BFF

• Indre arkitektur / struktur: Hexagonal arkitektur

Mål

Jeg vil gerne opnå en dybere forståelse for microservices og hvordan de bygges på en hensigtsmæssig måde, hvordan services kaldes i en sådan arkitektur, samt hvordan vi kan strukturere vores services.

Result

Uge 37: Arkitekturvalg (link)

Proces

• Se kort video om Microservice vs Monolithic architecture  (link)

• Læse artiker om ovenstående

• Søge online for læringsmaterialer om API Gateway og Backend For Frontend (BFF)

• Søge online for læringsmaterialer om Hexagonal arkitektur

Refleksion

Vi har valgt microservices, selvom det øger kompleksiteten. Det matcher Trackunits strategi og giver mig erfaring med moderne principper.

GraphQL er ikke nødvendigt for projektet, men en god læringsmulighed. Et smalt schema balancerer læring og behov.

Hexagonal arkitektur tydeliggør separation of concerns og gør test og udskiftning af teknologier enklere, især i Ingestion Service med storage, database og events.

Kant-arkitektur ift API-design

Jeg overvejede om Ingestion Service skulle tilbyde både REST og GraphQL (BFF).

Men da en teammate ser på API-gateway, ville det være overkill. Jeg har derfor valgt GraphQL som primær kontrakt - primært for læring.

REST (kendt for mig)

• POST /uploads/request-url - mobilappen beder om en pre-signed URL til upload

• POST /uploads/{id}/confirm  - mobilappen bekræfter, at filen er lagt i storage

• POST /uploads/{id}/finalize-processing  - Result Service melder billede færdigbehandlet

• (evt) GET /uploads/{id}  - status kan hentes, hvis der er behov for det

GraphQL  (nyt for mig)

mutations

• mutation requestUploadUrl(mimeType, size) { uploadId, url, expiresAt }

• mutation confirmUpload(id) { id, status }

• mutation finalizeProcessing(id) { id, status }

query

• query upload(id) { id, status }

Intern kommunikation

Jeg vil også gerne lære om message brokers for asynkron kommunikation, og Trackunit benytter selv Kafka, derfor har vi valgt at inkorporere det i projektet.

Kafka  

Events publiceres af Ingestion Service, så andre services kan reagere asynkront (nyt for mig)

• uploads.completed  (efter confirm) - AI-service reagerer

• uploads.finalized  (efter finalizeProcessing)  - markerer at hele kæden er afsluttet

• Payload:

  • mindst uploadId

  • evt. checksum, størrelse, tidspunkt

Hexagonal arkitektur i projektet

Jeg forstår bedre hvordan hexagonal arkitektur understøtter separation of concerns, encapsulation og SOLID. Det giver et bedre billede af, hvordan testbarhed og fleksibilitet kan opnås

(f.eks ved at udskifte eksterne systemer uden at ændre domænelogikken).

Struktur i Ingestion Service

Driving side (input)

GraphQL schema  → Resolver (adapter)  → Port (interface)   → App Service

App Service  → output-porte

Driven side  (output)

• StoragePort (interface) → StorageAdapter (S3 eller andet)

• RepoPort (interface) → RepoAdapter (DB)

• EventPort (interface) → EventAdapter (Kafka)

Elementer

Resolver: tynd oversætter, ingen forretningslogik

Driving port: kontrakt ind til domænet (én use case = én metode)

Application Service: implementerer driving port og orkestrerer use case

Driven ports: kontrakter ud af domænet (storage, DB, events)

Adapters: konkrete teknologier bag driven ports

Konklusion

I uge 37 har jeg arbejdet med at forstå arkitekturvalg på system-, kant- og indre niveau og udarbejdet et High Level Design (HLD) for Ingestion Service. Det giver mig et solidt udgangspunkt til at gå videre med Low Level Design i næste uge

Videre plan

Udarbejde

• LLD

Læse om

• storage - dokumentation for pre-signed URLs

• mere (i dybden) om GraphQL

• mere (i dybden) om Message brokers og events

---

Projekt

Mål

• Første iteration: high level design (HLD) af Ingestion Service

  • Usecases

  • System Sequence Diagram (SSD)

  • Operation Contract (OC)

  • Domain model

  • Sequence diagram (SD) - HLD system niveau

Proces

• HLD: modeller ud fra Usecases

  
  

Result

Uge 37: HLD (link)

Refleksion

HLD giver et godt overblik og skaber sammenhæng til de videre detaljer i LLD. Jeg skal huske at inddrage tidligere arbejde med IT-sikkerhed i dette næste trin.

Videre plan

Design

• Videre modellering (LLD)

Dykke ned i ressourcer om

• API-sikkerhed

• dokumentation for pre-signed URLs

• Begynde at lære om GraphQL

• Begynde at lære om Message brokers og events

• Læse om arkitekturprincipper som microservices vs. monolit og hexagonal arkitektur