När både webb och app ska visa samma sak måste sanningen flytta bakåt till API-lagret.
Webben blev mer avancerad och mobilappen växte fram. Då blev duplicerad logik direkt irriterande. Jag ville inte att webben skulle ha en egen tolkning av historik och appen en annan.
Jag började därför dela upp funktionerna i små egna tjänster. Relay 7 Now Playing API ansvarar för aktuell låt och ren historik. Relay 7 Community API hanterar interaktion. Relay 7 Request API tar emot låtönskningar och validerar dem. Relay 7 App Status API ger appen information om stationens tillstånd.
Det gör också att en klient kan bytas utan att radiohjärnan ändras. Om jag bygger om webben ska Kontrollcenter inte bry sig. Om appen får en ny vy ska requestreglerna fortfarande ligga på servern.
{
"now": {
"artist": "...",
"title": "...",
"startedAt": "..."
},
"show": {
"name": "...",
"host": "..."
},
"history": [ ... ]
}API-designen fick också felhantering
När mobilen och webben började bero på samma endpoints behövde jag bestämma vad som händer när upstream saknas. Ska history bli tom lista? Ska now vara null? Ska hela API-anropet bli fel?
Jag föredrar strukturerade degraderingar där klienten kan skilja “ingen data just nu” från “servern dog”. Det gör UI:t bättre och felsökningen tydligare.
API:erna fick bli kontrakt i stället för genvägar
Det var lockande att bara returnera exakt det interna objektet från en tjänst. Det är snabbt när man bygger första klienten men dyrt när intern kod senare behöver ändras.
Jag började därför tänka mer på stabila publika former. Now Playing ska inte läcka interna queuefält. Request API ska returnera ett begripligt resultat och inte bara ett lågnivåfel. Appstatus ska kunna versioneras utan att mobilen måste följa varje intern refaktorering.
Det gör att jag kan skriva om Kontrollcenter betydligt friare. Klienterna har ett kontrakt med API:t, inte med implementationen bakom.