Hvordan en API-først tilnærming former fremtiden til Zonos

Hva er en API-først tilnærming? 

API-først tilnærmingen står i sterk kontrast til kode-først tilnærmingen, hvor et team begynner med å designe applikasjonens funksjonalitet, skrive koden, og deretter legge til API-er på slutten av prosessen.

Hos Zonos betyr det å bygge programvare ved hjelp av en API-først tilnærming å designe løsninger rundt et API, i stedet for å kode en applikasjon og legge til et API senere. Dette betyr at våre API-er er avgjørende og produkter i seg selv; vi designer dem med et intenst fokus på kundens behov, og vi dokumenterer og arkitekter dem tydelig før vi skriver noen kode.

Fordelene med en API-først tilnærming 

API-først tilnærmingen hjelper til med å etablere følgende tankesett:

• Vi forstår at våre API-er er det primære grensesnittet for våre kunder, og ser derfor på dem som våre offentlige leveranser.
• Dokumentasjon før koding gir oss muligheten til å resonnere, diskutere, raffinere og kommunisere våre mål med våre team og interessenter for å skape et bedre sluttprodukt.
• Når vi fokuserer på behovene til våre kunder, forstår vi hvordan vi best kan designe API-er som møter disse behovene.

Dette tankesettet plasserer våre API-er og kunder først og er kritisk for å etablere et fundament hvor alle hos Zonos er ansvarlige for kundesuksess.

Utviklingsteam kan jobbe parallelt

API-først tilnærmingen innebærer å etablere en kontrakt. Å lage en kontrakt mellom tjenester som følges av team på tvers av en organisasjon, lar disse teamene jobbe med flere API-er samtidig. Utviklere trenger ikke å vente på at API-oppdateringer skal slippes før de går videre til neste API. Team kan samtidig mock-teste API-er og API-avhengigheter basert på forhåndsdefinerte API-definisjoner.

Reduserer kostnadene ved utvikling

API-er og kode kan gjenbrukes på mange forskjellige prosjekter. Under API-først tilnærmingen, hvis et utviklingsteam ønsker å bygge en ny applikasjon, trenger de ikke å starte fra bunnen av, noe som sparer tid og penger. API-først design tillater også at de fleste problemer kan løses før noen kode er skrevet, noe som bidrar til å forhindre problemer når det er tid for å integrere API-er med applikasjoner.

Øker hastigheten til markedet

Mye av prosessen med å bygge API-er kan automatiseres ved hjelp av verktøy for å importere API-definisjonsfiler. Vi begynner med å generere de grunnleggende typene, definisjonene og skjemaene; med disse filene kan API-verktøy som API-dokumentasjon, programvareutviklingssett (SDK-er) og mock-API-er genereres automatisk. Automatisering øker betydelig hastigheten på utviklingen av API-er og applikasjoner.

API-først gjør det også mulig å legge til nye tjenester og teknologier til applikasjoner uten å måtte omstrukturere hele systemet. Zonos må levere funksjoner til produksjon raskt for å forbli konkurransedyktig i det stadig skiftende grenseoverskridende SaaS-markedet. Det er lettere å eliminere teknisk gjeld i den underliggende koden enn å migrere kunder bort fra en dårlig designet API.

Sikrer gode utvikleropplevelser

API-forbrukere er oftest utviklere, og utvikleropplevelse (DX) kan avgjøre suksessen til en API. API-først tilnærmingen sikrer at utvikleropplevelsen er positiv fordi en godt designet, godt dokumentert, konsistent API er lettere å lære og gjenbruke. Dette øker også hastigheten på implementeringen. Disse fordelene er alle sammenkoblede!

Øker langsiktig suksess

En API-først tilnærming tillater rask prototyping og iterasjon, noe som betyr at vi lærer raskere hva som fungerer og hva som ikke gjør det. Som Eddisons 1.000 mislykkede forsøk før han skapte lyspæren, betyr API-først at vi feiler raskt og går videre med en bedre forståelse av hvordan vi oppnår suksess. API-først øker vår langsiktige suksess ved å sikre at API-er er pålitelige, konsistente og enkle for utviklere å bruke.

Hvorfor er det effektivt å jobbe bakover? 

I 2015 fikk jeg muligheten til å redesigne e-handelsnettstedet til et populært forbrukermerke. Jeg evaluerte ulike nøkkelindikatorer (KPI-er) relatert til det eksisterende systemet, og det var clear hvor de største forbedringene kunne gjøres:

• Konverterings rate for desktop var under standard.
• Konverterings rate for mobil var elendig.
• Prosentandelen av mobiltrafikk økte raskt og ville overgå 50% av total trafikk innen de neste 12 månedene. På grunn av den elendige mobilkonverterings rate var mesteparten av trafikken som var mobil, ikke ideell.

Gitt dataene, hva ville skape mest verdi for brukerne? Det var åpenbart: å fikse problemene med nettstedets mobilbrukeropplevelse. Derfor tok jeg en mobil-først tilnærming for å redesigne nettstedet. Dette betydde at alle designene, arkitekturen, API-ene osv. først vurderte mobilopplevelsen. Dette var bakover fra den tradisjonelle tilnærmingen på den tiden, som først fokuserte på desktopopplevelsen, og ofte etterlot mobilopplevelsen som en klønete påklistret ettertanke med dårlige konverteringsrater. Mobil-først tilnærmingen krevde også mer innsats på forhånd—det var ikke den enkle veien. En ny arkitektur var nødvendig, nye API-er måtte skrives, og flere design var nødvendige for hver breakpoint.

Mobil-først tilnærmingen resulterte i en betydelig økning i mobilkonverterings rate. Den nye arkitekturen ga også imponerende gevinster i desktopkonverterings rate. Tilnærmingen var vellykket fordi den identifiserte hvordan man kunne skape maksimal brukerverdi og fokuserte hele tilnærmingen på å gi den verdien. Det skapte det riktige tankesettet fra starten av. På samme måte—selv om det kan føles som å jobbe bakover—skaper en API-først tilnærming muligheter til å identifisere overordnede problemer og deretter bygge et fundament for å korrigere disse problemene.

Hva er ingeniøransvaret? 

API-første tankesett har og vil fortsette å lede Zonos til suksess, og ingeniørarbeid spiller en integrert rolle. Det er vårt ansvar å alltid opprettholde API-første tankesett. Dette betyr at vi konstant stiller spørsmål som holder fokuset på våre API-er, som: “Hvordan kan våre API-er møte kundens behov” Det betyr også at vi alltid svarer på spørsmål om funksjoner og funksjonalitet med en lenke til vår API-dokumentasjon. Hvis dokumentasjonen ikke eksisterer, så lager vi den—arbeider sammen i tverrfaglige team for å sikre at Zonos har strålende API-dokumentasjon.