Dietro Qboxmail: il nostro stack tecnologico

In occasione del rifacimento del nuovo pannello vogliamo raccontarvi cosa si nasconde dietro allo strumento utilizzato dai nostri utenti per gestire i propri servizi email. Con il salire del numero di utenti e l’allargarsi dei sistemi, è arrivato il momento di migliorare quella che è l’interfaccia che lega i nostri clienti alla nostra infrastruttura email: il pannello di controllo.

 

Il nostro pannello è composto da due applicazioni principali:

• Ruby
• JavaScript

Il backend del pannello di Qboxmail è interamente scritto in Ruby, questa scelta è dovuta alla popolarità che il linguaggio ha guadagnato negli ultimi 5 anni nell’ambito dello sviluppo web. Il compito del backend è quello di esporre delle API RESTful che consentono d’interagire con il nostro sistema in modo programmatico senza la necessità di utilizzare personalmente l’interfaccia. Questo consente a tutti gli sviluppatori di automatizzare le interazioni e integrare i dati da noi forniti in una qualsiasi altra piattaforma.

 

Avere questo obiettivo ha certamente influito nella scelta del linguaggio, framework come Sinatra e Ruby on Rails hanno reso Ruby una delle scelte preferite di chi deve realizzare questo tipo di applicazioni, e proprio quest’ultimo è il framework che fa da motore al nostro pannello.

 

Scegliere Ruby on Rails ha consentito di non perdere troppo tempo nel re-implementare una solida interfaccia HTTP, per concentrarsi sulla gestione dei diversi strumenti che compongono l’ecosistema di Qboxmail.

 

Per gestire l’intera infrastruttura email gli strumenti utilizzati sono molti e collocati su diversi livelli dell’architettura. Il compito della nostra applicazione Rails, è quello di orchestrare tutti questi tool (script bash, query SQL, applicativi anche legacy) e farli funzionare in modo complementare. A livello pratico, questo vuol dire avere a che fare con diversi database, diversi strumenti e diversi linguaggi di programmazione.

Con Ruby coordiniamo le operazioni e ci assicuriamo che il sistema sia sempre in uno stato coerente a tutti i suoi livelli.

 

La stessa applicazione Rails all’avvio crea due pool di processi, aventi compiti differenti:

• gestire le interazioni dirette con gli utenti
• eseguire le operazioni più dispendiose in modo asincrono e sequenziale

Il tipico workflow che si innesca con ogni richiesta avviata da un utente è questo:

• l’utente manda una richiesta tramite la nostra interfaccia Javascript (o tramite API), chiedendo di svolgere un’operazione su una determinata risorsa
• l’applicazione Rails riceve la richiesta e valuta il tipo di azione, se è particolarmente costosa e coinvolge operazioni su risorse a diversi livelli del file system (quindi non si limita al database dell’applicativo stesso) la mette in coda per essere eseguita da uno dei processi dedicati a questo tipologia di operazioni
• una volta messa in coda l’azione richiesta, non aspetta che essa venga completata, ma risponde all’utente immediatamente fornendo un feedback positivo e comunicando che l’operazione è in coda
• la coda, viene smaltita da un alto numero di processi che restano in attesa d’istruzioni. In media, queste operazioni richiedono pochi secondi, ma per una questione di usabilità è bene non tenere il browser dell’utente ‘appeso’ ad aspettare negando la possibilità di altre interazioni. Inoltre, vi sono operazioni che possono richiedere anche diversi minuti (cancellazioni di domini con un alto numero di email ad esempio). Per questo si è deciso di adottare questo tipo di approccio.

Il pannello con il quale i nostri clienti interagiscono, non è altro che un’applicazione JavaScript che i nostri server mandano alla prima richiesta ricevuta da quello specifico utente, il quale browser si occupa di eseguire. Dal momento della messa in esecuzione, è l’applicazione stessa che si prende carico di gestire ogni tipo d’interazione con le nostre API.

 

Questa è quella che viene chiamata una SPA (Single Page Application), ovvero quando il server manda una sola pagina HTML contenente del codice JavaScript che poi si occupa di generare i nuovi elementi HTML e di dialogare con il server, che invia solo dati. Le informazioni ricevute vengono utilizzate per comporre l’interfaccia da mostrare all’utente che l’ha richiesta.

 

In questo tipo di architettura si riduce notevolmente il lavoro del server, che non si occupa più di generare intere pagine in modo dinamico, ma semplicemente di restituire i dati richiesti. Il lavoro ‘sporco’ viene eseguito dal browser dell’utente. In questo modo ci si avvantaggia delle prestazioni base offerte dai device utilizzati per navigare il web negli ultimi anni (ben oltre superiori a quelle necessarie per supportare queste soluzioni).

 

Nei prossimi articoli faremo un approfondimento sulle migliorie tecniche riguardanti la nostra applicazione JavaScript, il pannello vero e proprio.