Le basi per affrontare lo sviluppo API-Driven

Questo è il primo di tre articoli in cui parliamo di come il nostro approccio allo sviluppo può essere equiparato ai processi ADD e come le API raggiungono un ruolo cruciale nella trasformazione digitale delle aziende. OneClickApp e Wavemaker nascono dall’idea di portare tutte queste metodiche e approcci in una piattaforma che è la sintesi ultima in cui il metodo Agile si semplifica all’ennesima potenza.


 

Alla domanda,ormai onnipresente di, “Cosa sono le API?” è stato risposto in più forum. Cominciamo con una domanda più interessante e pertinente: “Perché usare le API?”

Perché usare le API?

L’aspetto chiave con cui si può rispondere a questa domanda è che attraverso l’uso di API si introduce la standardizzazione delle interfacce (intese come dialogo tra microservizi) nel processo di sviluppo. Gli sviluppatori lavoreranno su API strutturate e standardizzate che non devono cambiare il loro comportamento sottostante, indipendentemente dalla tecnologia o dai componenti utilizzati.

Le API inoltre nascondono la complessità dell’implementazione e della tecnologia o infrastruttura sottostante, portando modularità e SoC (separation of concerns)  e consentendo un disaccoppiamento durante l’implementazione e il test di servizi indipendenti.

La proliferazione di applicazioni SaaS  che espongo API web, dà una nuova dimensione allo sviluppo di applicazioni, uno sviluppo in cui lo sviluppatore deve concentrarsi solo sulla logica di business e non sul coding vero e proprio delle applicazioni. Oggi sono tanti i servizi ausiliari come la gestione degli utenti (single sing on),il logging,le dashboard, il deployment, ecc… che possono essere invocati tramite API (servizi di terze parti o in-house). Questo accelera il tempo di sviluppo dell’applicazione.

Cosa è l’economia delle API?

In un mondo enterprise la risposta alla domanda “Perché usare le API?” è ancora più intrigante perché le API agiscono come gateway tra le risorse digitali aziendali e il mondo di internet. Le aziende trattano le API come un importante canale di guadagno. Infatti, in alcune organizzazioni come Salesforce.com, le entrate ottenute tramite la vendita di API contribuisce a oltre il 50% del fatturato totale. La capacità delle API di generare entrate monetizzando le attività digitali ha dato vita ad un nuovo modo di affrontare i ricavi delle imprese. Questo fenomeno ha bisogno di un nuovo nome , è stato quindi coniato lo slogan “ API Economy”.

 

Cosa è ADD (API-Driven Development) ?

Un metodo di creazione di app definito API-first, inizia con lo sviluppo di API. Le API sono quindi il primo artefatto creato durante il processo di sviluppo dell’app. Gli API contracts (specifiche delle API e firme, inclusi il nome, i parametri, i tipi, ecc.) vengono creati da architetti specializzati in API o da sviluppatori di front-end responsabili della creazione dell’esperienza dell’utente finale. Le API sono poi finalizzate in collaborazione tra gli sviluppatori front-end e back-end.

Una volta definiti gli endpoint e finalizzate le API, gli sviluppatori di front-end creano modellini di interfacce attorno alle API e perfezionando l’esperienza dell’utente finale. Parallelamente, gli sviluppatori del back-end implementano la logica sottostante delle API. Sono create vere e proprie test suite attorno a queste API che, in un certo senso, favoriscono l’idea dello sviluppo test-driven. Infine, le implementazioni degli sviluppatori front-end e back-end vengono unite. Questi test sono necessari per evitare insuccessi e fare in modo che gli sviluppatori possano seguire e attenersi agli “API Contracts” stabiliti nei passi iniziali.

A livello di implementazione e scrittura di codice, le API oggi sono tipicamente progettate utilizzando l’architettura REST con i payload in formato JSON.  SOAP, XML e altri standard sono considerati pesanti e destinati a scomparire.

Benefici derivati da ADD

Oltre ai vantaggi delle API elencate nella sezione “Perché usare le API?”, lo sviluppo API-driven aggiunge una serie di vantaggi per rendere il lavoro di uno sviluppatore e il processo di sviluppo delle applicazioni più semplice.

Lo sviluppatore riesce a focalizzarsi solo sulla logica di business, anziché sul coding. L’esempio più classico è Google Maps API: se voglio cercare la distanza tra due indirizzi posso invocare una API di Google che esegue per  me il calcolo desiderato invece che scrivere software e codice che esegue fantastici algoritmi, spesso incomprensibili ad uno sviluppatore che non conosce metodiche di Geo localizzazione GPS.

App Development realmente più rapido

Un approccio ADD consente allo sviluppatore di concentrarsi solo sulla logica di business. In ADD, si prevede che tutti i servizi sussidiari saranno accessibili tramite API. Inoltre, gli accordi iniziali derivanti dagli API contracts, l’implementazione parallela da parte di teams di sviluppatori di fornt-end e back-end e la fusione senza problemi dei codice di front-end e back-end, comportano enormi risparmi di tempo nella costruzione di applicazioni.

Focalizzarsi solo sulla logica di business

Se si prevede che gli sviluppatori utilizzino API per tutti i servizi sussidiari (di terze parti o interne), come la gestione degli utenti e del sign-on, del logging, ecc. di conseguenza, l’obiettivo dello sviluppo è puramente focalizzato sull’implementazione della logica aziendale che la App automatizza.In questo modo non esistono più spese di tempo inutili per l’attuazione o costruzione di strutture tecnologiche che costituiscono lo scheletro dell’app. Infatti, nel fiorente ecosistema delle API, i marketplaces di API come ProgrammableWeb e Mashape, stanno rendendo il processo di discovery e di utilizzo delle API richieste molto più facile.

Un’ottima documentazione è un punto di forza

Una cosa che accomuna tutte le aziende che sono divenute grandi grazie all’economia delle API (come Twitter, Expedia,Apigee, Google ecc.), è che le loro API sono facili da usare, da trovare e hanno una cospicua e perfetta documentazione. Una API efficace è determinata da una documentazione efficace. Infatti, strumenti come Swagger sono nati per aiutare le aziende moderne nel processo di descrizione e visualizzazione delle API web. In sintesi, un effetto positivo di ADD è quello di avere una grande documentazione delle API esposte. Questo è stato spesso un aspetto normalmente trascurato nel tradizionale processo di sviluppo del prodotto.

Applicazioni nativamente basate sui Microservices

Uno degli aspetti di cui abbiamo parlato  nella sezione “Perchè usare le API?” è la modularità. Le applicazioni sviluppate con ADD tendono ad essere modulari per natura, con ogni modulo che rappresenta un micro-servizio (terzo o proprio). L’applicazione principale in sé sembra essere una raccolta di micro applicazioni che parlano tra loro utilizzando API. Questa architettura di app è chiamata microservices e ha dei veri e propri vantaggi. Ad esempio, se sul servizio di gestione utenti di un’applicazione costruita a livello di microservizio esiste un sovraccarico, è possibile scalare tale servizio di gestione utenti aggiungendo altre risorse o ottimizzando l’API che espone il servizio. Confrontate questo con l’architettura tradizionale delle vecchie applicazioni monolitiche, in cui l’intera applicazione deve essere ridimensionata…in questo caso solo una parte dell’app necessiterebbe uno scaling.

La tua App è pronta per un mondo sempre connesso

Con la proliferazione di dispositivi smart e l’evoluzione dell’economia delle API, stiamo andando verso un mondo digitale (Internet of Things, IIoT è  un esempio) dove tutto è collegato tramite API. Con lo sviluppo API-driven e l’API come fulcro, la vostre applicazioni non solo sopravviveranno, ma potranno prosperare in questo “mondo connesso”.

What Next?

L’ADD (API-Driven Development) è sempre di più un potente processo di sviluppo e sta acquisendo grande rilievo tra i team IT in varie organizzazioni e aziende. Quali sono le tipiche fasi del ciclo di vita di un’API? Cosa si può fare per rendere ADD come l’approccio di sviluppo predefinito nelle organizzazioni e nelle aziende? Parliamo di queste domande e delle loro risposte  nei post successivi, dove parleremo del ciclo di vita delle API e del ADD di nuova generazione.