Porting PowerApps → web con sql-proxy Node.js: middleware singleton veloce e affidabile sulla intranet aziendale

Contesto

La stessa azienda ha un ecosistema PowerApps maturo — sei applicazioni in produzione quotidiana coprono l'operatività commerciale e logistica: dashboard provvigioni agenti, creazione preventivi, picking di magazzino con barcode scanner, gestione giri di consegna con mappe, monitoraggio consegne real-time. Hanno funzionato per anni e ancora funzionano. Ma a un certo punto i limiti sono diventati evidenti: latenza di caricamento di qualche secondo su ogni transizione, UX rigida e faticosa da evolvere, dipendenza dal runtime PowerApps e dalla rete cloud, e un debug che richiede aprire l'IDE Power Platform invece del browser.

Sfida

Spostare le PowerApps critiche in web app che girano sulla intranet aziendale, con prestazioni migliori e piena controllabilità, senza perdere le integrazioni Dataverse (dove vivono dati strutturali come coordinate GPS destinazioni, scale premio, eventi), senza rompere i flussi Mexal (stampa etichette, modifica scadenze, aggiornamento contatti), e soprattutto senza chiedere agli operatori di cambiare abitudine — il capo magazzino che prima apriva una PowerApp deve aprire una pagina web che fa esattamente la stessa cosa, solo meglio.

Approccio

L'architettura che ho scelto ha un pezzo centrale forte — il sql-proxy — e un perimetro deliberatamente semplice attorno. Sei feature che fanno la differenza.

sql-proxy come singleton middleware Node.js

Un servizio Node.js + Express di circa 5.700 righe che gira come Windows Service sulla intranet aziendale (IP interno dedicato, porta 3100 HTTP e 3443 HTTPS) e parla con tutto quello che serve alle app: pool su SQL Server del gestionale, client Dataverse con OAuth2 Azure AD, routing verso Mexal WebAPI, invio email e SMS via Brevo, lettura/scrittura su PostgreSQL Neon e MySQL SiteGround. Oltre settanta endpoint REST esposti. L'idea è che tutte le integrazioni stiano in un unico posto, con un'unica API key, un unico log, un unico servizio da monitorare — invece di N client sparsi nelle N app.

App HTML single-page leggerissime come frontend

Invece di salire di stack con un framework pieno, ogni app migrata è un singolo file HTML con JavaScript vanilla che fa fetch() al proxy sulla rete locale. Zero bundler, zero build step, zero framework update quarterly. La più complessa — quella che ha sostituito Gestione_Giro_Clienti_R2 — è un HTML da quattromila righe con sei pagine interne (indice, email, piani di carico, calendario, liste di magazzino, analisi fabbisogno), e carica istantaneamente perché servita dal proxy stesso sulla intranet. Le sei app già in pensione: monitor consegne, picking primo livello, picking secondo livello, launcher con PIN, launcher ufficio, gestione giro.

Dual-write SQL + Dataverse per coesistere con le PowerApps sopravvissute

Durante la migrazione le due generazioni devono vedere gli stessi dati. Il proxy lo garantisce con dual-write esplicito: quando una app web salva un collo o una nota operativa, il proxy scrive prima su SQL Server (fonte di verità operativa) e poi su Dataverse (fonte condivisa con le PowerApps ancora attive). Se una delle due scritture fallisce, il proxy logga la discrepanza e la seconda diventa recuperabile. Nessuno fra gli utenti si accorge che sta usando un sistema di transizione.

Pool, cache e retry intelligente: ogni scelta elimina un modo di fallire

Il proxy non è una semplice pass-through. Pool mssql con connessioni riutilizzabili, cache dei token OAuth Dataverse con refresh automatico 60 secondi prima della scadenza (elimina il giro di login ripetuti), batch delay di 500 ms tra chiamate Dataverse per non incappare nel throttling del tenant, fetch con retry automatico fino a tre tentativi su HTTP 429, timeout dedicati per ogni upstream (Mexal 30 s, Dataverse 15 s, proxy PHP 10 s). Ogni dettaglio è lì perché in PowerApps quel modo di fallire esisteva e faceva perdere tempo.

Routing Mexal integrato per le operazioni gestionale

Quattro endpoint dedicati inoltrano a Mexal le azioni operative più usate: stampa etichetta spedizione in formato ZPL (collage remoto), elenco e download dei documenti da archivio Docuvision, modifica della data di scadenza di un ordine cliente, aggiornamento dei contatti di spedizione. Dietro c'è il proxy Mexal PHP su hosting esterno che già gestisce credenziali e certificati self-signed — il sql-proxy lo chiama come client e centralizza così anche l'accesso al gestionale.

Deploy versioning delle app HTML dentro il proxy stesso

La cosa che preferisco di questa architettura. Il proxy espone endpoint che deployano le app che ha sopra: POST /api/apps/:app/:file/deploy pubblica una nuova versione di un file HTML con backup automatico, GET /api/apps/:app/:file/history lista tutte le revisioni, POST /rollback/:revision torna istantaneamente a una versione precedente, GET /api/apps/status dà lo stato di tutte le app. Niente git push, niente pipeline CI/CD, niente FTP: modifico un HTML, lo posto al proxy, in meno di un secondo è live — e se ho rotto qualcosa, torno indietro con una singola chiamata. È il deploy più pragmatico che abbia mai messo in piedi.

Risultato

Sei PowerApps operative già sostituite da app web più reattive, cinque ancora in pipeline (dashboard provvigioni, monitoraggio ordini, scale premio, gestione eventi, viaggi premio). L'operatore di magazzino che prima aspettava tre-quattro secondi di caricamento ora apre una pagina web che risponde in millisecondi. L'agente che consulta la dashboard delle sue consegne vede lo stato aggiornato senza refresh manuale. Il vero oggetto di valore non è il frontend — le app HTML sono volutamente semplici — è il proxy: è dove vivono pool, cache, retry, dual-write, deploy versioning, cioè tutte le garanzie di prestazione e affidabilità che PowerApps non riusciva a dare per design. È anche il tipo di migrazione che conferma una convinzione che porto avanti da anni: scegliere lo stack giusto conta più della modernità nominale. Un servizio Node.js scritto bene con HTML vanilla sopra sta battendo un ambiente low-code moderno, e lo sta facendo sullo stesso hardware.