Middleware serverless: la storia della sua scelta

Siti web, software interni, software esterni tutti strettamente connessi tra di loro. Ogni modifica era sempre una fida lunga e piena di ostacoli, ogni rilascio un odissea.

Ogni fornitore che doveva integrarsi con noi doveva conoscere i nostri dati, dove risiedevano ecc…

Questa era la situazione in cui ci trovavamo quando abbiamo realizzato (🤷‍♂️ chissà come mai non l’avessimo capito prima) che dovevamo avere un middleware per poter organizzare meglio le comunicazione tra i software.

La scelta

La prima azione che abbiamo intrappreso è stato fare scouting tra molti fornitori di soluzioni middleware più o meno grosse.

Qualche cosa però non ci convinceva, molte soluzioni si basavano “l’installazione di una piattaforma” e l’implementazione dei servizi/connettori non era sempre agevole.

In questo periodo ci stavamo affacciando concretamente al serverless e ci è venuta l’idea: Perchè non creare da zero il nostro middleware completamente serverless?

La tecnologia

L’idea piacque e si iniziò l’analisi tecnologica.

AWS Appsync, AWS EventBridge furono i servizi su cui si era deciso di poggiare tutto il nostro middleware (sono i principali).

Il middleware non doveva essere complesso, elaborato, ma semplice, di basso livello e facilmente implementabile (siamo programmatori ci piace scrivere sempre codice!).

Si doveva garantire la scalabilità automatica, l’uptime più alto possibile e una facilità d’implementazione e di mantenibilità.

AWS Appsync

https://aws.amazon.com/it/appsync/

E’ stato scelto perchè ci permette di avere un’unico endpoint di collegamento, un’unico linguaggio d’interrogazione estremamente versatile e potente GraphQL.

Cache dei dati, sicurezza sono state altre caratteristiche che abbiamo apprezzato molto in questo servizio.

Su Appsync abbiamo basato quindi tutte le nostre API di interrogazione e sfruttuato la potenza di GraphQL per generare entità complesse basate su dati provenienti da fonti differenti. In questo modo ogni nuovo fornitore doveva solo conoscere le API GraphQL e dimenticarsi da dove arrivavano i dati che a lui interessavano.

Altro vantaggio che ci è venuto gratis con GraphQL è stato quello di delegare al chiamante i dati che necessitava e non dover creare ApiRest complesse per gestire un ser di dati in output differente per ogni richiesta.

AWS EventBridge

https://aws.amazon.com/it/eventbridge/

Su questo servizio abbiamo basato tutto il nostro sistema di eventi.

Prima un servizio poteva gestire una logica non nel suo dominio perchè l’architettura software era spesso basata in modo sincrono.

Con l’introduzione EventBridge, si è potuto astrarre le chiamate tra vari servizi, atomizzarli, rilegandoli solo al dominio di loro competenza, permettendo asincronicità nelle invocazioni e flussi più veloci.

La struttura

Per spiegare meglio quello fatto di seguito uno schema ad alto livello di dove e come il middleware si posiziona ora nella nostra architettura software.