React per il frontend dei gestionali Laravel: SPA senza perdere il controllo del backend
Un gestionale complesso a volte chiede un frontend React, ma la SPA porta con sé costi che non tutti i progetti giustificano. Quando React ha senso su un backend Laravel e quando Livewire o Inertia bastano e avanzano: i confini dell'API, la gestione dello stato senza duplicare la logica di business, e i punti dove la SPA aggiunge complessità più che valore. Decisione di architettura frontend motivata dal caso reale, non dall'hype. Continua a leggere
Ultima modifica:
Il monolite PHP regge la maggior parte dei casi, ma per alcuni carichi un microservizio in Node.js e TypeScript è la scelta tecnica corretta: real-time, connessioni persistenti, I/O intensivo concorrente. Quando estrarre un servizio ha senso e quando frammenta l'architettura senza guadagno, i confini da rispettare, e come far convivere i due mondi senza duplicare logica. Decisione di architettura motivata, non moda dei microservizi. 
Non tutto si risolve nel framework PHP, e a volte la risposta giusta è affiancare Python invece di forzare lo stack. Dove Python ha l'ecosistema migliore: automazione, data processing, scripting di integrazione, task con librerie scientifiche o di scraping. Come farlo convivere con un backend PHP senza riscrivere l'applicazione, con i confini netti tra i due e i pattern di comunicazione affidabili. Pragmatismo multi-stack, non religione di linguaggio. 
I controller gonfi sono il debito tecnico più comune in Laravel, ma la cura non è astrarre tutto. Come applicare i principi SOLID in modo pragmatico: spostare la logica di business in un service layer, dove la separazione paga davvero e dove invece aggiunge solo indirezione. Refactoring concreto da un controller reale, con i tradeoff dichiarati: la testabilità che guadagni contro la complessità che introduci. 
Aggiungere il single sign-on a un prodotto che gira anche presso clienti senza identity provider non è mettere un flag: è progettare due forme del prodotto che convivono nello stesso codice. E siccome il flusso coinvolge due applicazioni, la modalità effettiva non è una configurazione ma un'intersezione, che va scoperta invece che assunta. Il pattern della negoziazione, il degrado direzionale, la macchina a cinque stati e come si collauda un prodotto che le ha tutte. 
C'è un momento, in ogni migrazione verso il single sign-on, in cui l'applicazione smette di avere la password dell'utente. Sembra un progresso e lo è, ma se quella password serviva anche ad accedere ai dati, in quell'istante hai silenziosamente rimosso il controllo di accesso e nessun test se ne accorge. Come ho ricostruito il recinto a livello applicativo, perché un solo livello non basta, come si enumera davvero la superficie da proteggere, e il buco cross-tenant che l'audit ha trovato. 
Il AI SDK first-party di Laravel porta text generation, tool-calling ed embeddings con uno switch di provider gestito da config. Fino a ieri lo si vendeva come comodità; dopo la sospensione di Fable 5 del 12 giugno 2026 è risk-mitigation: chi ha l'abstraction layer agnostico fa fallback in una riga quando un modello viene spento dall'alto, chi è cablato si ferma. Esempio concreto con un provider primario e un fallback, e cosa serve perché lo switch sia davvero indolore. 
Dopo la sospensione di Fable 5 del 12 giugno 2026, la domanda per chi sviluppa con l'AI non è più solo "quale modello" ma "cosa succede quando il modello sparisce". La risposta è architetturale: un abstraction layer provider-agnostic (Laravel AI SDK, LiteLLM), eval di portabilità che misurano la regressione cambiando modello, un fallback multi-provider o self-hosted, e un exit plan documentato. Non significa non usare i frontier model: significa progettarne la sostituibilità prima che serva. 
Per un RAG su dominio tecnico specialistico (vocabolario italiano, sigle proprietarie, convenzioni di settore), un dense bi-encoder single-vector generalista sbaglia spesso. Weaviate 1.30 porta multi-vector ColBERT in GA e 1.31 aggiunge MUVERA per ridurre il footprint. Setup completo: ingestion pipeline, configurazione schema Weaviate, retrieval con late interaction, benchmark accuracy su dataset tecnico italiano della mia sandbox. 
GPT-4 ha ~1.800 miliardi di parametri; il modello legge il prompt in quattro componenti: embedding lookup, multi-head self-attention, MLP, unembedding+softmax. L'attention fa parlare i token fra loro, l'MLP inietta fatti, il residual stream è un nastro che trasporta i vettori ricorsivamente per decine di transformer block. Capire questo rende prevedibili allucinazioni, dipendenza dal prompt, sensibilità all'ordine.