Category

Udvikling

API

Skriv kode som du bygger LEGO – Vigtigheden af faste API ‘er

By Udvikling

Har du udfordringer med API?

Håndterer du store kodebaser?

Er du fanget i det trælse legacy system, du bare ikke kan komme ud af?

Har du lyst til at prøve den helt nye og fede databaseteknologi, der hjælper med lige præcis dét problem, du står med?

API – et univers af udfordringer

Vi bliver ved med at løbe ind i de samme problemer, og det sker meget oftere, end vi kan håndtere. Vi hører hele tiden om, hvordan det næste framework kommer til at redde os fra den afgrund af fortvivlelse, som vi befinder os i, på grund af krav der altid ændrer sig. Men vi ender altid med at finde os selv tilbage ved det samme udgangspunkt igen – bare et par måneder senere.

Selvom et helt nyt og forkromet framework eller en ny fremgangsmåde (som eksempelvis funktionel programmering) hjælper dig et stykke af vejen, så kan du ikke forvente, at det kan klare alle dine problemer. Det ville kræve alt for mange meninger som skal stemme overens, og det ville kræve et overhead der slet ikke er til at forstille sig.

Frameworks er ikke et værktøj til organisering

Det fik mig til at tænke på en præsentation af Rich Harris (Rethinking reactivity Tag et kig!). Hvor hans kommentar virkelig ramte plet. Han siger nemlig ”Frameworks er ikke et værktøj til at organisere din kode, det er et værktøj til at organisere dit sind”. Jeg tog derefter et kig på, hvordan vi angriber kode på en måde, hvor vi kan sikre, at sandslottet stadig står stærkt efter 10 år.

Jeg indså, at det faktisk er ret simpelt: Et solidt og gennemtænkt API vil nok komme til at leve længere end dig.

 

API : Hvad skal du gøre?

  • Start med at udpensle en grov idé om, hvordan dit API skal virke baseret på den ændring, du er ved at lave.
  • Tag nu et kritisk blik på, hvad du egentlig har brug for lige nu og skær resten fra!
  • Du kan nu begynde at arbejde med dit API i konteksten af dit eksisterende system.

Nu er vi klar til faktisk at få lavet noget af arbejdet. Implementer hvad din ændring faktisk skal gøre. Du behøver ikke at gøre meget, selvom jeg ved, at du prøver at tænke 10 år ind i fremtiden. Det kommer ikke til at hjælpe dig lige nu.

Jeg vil garantere, at mens du laver den faktiske ændring, kommer du til at lære mere om, hvad du har brug for. Godt – vi skal bruge denne viden til at kunne omskrive vores API, så det bliver helt perfekt. Lige nu – er faktisk det helt rette tidspunkt at gøre det.

Hvad skal du så gøre nu? – du skal gøre det ovenstående igen og igen og igen, indtil din ændring er færdig.

Hvilke fordele giver det?

Isolation

Du har lige skrevet en kontrakt der definerer præcis, hvordan din nye ændring kommer til at passe ind i din eksisterende kode. Du kan tænke på det som en Legoklods. Den er formet på en helt bestemt måde. En form der aldrig ændrer sig og som altid vil passe sammen med andre klodser på en helt bestemt måde.

Isoleringen er vigtig, fordi den flytter fokus hen på, det der er rigtigt vigtigt. Nemlig grænsefladerne og hvordan tingene spiller sammen, og den ignorerer selve implementeringen.

 

Fleksibilitet

Ved at isolere dine ændringer til kontrakter, har du nu lavet ”byggeklodser”, som du kan bruge efter behov. Lad os tage et eksempel:

Du har lige lavet en ny ændring, der står for medlemsabonnementer. Din vildt fede nye ændring gemmer tingene i databasen (implementering), men det kan kun gøres ved at kalde funktionen ”subscribeMember” (API).

Din chef har lige lavet en aftale med en anden virksomhed. Det er nu dem, der skal styre alle medlemmer. Han beder dig nu om at sende medlemsdata til deres HTTP endpoint.

Fordi du har lavet en solid kontrakt med dit API der siger, at det kun kan ske ved at bruge funktionen ”subscribeMember”, kan du nu slette hele din eksisterende implementering helt bekymringsfrit og omskrive det uden at frygte hvor meget legacy kode, som du skal gennemteste igen.

 

Test af API

Denne del er virkelig vigtig. Når du bruger denne fremgangsmåde giver det mulighed for, at du kan teste dit API og IKKE din implementering. Du kan nu skrive tests til alle dine API kontrakter. Efter en laaang aften med 7 kopper kaffe, fordi der har været mange problemer med den nye virksomheds endpoint, kan du nu endelig vinde slaget. Alle tests er grønne! Du kan være helt rolig og sikker på, at resten af dit system arbejder pænt sammen med din nye ændring.

Jeg synes allerede dette indlæg begynder at blive langt, så jeg gemmer lige en længere “rant” omkring tests til en anden gang.

Og ja, jeg ved det godt!…

…Jeg har lige sagt, at der ikke er nogen “one size fits all” der bare klarer alt… Og det er der desværre stadig ikke. Dette vil ikke løse alle dine problemer, men det vil hjælpe dig til at ændre din tankegang. Det vil gøre dig langt mindre afhængig af de værktøjer, der gør det for dig i dag.

Det bedste er, at dette kan bruges uanset, hvilket tech du arbejder med, om det er et gammelt legacy system, en helt ny microservice, et Vue eller React komponent, eller bare en funktion eller klasse. Det kan bruges overalt!

Er du enig? Er det helt skørt det jeg siger? Lad os tage en snak om det!

Tak, fordi du gerne vil skrive bedre kode i dag, end du gjorde i går.

Valeco

Skal vi hjælpe dig med din udvikling og integration? 

Søren Frisk, CTO
+ 45 69 16 91 20 | +45 4124 6988
kontakt@valeco.dk

Her finder du os

Den Hvide Facet 1,
7100 Vejle
T: 691 691 20
E: kontakt@valeco.dk