Pagina 2 di 2
Il backend è dove vive la logica di business, e la scelta del linguaggio è una decisione ingegneristica. PHP resta il mio strumento principale e regge la stragrande maggioranza dei casi, ma su alcuni problemi altri linguaggi lavorano meglio, e onestà tecnica vuole che si dica. Questa categoria raccoglie il ragionamento su quando e perché uscire dal monolinguaggio.
Molti articoli riguardano la scelta del linguaggio giusto per il pezzo giusto. Python come lingua franca dell'AI, con FastAPI a fare da orchestrator dei modelli davanti a un dominio Laravel o Symfony; Node.js e TypeScript dove serve streaming real-time a bassa latenza; Go come inference gateway quando carico e latenza pesano più della produttività; Rust per l'inference edge di modelli leggeri. Ogni carico va sullo strumento che lo regge meglio.
Altri parlano dei confini fra i servizi. Un'architettura poliglotta conserva il suo valore solo se i confini restano puliti: code asincrone con Kafka o RabbitMQ, WebSocket con Reverb, un BFF in Node davanti a più API legacy, server MCP stateless per l'integrazione con gli agenti AI. La disciplina sta nel tenere ogni servizio comprensibile e sostituibile, per non ritrovarsi con un groviglio distribuito più difficile del monolite di partenza.
Se stai progettando un backend che deve integrare più tecnologie, vedi lo sviluppo software con AI o i miei progetti PHP senior.
Il linguaggio giusto è quello che risolve il problema e che il team può mantenere. Tutto il resto è tifoseria.
L'invio di 50.000 email mensili da un giro promozionale bloccava la UX dell'applicazione per ore. Con Symfony Messenger e un transport RabbitMQ, ho separato il processo di business dalla sua esecuzione: le email partono in background, la UI risponde istantaneamente, i fallimenti vengono riprocessati automaticamente. Continua a leggere
Prima di Reverb, ogni progetto con WebSocket richiedeva Pusher (costoso) o un server Node.js separato da mantenere. Ho messo in produzione Reverb su un VPS Hetzner da 4 CPU per un'applicazione di collaborazione con 200 utenti simultanei. Zero problemi, zero costi aggiuntivi. Vi mostro il setup completo. Continua a leggere
Molti usano Redis in Laravel solo come cache di secondo livello. Su un'applicazione di prenotazioni con picchi di 500 richieste al secondo, ho sfruttato Redis Sorted Sets per la gestione delle priority queue, Pub/Sub per le notifiche real-time e un layer di session management con persistenza distribuita. Continua a leggere
La RFC 9562 (maggio 2024) raccomanda UUID v7 al posto di v1 per tutti i nuovi sistemi. In Laravel 12, il trait HasUuids genera UUID v7 di default - con timestamp a 48 bit nei primi byte, le insert su indici InnoDB B-tree tornano sequenziali. Percona documenta che UUID v4 causa fino a 500× più page split e tabelle 2× più grandi di chiavi sequenziali. Continua a leggere
Tool gratuiti che tornano utili:
Generatore UUID, Convertitore timestamp, JSON formatter, Generatore dati fake.
