Datalager-API
- Per Persson
Status | decided |
|---|---|
Impact | Medium |
Driver | @Jakob Melander |
Approver | @Per Persson |
Contributors | @Adam Hedesand Stålhult (Unlicensed) @Ronny Lundberg (Unlicensed) |
Informed | |
Due date | Mar 4, 2022 |
Resources | |
Outcome | API-teamet bygger APIerna och går mot vyer i Datalagret |
Bakgrund
Vi behöver besluta om hur vi exponerar APIer för Datalagret.
Alternativ
Alternativ 1 - datalagret bygger och förvaltar sitt eget API
Datalagrets APIer byggs och förvaltas (inklusive livscykelhanteras i API Manager) 100% inom Datalager-objektet.
Alternativ 2 (a och b) - API-teamen bygger och förvaltar Datalagrets API
Datalagret ansvarar för datat och databasen.
API-teamen ansvarar för Datalagrets APIer och dess livscykelhanteras.
Alternativ a och b representerar två olika sätt att integrera våra mikrotjänster med Datalagrets databas:
Alternativ a: Datalagret bygger specifika vyer i databasen för det data som skall hämtas från en mikrotjänst i samtliga fall.
Alternativ b: Mikrotjänsterna går direkt mot tabeller och kolumner i Datalagrets databas om inte en vy krävs av prestandaskäl.
| Alternativ 1 | Alternativ 2a | Alternativ 2b |
|---|---|---|---|
Pros and cons | Korrekt funktionsallokering Inga beroenden mellan olika team Frågan om utökat driftansvar för BODIL-maskinen måste redan ut Resursbrist i hos Datalagret (är väl bara Joel som är aktuell för utvecklingen just nu) | Resursfrågan mindre akut Funktionsallokering/ Dubbel utveckling för varje ny datamängd (skapa vy i Datalagret samt logik i mikrotjänst) | Resursfrågan minst akut Funktionsallokering/ |
Utvärdering | Data samt dess API hanteras inom samma objektförvaltning, vilket talar för detta alternativ | Att alltid behöva utveckla på två ställen när en ny datamängd skall exponeras är det dyraste alternativet. Ansvarsdelningen är inte optimal | Kompetens- och resursmässigt är detta den bästa lösningen - dock är ansvarsdelningen inte optimal |
Action items
Outcome
Alternativ 2a
Motivering:
Saknas kompetens inom Datalagret för API-utveckling i dag, och det är i dagsläget inte ekonomiskt rimligt att ta in nya resurser bara för detta
Alternativ 2b går bort ur säkerhetssynpunkt
Att diskutera vidare:
Livscykelhantering samt incidenthantering för dessa APIer måste redas ut då det blir ett delat ägande av funktionen som helhet.