Anex - tekniske valg

Arkitektur er et ladet begreb, som ofte kan dele vandene – ikke kun for IT-systemer som Anex. Men lad os parkere midt på øretævernes holdeplads og få luftet alle beslutningerne:

Arkitekturen for Anex

Arkitektur i Anex, vist som en række gule rektangler for de tre public services: App, Web og Api. Derudover er der fire blå datakilder – en PostGres DB, et ElasticSearch cluster, en MongoDB og endelig en RabbitMQ. Til sidst er der vist tre interne lilla services: Indexing, Calculation og Subscription. Det er vist med pile, hvordan data flyder mellem de enkelte elementer. En grøn med pil i hver ende angiver at data bliver begge veje, mens en rød pil i en enkelt ende viser den modtagende part i en envejs kommunikation.

Argumenterne bag

Jeg har valgt en monolit med services og så (alt for) mange datakilder. Jeg ved godt, at monolitter er meget udskældte, men der er i min bog rigtig mange gode argumenter for en monolit i en applikation som Anex:

  • Simplicitet – stort set alle kald er direkte proces-kald. Det er ’nemt’ at pakke alt ind i transaktioner
  • Enkelt at deploye
  • Tunge kald – indeksering, kalkulationer osv. kan stadig køre asynkront

De mange datakilder

Jeg skal gerne medgive, at PostGres sagtens ville kunne håndtere MongoDB’ens opgave her – og det kan sagtens tænkes at jeg i en senere version flytter audit trail derind. Tanken er at der altid kun er én kilde til sandhed for en given klump data. ElasticSearch er en sekundær datakilde og kan til hver en tid gendannes ud fra de andre kilder.

Hver datakilde har en primær styrke, som gør den ideel til en given opgave. PostGres er klippestabil, har fuld ACID og understøtter adhoc queries til rapporter og den slags. MongoDB understøtter arbitrære data og er rigtig god til audit trail, hvor jeg lagrer snapshots af data før og efter en rettelse – det -kan- PostGres også, men det er noget jeg lige skal have læst op på, for at finde en god model. ElasticSearch er virkelig god til fritekstsøgning inkl. søgning i filer (via Tiki.Net). Derudover har de alle åben kildekode, hvilket var et absolut krav.

Sprog og frameworks

Alt pånær Anex.Web er skrevet i .NET C# – jeg er 100p klar over at det ikke er et åbenlyst valg, når vi nu kører open source, men det er nu engang det sprog, jeg er bedst til. Til Anex.Web har jeg valgt Svelte, som det mindst dårlige valg i et hav af dårlige valg. De vigtigste frameworks i backend koden er NHibernate, RebusFM, FluentMigrate – og så Avalonia til Xena.App.

Det er ikke de mest kendte frameworks, men til gengæld dem, jeg har haft bedst erfaringer med til det jeg skal bruge. De udmærker sig ved at være ‘gamle’ (læs: battle-hardened) og forholdsvis simple set op mod funktionalitet.