Hvordan en API-first-tilgang former fremtiden for Zonos

Hvad er en API-first-tilgang? 

API-first-tilgangen står i skarp kontrast til code-first-tilgangen, hvor et team begynder med at designe applikationens funktionalitet, skrive koden og derefter tilføje API'er i slutningen af processen.

Hos Zonos betyder at bygge software med en API-first-tilgang at designe løsninger omkring et API frem for at kode en applikation og tilføje et API senere. Det betyder, at vores API'er er altafgørende og produkter i sig selv; vi designer dem med intens fokus på kundens behov, og vi dokumenterer og arkitekterer dem tydeligt, før vi skriver kode.

Fordele ved en API-first-tilgang 

API-first-tilgangen hjælper med at etablere følgende tankegang:

• Vi forstår, at vores API'er er den primære grænseflade for vores kunder, og ser derfor på dem som vores offentlige leverancer.
• Dokumentation før kodeskrivning giver os mulighed for at ræsonnere, diskutere, forfine og kommunikere vores mål med vores teams og interessenter for at skabe et bedre slutprodukt.
• Når vi fokuserer på vores kunders behov, forstår vi, hvordan vi bedst designer API'er, der opfylder disse behov.

Denne tankegang sætter vores API'er og kunder først og er afgørende for at etablere et fundament, hvor alle hos Zonos er ansvarlige for kundesucces.

Udviklingsteams kan arbejde parallelt

API-first-tilgangen involverer etablering af en kontrakt. Oprettelse af en kontrakt mellem tjenester, som teams på tværs af en organisation følger, giver disse teams mulighed for at arbejde på flere API'er samtidigt. Udviklere behøver ikke vente på, at API-opdateringer frigives, før de går videre til det næste API. Teams kan samtidigt mocketeste API'er og API-afhængigheder baseret på forud etablerede API-definitioner.

Reducerer udviklingsomkostningerne

API'er og kode kan genbruges i mange forskellige projekter. Under API-first-tilgangen, hvis et udviklingsteam vil bygge en ny applikation, behøver de ikke starte forfra, hvilket sparer tid og penge. API-first-design giver også mulighed for at løse de fleste problemer, før der overhovedet skrives kode, hvilket hjælper med at forhindre problemer, når det er tid til at integrere API'er med applikationer.

Øger hastigheden til markedet

Meget af processen med at bygge API'er kan automatiseres ved hjælp af værktøjer til at importere API-definitionsfiler. Vi starter med at generere kerntyper, definitioner og skemaer; med disse filer kan API-værktøjer som API-dokumentation, software development kits (SDK'er) og mock API'er auto-genereres. Automatisering fremskynder udviklingen af API'er og applikationer betydeligt.

API-first gør det også muligt at tilføje nye tjenester og teknologier til applikationer uden at skulle re-arkitektere hele systemet. Zonos skal sende funktioner til produktion hurtigt for at forblive konkurrencedygtige på det stadigt skiftende cross-border SaaS-marked. Det er nemmere at eliminere teknisk gæld i den underliggende kode end at migrere kunder væk fra et dårligt designet API.

Sikrer gode udvikleroplevelser

API-forbrugere er oftest udviklere, og developer experience (DX) kan afgøre succesen for et API. API-first-tilgangen sikrer, at udvikleroplevelsen er positiv, fordi et veldesignet, veldokumenteret, konsistent API er nemmere at lære og genbruge. Det øger også implementeringshastigheden. Disse fordele er alle sammenkoblede!

Øger langsigtet succes

En API-first-tilgang giver mulighed for hurtig prototyping og iteration, hvilket betyder, at vi hurtigere lærer, hvad der virker, og hvad der ikke gør. Ligesom Edisons 1.000 mislykkede forsøg, før han skabte lyspæren, betyder API-first, at vi fejler hurtigt og går videre med en bedre forståelse af, hvordan vi opnår succes. API-first øger vores langsigtede succes ved at sikre, at API'er er pålidelige, konsistente og nemme for udviklere at bruge.

Hvorfor er det effektivt at arbejde baglæns? 

I 2015 havde jeg mulighed for at redesigne e-handelssitet for et populært forbrugermærke. Jeg evaluerede forskellige key performance indicators (KPI'er) relateret til det eksisterende system, og det var tydeligt, hvor de største forbedringer kunne gøres:

• Desktop-konverteringsraten var under standard.
• Mobil-konverteringsraten var elendig.
• Andelen af mobiltrafik steg hurtigt og ville overstige 50% af den samlede trafik inden for de næste 12 måneder. På grund af den elendige mobil-konverteringsrate var det ikke ideelt, at det meste af trafikken var mobil.

Givet dataene, hvad ville skabe mest værdi for brugerne? Det var indlysende: at rette problemerne med sitets mobile brugeroplevelse. Derfor tog jeg en mobile-first-tilgang til at redesigne sitet. Det betød, at alle designs, arkitektur, API'er osv. først overvejede den mobile oplevelse. Det var baglæns i forhold til den traditionelle tilgang på det tidspunkt, som først fokuserede på desktop-oplevelsen og ofte efterlod den mobile oplevelse som en klodset påboltet eftertanke med dårlige konverteringsrater. Mobile-first-tilgangen krævede også mere indsats på forhånd - det var ikke den nemme vej. En ny arkitektur var nødvendig, nye API'er skulle skrives, og flere designs var nødvendige for hvert breakpoint.

Mobile-first-tilgangen resulterede i en betydelig stigning i mobil-konverteringsraten. Den nye arkitektur gav også imponerende gevinster i desktop-konverteringsraten. Tilgangen var succesfuld, fordi den identificerede, hvordan man skaber maksimal brugerværdi, og fokuserede hele tilgangen på at levere den værdi. Den skabte den rette tankegang fra starten. Ligeledes - selvom det kan føles som at arbejde baglæns - skaber en API-first-tilgang muligheder for at identificere overordnede problemer og derefter bygge et fundament for at rette disse problemer.

Hvad er engineering-ansvaret? 

API-first-tankegangen har og vil fortsat føre Zonos til succes, og engineering spiller en integreret rolle. Det er vores ansvar altid at opretholde API-first-tankegangen. Det betyder, at vi konstant stiller spørgsmål, der holder fokus på vores API'er, såsom: „Hvordan kan vores API'er opfylde kundens behov" Det betyder også, at vi altid svarer på spørgsmål om funktioner og funktionalitet med et link til vores API-dokumentation. Hvis dokumentationen ikke eksisterer, opretter vi den - arbejder sammen på tværfunktionelle teams for at sikre, at Zonos har fremragende API-dokumentation.