Opzioni per implementare un’API per la vostra dApp Web3

Introduzione

I progetti Web3 sono più simili alla blockchain quando sono completamente decentralizzati, ma in alcuni casi è necessario creare un’API centralizzata per la propria applicazione a causa delle limitazioni della blockchain. Molti progetti di successo si affidano alle loro potenti API per essere in grado di rispondere alle centinaia di migliaia di richieste al minuto. Ad esempio, Opensea non sarebbe così veloce se non avesse il suo database.
In questo articolo, accennerò ad alcune limitazioni della blockchain e poi presenterò i modi per implementare un’API per la vostra dApp.

Perchè abbiamo bisogno di una API ??

Leggere i dati dalle blockchain richiede molto tempo. Inoltre, alcune applicazioni hanno una logica complessa e l’implementazione di questa logica nei contratti intelligenti aumenta il consumo di gas.
Un’interfaccia di programmazione delle applicazioni (API) definisce una modalità di comunicazione tra programmi informatici. Creando un’API per la vostra dApp potrete recuperare i dati richiesti da essa invece di interrogare l’intera blockchain.

Ma dunque che cosa sono le API ??

Le API (Application Programming Interface) sono un insieme di protocolli e strumenti per la creazione di applicazioni che interagiscono con un determinato sistema.
In pratica, le API servono a consentire la comunicazione tra due sistemi differenti.

Nel caso della Blockchain, le API possono essere utilizzate per consentire a un’applicazione di interagire con la catena di blocchi e di utilizzare i dati in essa contenuti.
Ad esempio, un’applicazione potrebbe utilizzare le API di una Blockchain per verificare la validità di una transazione o per recuperare il saldo di un indirizzo specifico.

Le API possono velocizzare l’utilizzo della Blockchain in diversi modi. Innanzitutto, consentono di semplificare l’interazione con la catena di blocchi, rendendo più facile per gli sviluppatori creare nuove applicazioni basate sulla Blockchain. Inoltre, le API possono essere utilizzate per creare “ponti” tra diverse Blockchain, consentendo ai dati di essere condivisi e utilizzati tra più piattaforme diverse.

Inoltre, le API possono essere utilizzate per creare servizi “on demand”, ovvero per fornire accesso ai dati della Blockchain solo quando sono richiesti, evitando di dover fare una copia di tutti i dati in un database locale e quindi rendendo più efficiente l’utilizzo della memoria.

Infine, le API possono essere utilizzate per creare servizi di “abstracting”, ovvero per nascondere la complessità della Blockchain agli utenti finali, rendendo più facile per loro utilizzare le applicazioni basate sulla Blockchain.

In sintesi, le API rappresentano un modo semplice e veloce per gli sviluppatori di creare applicazioni che interagiscono con la Blockchain, rendendo più facile per gli utenti finali utilizzare queste applicazioni e facilitando la condivisione dei dati tra diverse piattaforme basate sulla Blockchain.

GraphQL – un linguaggio per interfacciarsi con la Blockchain

GraphQL è un linguaggio di query progettato per fornire un modo semplice ed efficiente per i clienti di interagire con i dati di un server.
GraphQL consente ai clienti di richiedere esattamente i dati di cui hanno bisogno, e solo quelli, evitando di dover scaricare tutti i dati presenti in un database o in una risorsa.

Per utilizzare GraphQL per interagire tra la Blockchain Ethereum e IPFS (InterPlanetary File System), è necessario prima di tutto creare un server GraphQL che faccia da intermediario tra le due piattaforme. Questo server dovrà essere in grado di connettersi alla Blockchain Ethereum utilizzando una libreria come Web3.js, e di utilizzare le API di IPFS per accedere ai file presenti sulla rete.

Una volta creato il server GraphQL, sarà possibile utilizzare GraphQL per eseguire query sui dati presenti sulla Blockchain Ethereum e su IPFS.

Ad esempio, sarà possibile utilizzare GraphQL per richiedere il saldo di un indirizzo specifico sulla Blockchain Ethereum o per ottenere il contenuto di un file su IPFS.

Per eseguire queste query, sarà sufficiente inviare una richiesta HTTP POST al server GraphQL con il corpo della richiesta in formato JSON contenente la query GraphQL. Il server GraphQL eseguirà quindi la query e restituirà i dati richiesti al client in formato JSON.

In sintesi, GraphQL consente di interagire con la Blockchain Ethereum e con IPFS in modo semplice e veloce, fornendo un modo efficiente per accedere ai dati di cui si ha bisogno senza dover scaricare tutti i dati presenti in un database o in una risorsa.

MORALIS

Moralis non è solo un indicizzatore, questa piattaforma fornisce molte soluzioni come API blockchain, API NFT, autenticazione web3, API token e API stream.
I prodotti di Moralis possono rispondere facilmente a molte delle vostre esigenze. In questo modo non sarà necessario implementare un’API o un indicizzatore da zero per avere un accesso veloce ai dati della blockchain.

In Moralis, potrete creare un database di eventi di smart contract e interrogarlo come vorrete.

Sviluppare una propria API

Questa è sempre un’opzione valida e che da pieno controllo sul codice e sulle azioni che si andranno a sviluppare. Dovrete però spendere molto tempo per sviluppare un’API che potrebbe comunque rivelarsi non buona come le opzioni precedenti.
Richiede maggiori conoscenze, studio e tempo di sviluppo.

L’aspetto positivo è che potete implementare e aggiungere funzionalità uniche per la vostra dApp. Gli indicizzatori di cui ho parlato nelle sottosezioni precedenti sono progettati per rispondere al maggior numero possibile di scenari diversi. Ma quando si crea un’API personalizzata, è possibile personalizzarla come si desidera.

Potete sviluppare l’API utilizzando qualsiasi linguaggio di programmazione, ma dovete tenere conto dei seguenti suggerimenti:

  • Integrazione della blockchain
  • Manutenibilità
  • Velocità
  • Strumenti disponibili

Conclusioni

Se volete sviluppare un’API per la vostra dApp o se non siete sicuri di quale delle opzioni disponibili sia la più adatta a voi, tenete sempre presente che anche utilizzando un indicizzatore potreste aver bisogno di sviluppare un’API personalizzata per tenere traccia di alcuni lavori che l’indicizzatore già pronto potrebbe non supportare.
Nelle prossime parti ci cimenteremo nello sviluppo di un’API per un semplice smart contract, quindi assicuratevi di seguire il blog per non perdervi i prossimi aggiornamenti!

Ansible – automazione IT e Configuration Management (II parte)

Ansible + Vagrant Environment

Ansible + Vagrant Environment

 

 

 

 

 

 

Nel primo articolo “Ansible per l’automazione IT ed il Configuration Management” abbiamo descritto le caratteristiche principali di questo interessante prodotto per il Configuration Management. In questo secondo articolo descriveremo con degli esempi come utilizzare nel concreto Ansible.

Per preparare il nostro ambiente di lavoro sfrutteremo un’altro software, che rappresenta, anch’esso una delle grandi novita’ del Web degli ultimi mesi come Vagrant, di cui abbiamo parlato nell’articolo “Virtualizzazione e provisioning senza sforzo“.

configuriamoci l’ambiente Vagrant:

$ vagrant box add pre http://files.vagrantup.com/precise32.box
$ vagrant init precise32
$ vagrant up

a seguito dell’ultimo comando, vedremo dei messaggi come questi:

Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
Guest Additions Version: 4.2.0
VirtualBox Version: 4.3
[default] Mounting shared folders...
[default] -- /vagrant

Vagrant ha quindi scaricato e creato per noi una macchina virtuale Ubuntu Precise (32bit). Scorrendo i messaggi ci sono due cose importanti da notare: la prima è che il traffico sulla porta 2222 del nostro pc locale sarà inoltrato alla porta 22 della macchina virtuale; la seconda è che l’utente “vagrant” sulla macchina remota può connettersi con la password “vagrant” ed ha già i privilegi per diventare root con sudo. Aggiorniamo quindi l’inventario delle macchine che decidete di coinvolgere modificando il file /etc/ansible/hosts

Dopo aver preso confidenza con Vagrant iniziamo la configurazione dell’ambiente per Ansible, iniziando ad usarlo per automatizzare i compiti di ogni giorno.

Configuriamo il file /etc/ansible/hosts tramite comando:

# sudo bash -c 'echo [web] >> /etc/ansible/hosts'
# sudo bash -c 'echo 127.0.0.1:2222 ansible_ssh_user=vagrant ansible_ssh_pass=vagrant >> /etc/ansible/hosts'

Verifichiamo che ansible sia in grado di leggere correttamente i parametri inseriti nel file hosts usando il seguente comando:

# ansible -m ping all
127.0.0.1 | success >> {
"changed": false,
"ping": "pong"
}

Ansible facts
come possiamo essere sicuri che la macchina a cui ci stiamo connettendo sia quella giusta ? Diamo un’occhiata ai “facts”, ovvero a tutte le informazioni che Ansible raccoglie…

# ansible web -m setup | less

otteniamo cosi’ una serie di dati in formato JSON tra cui notiamo che il nostro nuovo server ha come hostname ‘localhost’.
A titolo didattico scriveremo un playbook per installare un webserver nginx sul nuovo server.

Ora apriamo un editor per iniziare a scrivere il nostro playbook che si chiamera’ nginx.yml :

--- PLAYBOOK ottimizzato su Centos Linux
- name: installa NGINX e avvia il servizio
   remote_user: root
   sudo: yes
   hosts: web
   tasks:
   - name: installazione Nginx
     apt: pkg=nginx state=installed update_cache=true
     notify:
     - start nginx
   handlers:
     - name: start nginx
     service: name=nginx state=started

Come possiamo notare nel playbook abbiamo editato una lista di task, uno per ogni “step” del nostro compito.
Se stiamo usando virtualbox come hypervisor, dobbiamo aggiungere una riga al file (bastera’ solo decommentarla) di configurazione di vagrant perché attivi il forwarding della porta 80 della guest sulla porta 8080 del nostro pc.

(vedi https://docs.vagrantup.com/v2/networking/forwarded_ports.html)

config.vm.network "forwarded_port", guest: 80, host: 8080

e dare il comando per ricaricare la virtual machine con la nuova configurazione:

vagrant reload
[default] Attempting graceful shutdown of VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] -- 80 => 8080 (adapter 1)
[default] Booting VM...
[default] Machine booted and ready!

Ora possiamo lanciare il playbook

# ansible-playbook nginx.yml

PLAY [installa NGINX e avvia il servizio] *****************************

GATHERING FACTS ***************************************************************
ok: [127.0.0.1]

TASK: [installazione Nginx] ***************************************************
changed: [127.0.0.1]

NOTIFIED: [start nginx] *******************************************************
changed: [127.0.0.1]

PLAY RECAP ********************************************************************
127.0.0.1 : ok=3 changed=2 unreachable=0 failed=0

sulla macchina virtuale potrete visualizzare, dal syslog, quello che sta accadendo:

ansible-apt: Invoked with dpkg_options=force-confdef,force-confold upgrade=None force=False package=[‘nginx’] purge=False state=installed update_cache=True pkg=nginx default_release=None install_recommends=True deb=None cache_valid_time=None
Mar 19 15:59:33 precise32 ansible-service: Invoked with name=nginx pattern=None enabled=None state=started sleep=None arguments= runlevel=default

ora sulla macchina virtuale mi ritrovo con l’nginx attivo e rispondente all’indirizzo 127.0.0.1:8080

Welcome to nginx!

Come gia accennato nel primo articolo la curva di apprendimento di questo ottimo strumento di Management dei server e’ davvero bassa e funzionale, ed in poco tempo si e’ in grado di gestire un ambiente ad alto volume di macchine.

Questa è solo una semplice introduzione al mondo di Ansible, e prima di concludere vi faccio inoltre presente che Ansible non è solo usufruibile da linea di comando ma presso il sito ufficiale è disponibile una web dashboard che permette di controllare i job, avere report, statistiche e così via.

Esiste anche Ansible Galaxy , che è invece un repository comunitario di “ricette”, playbooks, task moduli e tutto quello che si può immaginare … Quindi se doveste installare e configurare software come tomcat, oracle, mongodb, jenkins, drupal, rabbitmq e tanti altri, troverete già tutto pronto.
Di sicuro una base di partenza molto comoda per le vostre personalizzazioni!

Se tutto ciò non bastasse ancora, Ansible ha una API estremamente chiara e flessibile per scrivere moduli custom in Python o qualsiasi altro linguaggio, un esempio concreto

#AnsibleConfigurationManagement

Nginx HTTP 2.0 supportato entro fine 2015

Nginx e supporto HTTP 2.0

Nginx e supporto HTTP 2.0

Nginx supporta da sempre l’attuale protocollo HTTP 1.1 ed il protocollo di Google SPDY. Con l’annuncio di HTTP 2.0, Nginx è pronta a convertire il supporto SPDY verso il neonato HTTP 2.0 entro la fine di quest’anno.

Il protocollo HTTP 2.0 è la nuova generazione del protocollo attuale e su cui si basa l’intera Internet, che viene adesso rinnovato dopo circa 16 anni.

Questo non significa certo che lo standard è stato finalizzato ed è appropriato all’operatività, ma indica che tutte le sue specifiche sono state definite in modo conclusivo e la documentazione può passare al gruppo RFC per l’approvazione finale come standard definitivo.

Comunque, anche dopo la dichiarazione a standard, il protocollo non entrera’ subito in attività, anche perché dovrà, prima di tutto, essere implementato e supportato nei browser e nei Web server.

Fra i Web server, Nginx si dice comunque pronto a supportare questa nuova tecnologia e il motivo di questa sicurezza sta nel pieno supporto alla versione draft 3.1 di SPDY, di cui Google ha deciso l’interruzione dello sviluppo e l’esclusione da Chrome.

Il fatto che il protocollo HTTP 2.0 sia gran parte basato su SPDY permette a Nginx di avere già una solida base di codice pronto per essere riutilizzato ai fini di ospitare il nuovo HTTP quando questo diventerà lo standard. Secondo Owen Garrett, responsabile di prodotto per Nginx : ” l’implementazione nel Web browser sarà facile e snella, in quanto la maggior parte dei siti Web SPDY già viene eseguita correttamente in Nginx “.

HTTP/2 si baserà, inoltre, sulle stesse API che già conoscono e usano gli sviluppatori del web, ma in più offrirà feature esclusive a cui questi possono attingere. Fino ad oggi, ad esempio, bisognava adottare alcune tecniche di ottimizzazione per impedire alla pagina di effettuare troppe richieste HTTP. Il nuovo protocollo permetterà invece l’esecuzione di un numero superiore di richieste contemporanee, attraverso una tecnica chiamata multiplexing , senza che queste blocchino il caricamento degli elementi della pagina.

HTTP/2 effettua un numero di connessioni inferiore rispetto alle tecnologie attuali, fattore che si traduce con un carico minore richiesto ai server e alle reti per il caricamento dei dati. Il nuovo protocollo supporta TLS ma non obbligherà all’implementazione del layer di crittografia.

Uno dei più importanti cambiamenti di HTTP 2.0 infatti sara’ la crittografia basata su protocollo TLS, a cui Nginx dice di voler dare un approccio implementativo persistente. Inoltre, il nuovo protocollo Internet introduce alcune differenze nella gestione delle priorità, in modo da fornire un maggiore controllo sui flussi di traffico. Sempre secondo Garrett, la maggiore sfida non sarà tanto nell’implementazione nei browser e nei Web server, quanto nell’adeguamento dei siti Web, che dovranno essere ottimizzati per il protocollo HTTP 2.0.

“Ci potrebbe essere molto lavoro di ottimizzazione e re-ingegnerizzazione dei siti Web, soprattutto per mantenere la compatibilità con i client più anziani” ha detto Garrett.

 

Introduzione a CouchDB

couchDBCouchDB e’ un database documentale NoSQL disponibile con l’ampia licenza Apache.
Apache CouchDB e’ un moderno documentale richiamabile semplicemente con l’HTTP e che al tempo stesso offre le piu’ avanzate funzionalita’ di replicazione dati e di ricerca in parallelo (Map/Reduce).

CouchDB (acronimo di Cluster Of Unreliable Commodity Hardware) e’ uno dei piu’ diffusi DB documentali Web grazie alla sua velocita’, alla flessibilita, alla semplicita’ di utilizzo ed al… prezzo!

Installazione

Installare CouchDB e cURL (che serve per accedere) e’ facile su Linux (eg. RedHat, Fedora, CentOS, Scientific Linux, …):

yum install couchdb curl -y
oppure
sudo aptitude install couchdb curl
Ora bisogna far partire il server CouchDB con il comando couchdb. Per verificare se funziona tutto basta un comando:
# curl http://127.0.0.1:5984
{“couchdb”:”Welcome”,”uuid”:”fd91d8b7b77c7f6d75d5937326a95ad2″,”version”:”1.5.0″,”vendor”:{“version”:”14.04″,”name”:”Ubuntu”}}

CouchDB e’ disponibile per tutti i sistemi UNIX-based ed anche sulle piattaforme MS-Windows e Mac OS X. Installare le versioni precedenti di CouchDB non era cosi’ semplice: bisognava partire dall’installazione del linguaggio di programmazione Erlang e ricompilare…

Utilizzo

CouchDB e’ accessibile esclusivamente attraverso un HTTP-based RESTful API, cio’ significa che, anziche’ collegarsi al DB server utilizzando un’applicazione client per interagire con il sistema, basta utilizzare un software in grado di interagire con un HTTP server web per fare richieste. CouchDB che a sua volta eseguira’ le azioni nel database, restituendo una risposta appropriata quando finito.
Quindi e’ possibile gestire il database semplicemente visitando gli URL nel browser web oppure utilizzando gli strumenti da riga di comando come curl o, cosa piu’ importante, attraverso qualsiasi linguaggio di programmazione che supporta richieste HTTP.
L’implementazione dell’interfaccia REST (Representational Transfer State) su CouchDB e’ molto completa poiche’ non si limita al CRUD (CREATE, READ, UPDATE, DELETE) ma ogni operazione svolta su CouchDB e’ richiamabile con l’HTTP.

Futon

CouchDB possiede una sua interfaccia web molto user friendly, Futon, dalla quale e’ possibile eseguire qualsiasi operazione per la gestione di un database, come l’inserimento, la visualizzazione, la modifica e la cancellazione dei dati. Inoltre Futon contiene anche le principali funzionalita’ di amministrazione di un database, come le impostazioni di configurazione, la replicazione dei dati, definizione dei ruoli e privilegi e uno strumento di testing.
Per accedere all’interfaccia web basta collegarsi da browser a localhost:5984/_utils

cURL

Per i piu’ affezionati alla linea di comando (come me per esempio), si puo’ usare curl, un ottimo tool utile per trasferire dati da/a un server utilizzando vari protocolli, tra cui HTTP, HTTPS, FTP. Il modo per farlo e’ digitando:

curl <opzioni> <ip_host>:5984/<database>/<record>.

Da notare che nel URL viene specificata la porta 5984, e’ quella usata dal processo di couchdb.
Tra le opzioni piu’ importanti: -X per specificare il tipo di richiesta http: GET per richiedere dati, PUT e POST per modificare dati o DELETE per cancellare. Inoltre -d permette di specificare i dati da includere nella richiesta, ad esempio per modificare documenti nel database.
Esempi:

# Crea il database "libri"
curl -X PUT http://127.0.0.1:5984/libri

# Visualizza il contenuto di "libri" (all'inizio e' vuoto)
curl -X GET http://127.0.0.1:5984/libri

# Crea il documento con _id "lafineeilmioinizio" dentro il database "libri"
curl -X PUT http://127.0.0.1:5984/libri/lafineeilmioinizio \
 -d '{"titolo":"La fine e il mio inizio", "autore":"Tiziano Terzani", 
      "casa_editrice":"Longanesi", "prezzo":"18.60"}'

# NB: Tutte le volte che un documento viene modificato riceve un revision number
# Modifica un documento aggiungendo come allegato un'immagine
curl -X PUT http://127.0.0.1:5984/libri/lafineeilmioinizio/cover.jpg?rev=1-XXX \
 --data-binary @images/budda.jpg -H "Content-Type: image/jpg"

# Crea un documento hungergames copiando il contenuto da un altro documento
curl -X COPY http://127.0.0.1:5984/libri/lafineeilmioinizio -H "Destination: hungergames"

# Cancella il documento con _id "hungergames"
curl -X DELETE http://127.0.0.1:5984/libri/hungergames?rev=1-YYY 

# Effettua un caricamento massivo di documenti da file
curl -X POST http://127.0.0.1:5984/libri/_bulk_docs -H "Content-type: application/json" -d @biblio.json

# Visualizza tutto il contenuto del database "libri" e il dettaglio dei documenti presenti
curl -X GET http://127.0.0.1:5984/libri/_all_docs?include_docs=true

Architettura

CouchDB e’ un database document-oriented. Cio’ significa che a differenza dei piu’ tradizionali DBMS (Database Management System) relazionali come Oracle e PostgreSQL, i dati non vengono memorizzati in tabelle (o se volete, relazioni), ma in “documenti”.

Su un database relazionale le tabelle hanno una struttura rigida, sono composte da campi definiti prima della effettiva memorizzazione dei dati. Le tabelle vanno dichiarate con gli opportuni statement DDL, prima di essere utilizzate. Ogni tabella e’ composta da tuple (ovvero le righe della tabella o i record) che contengono i dati. La gestione dei dati si effettua con statement DML. I comandi DDL e DML della stragrande maggioranza dei DB relazionali sono in SQL. Ora dimentichiamoci tutto questo…

In CouchDB il concetto di relazione o di tabella non esiste, l’elemento fondamentale e’ il documento che contiene al suo interno tutti i dati relativi, organizzati in modo eterogeneo. Si possono aggiungere e modificare i campi anche dopo l’effettivo inserimento dei dati. In questo modo record appartenenti alla stessa categoria di informazioni possono avere campi diversi tra di loro. La chiave primaria dei database relazionali viene tradotta nel campo univoco _id di CouchDB, creato automaticamente dall’engine del DBMS (ma che e’ anche possibile indicare in modo esplicito.

Dal punto di vista del sistema operativo CouchDB si presenta come un unico processo beam.smp in ascolto sulla porta TCP 5984 (6984 se e’ abilitato l’HTTPS). In realta’ all’interno del processo operano diversi thread con compiti specifici.
I file utilizzati da CouchDB su Linux si trovano in /etc/couchdb, i file di database su /var/lib/couchdb, i log su /var/log/couchdb.

Consistenza dei dati e replicazione

CouchDB non utilizza alcun meccanismo di locking ma sfrutta l’MVCC (Multiversion Concurrency Control), ogni modifica di un oggetto ne crea una nuova versione. Le versioni precedenti non vengono cancellate. Se due modifiche vanno in conflitto poiche’ accedono allo stesso documento, la seconda riceve un errore in save. L’applicazione deve riprendere l’ultima versione del documento e rieseguire l’UPDATE.
L’isolamento e’ mantenuto solo a livello di un singolo documento, questa e’ una notevole semplificazione, rispetto alla complessa logica transazionale di altri database, ma consente l’ottimizzazione, la parallelizzazione e la distribuzione dei dati in modo semplice. A livello di accesso al file di dati ogni singola modifica ad un documento rispetta le proprieta ACID (Atomic Consistent Isolated Durable) con la serializzazione delle modifiche sui documenti e la scrittura sincrona sul disco.

Piu’ database CouchDB possono essere collegati tra loro in modo molto semplice. I database vengono aggiornati tra loro con una replicazione peer-to-peer incrementale implementata nativamente nell’engine. CouchDB permette una replicazione bidirezionale asincrona, utilizza un meccanismo automatico di risoluzione dei conflitti e fornisce una eventual consistency tra i database. Se i database sono ospitati su nodi differenti si ottiene con questo la distribuzione dei dati.
La replicazione di CouchDB puo’ essere utilizzata sia per sincronizzare database locali che per complesse configurazioni con sharding dei dati.