Hvordan en API-først tilnærming former fremtiden for 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, der et team begynner med å utforme applikasjonsens funksjonalitet, skriver koden, og legger deretter til APIer på slutten av prosessen.

Hos Zonos betyr det å bygge programvare ved hjelp av en API-først tilnærming å utforme løsninger rundt et API, i stedet for å kode en applikasjon og legge til et API senere. Dette betyr at våre APIer er av største betydning og produkter i seg selv; vi utfører dem med intens fokus på kundens behov, og vi dokumenterer og arkitekterer dem tydelig før vi skriver noen kode.

Fordelene ved en API-først tilnærming 

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

• Vi forstår at våre APIer er det primære grensesnittet for kundene våre, og ser derfor på dem som våre offentlige leveranser.
• Dokumentering før koding gir oss muligheten til å resonnere, diskutere, forbedre og kommunisere våre mål med teamene og interessentene våre for å lage et bedre sluttprodukt.
• Ettersom vi fokuserer på behovene til kundene våre, forstår vi hvordan vi best utfører APIer som møter disse behovene.

Denne mentaliteten setter våre APIer og kunder først og er kritisk for å etablere et grunnlag der alle hos Zonos er ansvarlige for kundesuksess.

Utviklingsteam kan jobbe parallelt

API-først tilnærmingen innebærer å etablere en kontrakt. Å opprette en kontrakt mellom tjenester som følges av team på tvers av en organisasjon, gjør det mulig for disse teamene å jobbe på flere APIer samtidig. Utviklere trenger ikke vente på at API-oppdateringer blir utgitt før de går videre til neste API. Team kan samtidig ettermåle APIer og API-avhengigheter basert på forhåndsestablerte API-definisjoner.

Reduserer utviklingskostnadene

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

Øker hastigheten til marked

Mye av prosessen med å bygge APIer kan automatiseres ved hjelp av verktøy for å importere API-definisjonsfiler. Vi begynner med å generere kjernetype, definisjoner og skjemaer; med disse filene kan API-verktøy som API-dokumentasjon, software development kits (SDKs) og mock APIer bli auto-generert. Automatisering fremskynder utviklingen av APIer og applikasjoner betydelig.

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

Sikrer god utviklererfaring

API-forbrukere er oftest utviklere, og utviklererfaring (DX) kan gjøre eller bryte suksessen til et API. API-først tilnærmingen sikrer at utviklererfaring er positiv fordi et velutformet, velpdokumentert, konsekvent API er lettere å lære og gjenbruke. Dette øker også implementeringshastigheten. Alle disse fordelene er sammenkoblet!

Ø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. Som Eddison med 1000 mislykkede forsøk før han laget lyspæren, betyr API-først at vi mislykkes raskt og går videre med bedre forståelse av hvordan man oppnår suksess. API-først øker vår langsiktige suksess ved å sikre at APIer er pålitelige, konsistente og enkle for utviklere å bruke.

Hvorfor er det effektivt å jobbe bakover? 

I 2015 hadde jeg muligheten til å redesigne e-handelsnettsiden til en populær forbrukermerke. Jeg evaluerte ulike nøkkelprestasjonsindikatorer (KPIer) relatert til det eksisterende systemet, og det var klart hvor de største forbedringene kunne gjøres:

• Konverteringsgraden for stasjonær var under gjennomsnitt.
• Konverteringsgraden for mobiltelefon var forferdelig.
• Prosentandelen av mobil trafikk økte raskt og ville overgå 50% av total trafikk innen de neste 12 månedene. På grunn av den forferdelige mobilkonverteringsgraden var det ikke ideelt at det meste av trafikken var mobil.

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 av designene, arkitekturen, APIene, osv. først vurderte mobilopplevelsen. Dette var bakover fra den tradisjonelle tilnærmingen på den tiden, som fokuserte først på stasjonæropplevelsen, og etterlot ofte mobilopplevelsen som en klønete påfestet etterpatning med dårlige konverteringsgrader. 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 APIer måtte skrives, og flere design var nødvendig for hvert bruddpunkt.

Mobil-først tilnærmingen resulterte i en betydelig økning i mobil konverteringsgrad. Den nye arkitekturen ga også imponerende gevinster i stasjonær konverteringsgrad. Tilnærmingen var vellykket fordi den identifiserte hvordan man skaper maksimal brukverdi og fokuserte hele tilnærmingen på å gi den verdien. Det opprettet den riktige mentaliteten fra begynnelsen av. På samme måte – selv om det kan føles som om man jobber bakover – skaper en API-først tilnærming muligheter til å identifisere overordnede problemer og deretter bygge et grunnlag for å korrigere disse problemene.

Hva er ingeniøransvaret? 

API-først mentaliteten har og vil fortsette å føre Zonos til suksess, og ingeniøring spiller en integrert rolle. Det er vårt ansvar å alltid opprettholde API-først mentaliteten. Dette betyr at vi konstant stiller spørsmål som holder fokus på våre APIer, for eksempel: "Hvordan kan våre APIer møte kundens behov?" Det betyr også at vi alltid reagerer på spørsmål om funksjoner og funksjonalitet med en lenke til vår API-dokumentasjonen. Hvis dokumentasjonen ikke finnes, lager vi den – og arbeider sammen på tverrfaglige team for å sikre at Zonos har utmerket API-dokumentasjon.