La tecnologia di E-Motion Web: Hydra, WordPress e i criteri con cui scegliamo
E-Motion Web costruisce i siti dei suoi clienti su due piattaforme: Hydra, il CMS enterprise proprietario sviluppato internamente, e WordPress con tema custom. Aver progettato da zero due generazioni di CMS — Logos prima, Hydra oggi — è ciò che ci permette di scegliere fra le due con cognizione di causa, e di lavorare in WordPress senza compromessi.
Su quali piattaforme lavoriamo
E-Motion Web sviluppa i siti dei suoi clienti su due piattaforme: Hydra, il CMS enterprise proprietario in esercizio dal 2022, e WordPress con tema custom, scritto da zero e senza page builder. Non è una gerarchia e nessuna delle due è un ripiego: sono strumenti con profili diversi, e la scelta si fa progetto per progetto sui sette criteri descritti più avanti.
Hydra è un'architettura cloud-native e headless che disaccoppia la gestione dei contenuti dalla loro presentazione, distribuisce ogni sito sull'edge globale e integra nativamente le funzioni che altrove richiedono estensioni di terzi. Dà il meglio dove contano prestazioni sotto stress, scalabilità e requisiti di conformità.
WordPress con tema custom è la piattaforma più diffusa al mondo, sviluppata da noi con tema scritto su misura, plugin ridotti al minimo e verificati, prestazioni e sicurezza presidiate. Dà il meglio dove servono rapidità nel modellare contenuti con molti attributi tecnici, l'ampiezza di un ecosistema maturo e piena portabilità del sito.
Come scegliamo: sette criteri a confronto
Su un nuovo progetto la scelta della piattaforma si gioca su sette criteri.
| Criterio | WordPress con tema custom | Hydra |
|---|---|---|
| Tipo di progetto | Siti vetrina e corporate, siti editoriali, cataloghi tecnici di prodotto. |
Siti corporate complessi, portali, aree riservate, progetti con picchi di traffico o obblighi normativi. |
| Modellazione dei contenuti | Rapida: tipi di contenuto e attributi tipizzati si definiscono in poche ore, ideale per schede tecniche articolate. |
Oggi più lenta: modellare classi e attributi con valore semantico specifico richiede sviluppo dedicato. |
| Prestazioni e distribuzione | Ottime, con caching e CDN da assemblare e configurare progetto per progetto. |
Estreme e native: server-side caching e deployment worldwide sono parte dello stack, non componenti aggiunti. |
| Funzioni ed estensioni | Ecosistema vastissimo: quasi ogni funzione esiste già come plugin di terzi, da selezionare e mantenere. |
Nessun plugin: dati strutturati schema.org, dashboard SEO, form builder e SMTP esterno sono integrati nella piattaforma. |
| Controllo del design responsive | Media query scritte a mano nel tema, verificate a valle sui dispositivi. |
Fine tuning su sei breakpoint con anteprima in fase di progettazione. |
| Portabilità | Alta: il sito è migrabile ad altri fornitori. |
Portabilità dei contenuti alta, UI legata all'agenzia che sviluppa e mantiene la piattaforma. |
| Investimento iniziale | Contenuto rispetto a una piattaforma enterprise. |
Superiore, giustificato da prestazioni, conformità o scala. |
I due criteri che decidono più spesso sono il secondo e il terzo: quanto è articolata la modellazione dei contenuti da costruire, e quanto contano prestazioni e scalabilità sotto stress. La domanda con cui iniziamo ogni valutazione non è "quale piattaforma preferite", ma "cosa deve fare questo sito nei prossimi cinque anni, e chi ci metterà le mani".
Perché aver scritto due CMS ci rende più competenti anche in WordPress
Progettare un CMS da zero significa aver risolto in prima persona ogni problema che WordPress risolve con un plugin: la modellazione dei contenuti, la cache, la composizione delle pagine, il controllo degli accessi, la distribuzione geografica, i dati strutturati, la gestione dei form, il recapito delle email. Chi ha scritto quel codice sa cosa fa un plugin quando lo installi, cosa costa in prestazioni e in superficie di rischio, e quali di quelle funzioni si possono scrivere direttamente nel tema.
È la differenza fra assemblare e progettare. La maggior parte delle agenzie che lavorano in WordPress compone soluzioni scegliendo fra estensioni esistenti; noi possiamo valutarle sapendo come sono fatte dentro, perché l'equivalente lo abbiamo costruito. Per questo il nostro WordPress ha tema scritto a mano, nessun page builder e pochissimi plugin: non è un vezzo, è ciò che sa fare chi viene dallo sviluppo full-stack.
E-Motion Web lavora dal 2001, e il suo fondatore Enrico Maria Parizzi costruisce siti dal 1996: venticinque anni di agenzia più i cinque che li hanno preceduti fanno trent'anni di sviluppo web continuativo, e due generazioni di piattaforma proprietaria messe in esercizio su progetti reali.
Logos, la prima generazione
La prima piattaforma proprietaria dell'agenzia si chiamava Logos ed è stata in esercizio dal 2010 al 2022. Oggi è legacy: nessun nuovo progetto ci viene sviluppato, e i siti che ancora vi girano sono in migrazione o in manutenzione.
Logos era un'applicazione ASP.NET costruita su un'architettura a livelli — interfaccia, logica di business e accesso ai dati nettamente separati — appoggiata a un database relazionale Microsoft SQL Server, fortemente normalizzato e interrogato tramite stored procedure. I dataset estratti venivano mantenuti in cache lato server per comporre le pagine, generate a ogni richiesta. Ogni sito girava su un server dedicato presso un data center italiano.
Il modello rifletteva il suo tempo, ed era solido. Ma aveva due conseguenze. Ogni progetto cliente era un'applicazione a sé, derivata da un fork del repository di base: un miglioramento applicato al codice base andava ridistribuito progetto per progetto, con un deployment separato per ciascun sito. E il front-end si costruiva adattando schemi predefiniti tramite programmazione manuale: ogni layout passava dalle mani di uno sviluppatore.
Hydra nasce per superare entrambi i limiti con un cambio di paradigma. Dove Logos aveva un'applicazione per cliente, Hydra è una piattaforma unica: un solo codice e un solo database servono tutti i clienti, e ogni personalizzazione vive come layer di parametri e configurazioni memorizzate, non come variante di codice. Un miglioramento è immediatamente disponibile a tutti, senza redistribuzioni. E dove Logos richiedeva uno sviluppatore per ogni intervento sul front-end, Hydra mette a disposizione un editor visuale. A questo si aggiunge il salto infrastrutturale — dalla generazione delle pagine a ogni richiesta su un server unico, alla pre-generazione distribuita sull'edge globale — che è la radice delle prestazioni di Hydra.
Ciò che non è cambiato, in venticinque anni e due generazioni, è la competenza che le sostiene: la stessa che oggi applichiamo anche ai progetti WordPress. E, per i siti costruiti su Hydra, la scelta che i dati dei clienti restino su infrastruttura italiana — ieri un data center nazionale, oggi la region di Milano di AWS.
Domande frequenti
La scelta si gioca su sette criteri: tipo e complessità del progetto, velocità di modellazione dei contenuti, requisiti di prestazioni e distribuzione, funzioni ed estensioni necessarie, controllo del design responsive, portabilità e budget. Hydra è la scelta quando contano prestazioni e affidabilità: server-side caching e distribuzione worldwide sono parte dello stack, le funzioni essenziali — dati strutturati schema.org, dashboard SEO, form builder, invio email tramite SMTP esterno — sono integrate nella piattaforma senza un solo plugin di terzi, e il design si rifinisce su sei breakpoint con anteprima già in fase di progettazione. WordPress con tema custom è la scelta quando serve modellare rapidamente contenuti con attributi tecnici articolati — un catalogo di motori elettrici con tutte le loro caratteristiche fisico-tecniche, per esempio — quando l'ampiezza dell'ecosistema accorcia i tempi, o quando il cliente vuole piena portabilità del sito. È il criterio su cui oggi WordPress è più veloce di Hydra, e lo diciamo perché la piattaforma la scegliamo sul progetto, non sul nostro interesse.
Perché la piattaforma giusta dipende dal progetto, non dal fornitore: proporne una sola significherebbe adattare il progetto allo strumento invece del contrario. Hydra dà il meglio dove contano prestazioni sotto stress, distribuzione globale e integrazione nativa delle funzioni; WordPress è più rapido quando serve modellare contenuti con molti attributi tecnici, quando l'ampiezza dell'ecosistema accorcia i tempi di sviluppo o quando il cliente vuole piena portabilità del sito. Aver progettato due CMS da zero — Logos dal 2010 al 2022, Hydra dal 2022 — ci mette nella condizione di riconoscere quale dei due profili serve, e di sviluppare in WordPress con la stessa disciplina con cui scriviamo la nostra piattaforma: tema su misura, nessun page builder, plugin ridotti al minimo e verificati.
Logos era il CMS proprietario di prima generazione di E-Motion Web, in esercizio dal 2010 al 2022 e oggi legacy. Era costruito su architettura ASP.NET a livelli con database Microsoft SQL Server, e ogni sito cliente era realizzato come applicazione dedicata, ospitata su server in Italia. Nel 2022 è stato sostituito da Hydra, la seconda generazione, cloud-native e headless. Su Logos non vengono sviluppati nuovi progetti.
Per superare due limiti del modello di Logos. Primo: ogni sito era un'applicazione separata derivata dal codice base, quindi ogni aggiornamento richiedeva un deployment progetto per progetto; Hydra è invece una piattaforma unica multi-tenant, dove un solo codice serve tutti i clienti e le personalizzazioni sono parametri memorizzati, immediatamente aggiornabili per tutti. Secondo: in Logos il front-end si costruiva con programmazione manuale su schemi fissi, mentre Hydra offre un editor visuale con anteprima su sei breakpoint. A questi si aggiunge il salto di prestazioni dato dalla distribuzione sull'edge globale.
Parliamone
Se vuoi capire quale infrastruttura è giusta per il tuo progetto, chiamaci in videocall: partiamo da requisiti, traffico atteso e vincoli tecnici.