MuleSoft tilføjede i denne uge en DataGraph-funktion til sin Anypoint-platform til integration af applikationer, der anvender GraphQL-forespørgselssproget til øjeblikkeligt at opdage, få adgang til og betjene data fra flere eksisterende API'er med en enkelt forespørgsel uden at skrive yderligere kode.
Samtidig har MuleSoft tilføjet yderligere connectorer Automation Anywhere, Google Sheets, JIRA, Netsuite og Stripe sammen med en forekomst af MuleSoft Accelerators til at oprette forbindelse til SAP-applikationer ved hjælp af connectors og bedste praksis defineret af MuleSoft.
Blandt de bedste API-udviklerpraksis inkluderer:
- Opret forventninger: Hold dine kommunikationslinjer åbne og klare. Fortæl udviklerne, hvad du forventer af dem og projektet, angiv klare deadlines, og tag fat på eventuelle smertepunkter, som API-funktionaliteten burde løse.
- Tjenestemeddelelser: Alle API'er og og tjenester bør stemme overens med forretningsmål og leadtjenester, der sigter mod at levere værdi for nye og eksisterende produkter og tjenester.
- Casestudier: Brug casestudier til at give beviser og illustrere de forbedringer, som API-adoption vil medføre for projektet.
- Dokumentation: Sørg for, at dokumentationsværktøjer er på plads, så udviklerteamet nøjagtigt kan dokumentere deres fremskridt med at adoptere API'en.
- SDK'er og biblioteker: Lever ressourcer såsom genbrugelig kode og processer (inklusive SDK'er og biblioteker) for at hjælpe med at fremskynde udvikling og implementering.
Endelig gør MuleSoft nu sin Anypoint Runtime Fabric tilgængelig for første gang på Kubernetes-platforme såsom Azure Kubernetes Service, Amazon Elastic Kubernetes Service og Google Kubernetes Engine. Anypoint Runtime Fabric gør det muligt konsekvent at implementere Anypoint-platformen indkapslet i en container.
Anypoint DataGraph anvender de samme kerne GraphQL-egenskaber, som MuleSoft tidligere har indlejret i software-as-a-service (SaaS)-applikationer leveret af moderselskabet Salesforce. Nu gøres disse muligheder mere tilgængelige for andre applikationer via et sæt lavkodeværktøjer i Anypoint-platformen, der gør det muligt for udviklere at anvende GraphQL bredere som et alternativ til REST API'er, siger Shaun Clowes, senior vice president for produktstyring hos MuleSoft.
Denne tilgang gør det nemmere for udviklere at integrere deres applikationer med andre datakilder, uanset om den applikation, de opretter, er bygget ved hjælp af procedurekode eller en lav-kode platform. Selv når udviklere foretrækker at skrive deres applikation ved hjælp af procedurekode, giver det stadig mening at bruge et lavkodeværktøj til at skabe integration hurtigere, bemærker Clowes.
Udviklere i dag skal være i stand til fleksibelt at forbruge data via flere API'er, efterhånden som digitale forretningstransformationsinitiativer fortsætter med at udvide og udvikle sig, tilføjer Clowes. Faktisk bliver udviklere forpligtet til hurtigt at komponere applikationer for at sætte deres organisationer i stand til dygtigt at reagere på hurtigt skiftende forretningskrav, siger Clowes.
Typerne af udviklere, der anvender integrationsværktøjer med lav kode, begynder også at udvide sig. Såkaldte borgerudviklere begynder at bygge applikationer, der skal forbruge data via API'er. Sofistikeringen af disse applikationer varierer naturligvis afhængigt af disse udvikleres færdigheder.
"Udfordringen med borgerudviklere er, hvor borgerskab de er," siger Clowes.
Uanset hvem der bygger applikationerne, bliver det meget nemmere for udviklere med forskellig ekspertise at genbruge API'er. Professionelle udviklere, for eksempel, kan oprette et bibliotek af kontrollerede API'er, som kan genbruges af andre udviklere. Den, der kræves, er en centraliseret tilgang til opbygning og implementering af API'er, der giver en tiltrængt styringsramme, da ansvaret for både opbygning og vedligeholdelse af API'er flyttes længere til venstre mod udviklere, bemærker Clowes. Det er ikke kun vigtigt ud fra et compliance-perspektiv, men også fordi det ikke er ualmindeligt, at udviklere arbejder på et separat projekt for at skabe overflødige API'er.
Fremover er det klart, at API'er er i centrum for applikationsudvikling, mens den fortsætter med at udvikle sig. Næste generations mikrotjenester-baserede applikationer afhænger af, at hver tjeneste har sin egen API. Antallet af API'er, som organisationer snart kan finde sig selv, kan tælle i tusindvis. GraphQL giver en kritisk manglende lynchpin til at klare dem alle. Udfordringen er nu at finde den bedste måde at implementere det på sammen med ældre REST API'er, der ikke forsvinder lige foreløbigt.