Datalager-API

Status	IN PROGRESS
Impact	MEDIUM
Driver	Jakob Melander
Approver	Per Persson
Contributors	Adam Hedesand Stålhult (Unlicensed) Ronny Lundberg (Unlicensed)
Informed
Due date	04 Mar 2022
Resources

\uD83D\uDCD8 Bakgrund

Vi behöver besluta om hur vi exponerar APIer för Datalagret.

Datalagrets APIer byggs och förvaltas (inklusive livscykelhanteras i API Manager) 100% inom Datalager-objektet.

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.
Alternativ b: Mikrotjänsterna går direkt mot tabeller och kolumner i Datalagrets databas.

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/
ansvarsfördelning alls inte optimal

Dubbel utveckling för varje ny datamängd (skapa vy i Datalagret samt logik i mikrotjänst)

Resursfrågan minst akut

Funktionsallokering/
ansvarsfördelning alls inte optimal

Utvärdering

Data samt dess API hanteras inom samma objektförvaltning, vilket talar för detta alternativ

Detta alternativ går bort - att behöva utveckla på två ställen när en ny datamängd skall exponeras är det sämsta alternativet

Kompetens- och resursmässigt är detta den bästa lösningen - dock är ansvarsdelningen inte optimal och vi riskerar “blame-games”