MuleSoft lade den här veckan till en DataGraph-funktion till sin Anypoint-plattform för att integrera applikationer som använder frågespråket GraphQL för att omedelbart upptäcka, komma åt och servera data från flera befintliga API:er med en enda fråga utan att skriva någon ytterligare kod.
Samtidigt har MuleSoft lagt till ytterligare kopplingar Automation Anywhere, Google Sheets, JIRA, Netsuite och Stripe, tillsammans med en instans av MuleSoft Accelerators för anslutning till SAP-applikationer med kopplingar och bästa praxis definierade av MuleSoft.
Bland de bästa metoderna för API-utvecklare inkluderar:
- Skapa förväntningar: Håll dina kommunikationslinjer öppna och tydliga. Berätta för utvecklare vad du förväntar dig av dem och projektet, ange tydliga deadlines och ta itu med eventuella problem som API-funktionaliteten borde lösa.
- Tjänstemeddelanden: Alla API:er och och tjänster bör vara i linje med affärsmål och leda tjänster som syftar till att leverera värde för nya och befintliga produkter och tjänster.
- Fallstudier: Använd fallstudier för att tillhandahålla bevis och illustrera de förbättringar som API-antagandet kommer att ge projektet.
- Dokumentation: Se till att dokumentationsverktyg finns på plats så att utvecklarteamet korrekt kan dokumentera sina framsteg när det gäller att anta API:et.
- SDK:er och bibliotek: Tillhandahåll resurser som återanvändbar kod och processer (inklusive SDK:er och bibliotek) för att påskynda utveckling och implementering.
Slutligen gör MuleSoft nu sin Anypoint Runtime Fabric tillgänglig för första gången på Kubernetes-plattformar som Azure Kubernetes Service, Amazon Elastic Kubernetes Service och Google Kubernetes Engine. Anypoint Runtime Fabric gör det möjligt att konsekvent distribuera Anypoint-plattformen inkapslad i en container.
Anypoint DataGraph använder samma centrala GraphQL-funktioner som MuleSoft tidigare bäddade in i SaaS-applikationerna (Software-as-a-service) som tillhandahålls av moderbolaget Salesforce. Nu görs dessa funktioner tillgängliga mer allmänt för andra applikationer via en uppsättning lågkodsverktyg i Anypoint-plattformen som gör det möjligt för utvecklare att använda GraphQL mer brett som ett alternativ till REST API:er, säger Shaun Clowes, senior vice president för produkthantering på MuleSoft.
Det tillvägagångssättet gör det enklare för utvecklare att integrera sina applikationer med andra datakällor oavsett om applikationen de skapar är byggd med procedurkod eller en lågkodsplattform. Även när utvecklare föredrar att skriva sin applikation med procedurkod, är det fortfarande vettigt att använda ett lågkodsverktyg för att skapa integration snabbare, konstaterar Clowes.
Utvecklare idag måste kunna flexibelt konsumera data via flera API:er när digitala affärstransformationsinitiativ fortsätter att expandera och utvecklas, tillägger Clowes. I själva verket måste utvecklare snabbt komponera applikationer för att göra det möjligt för deras organisationer att på ett skickligt sätt svara på snabbt föränderliga affärskrav, säger Clowes.
De typer av utvecklare som använder lågkodsintegrationsverktyg börjar också expandera. Så kallade medborgarutvecklare börjar bygga applikationer som behöver konsumera data via API:er. De sofistikerade programmen varierar naturligtvis beroende på kompetensen hos dessa utvecklare.
"Utmaningen med medborgarutvecklare är hur medborgare de är", säger Clowes.
Oavsett vem som bygger applikationerna blir det mycket lättare för utvecklare med varierande expertis att återanvända API:er. Professionella utvecklare, till exempel, kan skapa ett bibliotek med granskade API:er som kan återanvändas av andra utvecklare. Det som krävs är ett centraliserat tillvägagångssätt för att bygga och distribuera API:er som tillhandahåller ett välbehövligt ramverk för styrning eftersom ansvaret för att både bygga och underhålla API:er flyttas ytterligare åt vänster mot utvecklare, noterar Clowes. Det är avgörande inte bara ur ett efterlevnadsperspektiv utan också för att det inte är ovanligt att utvecklare arbetar med ett separat projekt för att skapa redundanta API:er.
Framöver är det tydligt att API:er är i centrum för applikationsutvecklingen när den fortsätter att utvecklas. Nästa generations mikrotjänstbaserade applikationer är beroende av att varje tjänst har sitt eget API. Antalet API:er som organisationer snart kan hitta sig själva kan uppgå till tusentals. GraphQL tillhandahåller en kritisk saknad stift för att klara av dem alla. Utmaningen nu är att hitta det bästa sättet att implementera det tillsammans med äldre REST API:er som inte kommer att försvinna någon gång snart.