Questa settimana MuleSoft ha aggiunto una funzionalità DataGraph alla sua piattaforma Anypoint per l'integrazione di applicazioni che utilizzano il linguaggio di query GraphQL per scoprire, accedere e servire istantaneamente i dati da più API esistenti con una singola query senza scrivere alcun codice aggiuntivo.
Allo stesso tempo, MuleSoft ha aggiunto ulteriori connettori Automation Anywhere, Google Sheets, JIRA, Netsuite e Stripe, insieme a un'istanza di MuleSoft Accelerators per la connessione ad applicazioni SAP utilizzando connettori e best practices definite da MuleSoft.
Tra le migliori pratiche per gli sviluppatori di API figurano:
- Crea aspettative: Mantieni le tue linee di comunicazione aperte e chiare. Spiega agli sviluppatori cosa ti aspetti da loro e dal progetto, fornisci scadenze chiare e affronta eventuali punti deboli che la funzionalità API dovrebbe risolvere.
- Messaggistica di servizio: Tutte le API e tutti i servizi devono essere in linea con gli obiettivi aziendali e guidare i servizi volti a fornire valore per prodotti e servizi nuovi ed esistenti.
- Casi di studio: Utilizza casi di studio per fornire prove e illustrare i miglioramenti che l'adozione dell'API porterà al progetto.
- Documentazione: Assicurati che gli strumenti di documentazione siano attivi in modo che il team di sviluppatori possa documentare accuratamente i propri progressi nell'adozione dell'API.
- SDK e librerie: Fornisci risorse come codice e processi riutilizzabili (inclusi SDK e librerie) per accelerare lo sviluppo e l'implementazione.
Infine, MuleSoft sta ora rendendo Anypoint Runtime Fabric ora disponibile per la prima volta su piattaforme Kubernetes come Azure Kubernetes Service, Amazon Elastic Kubernetes Service e Google Kubernetes Engine. Anypoint Runtime Fabric consente di distribuire in modo coerente la piattaforma Anypoint incapsulata all'interno di un container.
Anypoint DataGraph utilizza le stesse funzionalità GraphQL di base che MuleSoft ha precedentemente incorporato nelle applicazioni SaaS (software-as-a-service) fornite dalla società madre Salesforce. Ora queste funzionalità vengono rese disponibili più ampiamente ad altre applicazioni tramite una serie di strumenti low-code nella piattaforma Anypoint che consente agli sviluppatori di utilizzare GraphQL in modo più ampio come alternativa alle API REST, afferma Shaun Clowes, vicepresidente senior per la gestione dei prodotti presso MuleSoft.
Questo approccio semplifica agli sviluppatori l'integrazione delle loro applicazioni con altre origini dati, indipendentemente dal fatto che l'applicazione che creano sia creata utilizzando codice procedurale o una piattaforma low-code. Anche quando gli sviluppatori preferiscono scrivere la loro applicazione utilizzando il codice procedurale, ha comunque senso utilizzare uno strumento low-code per creare un'integrazione più veloce, osserva Clowes.
Gli sviluppatori di oggi devono essere in grado di consumare dati in modo flessibile tramite più API mentre le iniziative di trasformazione del business digitale continuano ad espandersi ed evolversi, aggiunge Clowes. In effetti, agli sviluppatori viene richiesto di comporre rapidamente applicazioni per consentire alle loro organizzazioni di rispondere abilmente ai requisiti aziendali in rapida evoluzione, afferma Clowes.
Anche i tipi di sviluppatori che utilizzano strumenti di integrazione a basso codice stanno iniziando ad espandersi. I cosiddetti citizen developer stanno iniziando a creare applicazioni che necessitano di consumare dati tramite API. La sofisticatezza di queste applicazioni varia naturalmente a seconda delle capacità di quegli sviluppatori.
"La sfida con gli sviluppatori cittadini è come sono cittadini", afferma Clowes.
Indipendentemente da chi crea le applicazioni, sta diventando molto più facile per gli sviluppatori con competenze diverse riutilizzare le API. Gli sviluppatori professionisti, ad esempio, potrebbero creare una libreria di API controllate che potrebbero essere riutilizzate da altri sviluppatori. Quello che è richiesto è un approccio centralizzato alla creazione e alla distribuzione di API che fornisca un quadro di governance tanto necessario poiché la responsabilità sia della creazione che della manutenzione delle API si sposta ulteriormente a sinistra verso gli sviluppatori, osserva Clowes. Questo è fondamentale non solo dal punto di vista della conformità, ma anche perché non è raro che gli sviluppatori che lavorano su un progetto separato creino API ridondanti.
Andando avanti, è chiaro che le API sono al centro dello sviluppo dell'applicazione mentre continua ad evolversi. Le applicazioni basate su microservizi di nuova generazione dipendono da ogni servizio per avere la propria API. Il numero di API che le organizzazioni potrebbero presto trovarsi potrebbe arrivare a migliaia. GraphQL fornisce un fulcro fondamentale mancante per far fronte a tutti loro. La sfida ora è trovare il modo migliore per implementarlo insieme alle API REST legacy che non scompariranno presto.
