Applicazioni Node.js

Node.js, sviluppato e gestito accanto al tuo PHP.

Sviluppiamo in Node API, siti renderizzati lato server, servizi in tempo reale e worker, e li facciamo girare sugli stessi server dei tuoi siti PHP, dietro un unico Nginx.

Richiedi un preventivo Server dedicati
Funziona su e costruito con
  • Node.js
  • Express
  • npm
  • NGINX
  • MySQL
  • PostgreSQL
  • Redis

Cosa sviluppiamo in Node

Cinque tipi di lavoro, ognuno qui perché Node gli si addice.

  1. 01

    Express

    API e back-end piccoli e diretti: poche route, middleware chiari, niente di nascosto.

    API e back-end
  2. 02

    NestJS

    Servizi più grandi con moduli, dependency injection e contratti tipizzati in TypeScript, per codice che un team farà crescere per anni.

    Servizi strutturati
  3. 03

    Next.js · Nuxt

    Rendering lato server per React e Vue: le pagine arrivano pronte per i motori di ricerca e per una prima visualizzazione rapida, poi si comportano come un'app.

    Siti renderizzati lato server
  4. 04

    Socket.IO · WebSockets

    Chat, notifiche, dashboard dal vivo e tracciamento che si aggiornano nell'istante in cui qualcosa cambia, su un'unica connessione aperta.

    Tempo reale
  5. 05

    Worker e code

    Job in background, attività pianificate e consumer di code su Redis che tengono il lavoro lento fuori dalla richiesta.

    Lavoro in background

Perché Node sa aspettare così bene

Un processo Node esegue il tuo JavaScript su un solo thread e affida l'attesa - disco, rete, database - al sistema. È così che un solo processo tiene aperte molte connessioni contemporaneamente.

L'event loop di Node.js, semplificato
  1. Il tuo codice gira sulla call stack, una funzione alla volta.
  2. Il lavoro lento lascia il thread: file, DNS e hashing vanno al pool di libuv, mentre i socket li sorveglia il sistema operativo.
  3. Quando il lavoro è finito, la sua callback attende nella coda dei task.
  4. Prima del task successivo vengono eseguite tutte le callback delle promise nella coda dei microtask.
  5. Il loop attraversa le sue fasi e prende il task successivo.

PHP e Node su un solo server

Nginx risponde a ogni richiesta e manda ogni percorso al processo che lo gestisce. Il tuo sito PHP e il tuo servizio Node condividono la macchina, il database e il certificato - non la memoria l'uno dell'altro.

Esempio di un server che li fa girare entrambi

Quale per quale lavoro

Sviluppiamo con entrambi, quindi la risposta viene dal lavoro, non da un'abitudine.

Scegli PHP quando

  • Il sito è fatto soprattutto di pagine, moduli e un pannello di amministrazione: negozi, siti di contenuti, gestionali.
  • Vuoi WordPress, WooCommerce o Laravel e tutto ciò che esiste già per loro.
  • Ogni richiesta è indipendente e finisce in fretta.
  • Le persone che lo manterranno conoscono già PHP.

Scegli Node quando

  • Le connessioni restano aperte: chat, dashboard dal vivo, notifiche, tracciamento.
  • Le pagine React o Vue vengono renderizzate sul server con Next.js o Nuxt.
  • Il servizio passa gran parte del tempo ad attendere altre API e a far scorrere flussi di dati.
  • Un solo linguaggio nel browser e sul server aiuta il tuo team.

Spesso la risposta è: entrambi

PHP tiene il sito, il negozio e il pannello; un piccolo servizio Node accanto si occupa della parte in tempo reale. Entrambi leggono lo stesso database e stanno dietro lo stesso Nginx.

Rilasci senza buchi

Una nuova versione parte accanto alla vecchia, dimostra di essere in salute e solo allora prende il traffico. I vecchi worker completano le richieste che hanno già prima di fermarsi.

  • Visitatori serviti
  • Versione attuale
  • Nuova versione
  1. 01

    Scarica e installa

    git pull && npm ci

    Le versioni esatte del lockfile, niente di più recente a sorpresa.

  2. 02

    Compila

    npm run build

    TypeScript e asset vengono compilati prima che qualcosa si riavvii.

  3. 03

    Avvia accanto alla vecchia

    pm2 reload app

    La nuova versione si avvia accanto a quella che sta ancora servendo.

  4. 04

    Attendi che sia pronta

    wait_ready: true

    Deve superare il suo health check prima di ricevere un visitatore.

  5. 05

    Prendi il traffico

    cluster → new workers

    Le nuove connessioni vanno alla nuova versione.

  6. 06

    Svuota la vecchia

    SIGINT → server.close()

    I vecchi worker completano le richieste in corso, poi si chiudono.

Se la nuova versione non supera il suo health check, non riceve mai traffico: la vecchia continua semplicemente a servire.

Il server attorno al codice

Ciò che tiene in piedi un servizio Node è scritto sul server, in file che manteniamo noi e che puoi leggere anche tu.

  • /etc/nginx/sites-enabled/app.conf

    Reverse proxy

    TLS, compressione, file statici in cache e upgrade a WebSocket, davanti a ogni processo.

  • /srv/app/ecosystem.config.js

    Gestore dei processi

    PM2 tiene vivo il processo, lo riavvia se va in crash e usa ogni core in modalità cluster. Dove basta un solo processo, una unit systemd fa lo stesso lavoro.

  • /srv/app/.env (0600)

    Ambiente e segreti

    Chiavi e password stanno fuori dal codice e fuori da git, leggibili solo dall'utente proprio dell'applicazione.

  • /srv/app/package-lock.json

    Audit delle dipendenze

    npm audit a ogni rilascio; gli aggiornamenti vengono letti e testati prima di arrivare in produzione.

  • /srv/app/.nvmrc

    Aggiornamenti tra versioni LTS di Node

    L'app gira su una versione a supporto a lungo termine, e la portiamo alla successiva prima che la vecchia esca dal supporto.

  • /var/log/app/

    Log e monitoraggio

    Log strutturati e ruotati, con un avviso quando il processo si riavvia, la memoria sale o gli errori aumentano.

Quattro numeri dietro ogni servizio Node

Ogni cifra viene dalla documentazione di Node.js, libuv o WebSocket e non da nostre misurazioni, così potete verificarla alla fonte.

  • 30mesi

    di correzioni per ogni versione LTS di Node.js: 12 mesi di supporto attivo, poi 18 di manutenzione.

    Fonte: Node.js Release Working Group

  • 4thread

    nel pool di libuv per impostazione predefinita, per file, DNS e hashing. Un'impostazione può portare il pool fino a 1024.

    Fonte: documentazione di libuv

  • 101codice di stato

    è la risposta con cui un server accetta di passare una richiesta a WebSocket: Switching Protocols.

    Fonte: RFC 6455

  • 443porta

    è la porta a cui si connette per impostazione predefinita un WebSocket sicuro, la stessa di HTTPS, quindi l'unico ingresso Nginx porta entrambi.

    Fonte: RFC 6455

Cosa può fare un servizio Node, a colpo d'occhio

Le capacità in quattro gruppi: cosa serve, cosa delega, dove tiene i dati e come resta in piedi.

Costruire e servire

  • API HTTP e REST

    Express da solo, oppure NestJS, che poggia su Express per impostazione predefinita e può usare Fastify al suo posto.

  • TypeScript

    Contratti tipizzati tra i moduli, verificati alla compilazione, prima che qualcosa si riavvii.

  • Rendering lato server

    Next.js e Nuxt generano le pagine sul server, così motori di ricerca e nuovi visitatori ricevono HTML già pronto.

  • Tempo reale

    Socket.IO parte con HTTP semplice e passa a WebSocket, quindi si connette anche dove un proxy blocca i WebSocket, e si riconnette da solo.

Delegare il lavoro pesante

  • Worker thread

    Il JavaScript pesante per il processore gira in thread propri e lascia libero il ciclo delle richieste. Aiutano nel calcolo, non nell'attesa di I/O.

  • Code su Redis

    I lavori lenti vengono messi in coda e completati in background, lontano dalla richiesta del visitatore.

  • Attività pianificate

    Lavori che partono a orari stabiliti invece di aspettare che un visitatore li avvii.

  • Modalità cluster

    PM2 avvia un worker per core, così un servizio molto usato sfrutta l'intera macchina e non un solo thread.

Dati vicini

  • MySQL e PostgreSQL

    Il servizio Node e il sito PHP possono leggere lo stesso database.

  • Redis

    Sessioni, cache e code in memoria, condivise da entrambi gli ambienti.

  • File statici

    Nginx serve CSS, immagini e download direttamente dal disco, e Node gestisce solo ciò che richiede codice.

  • Un solo piano di backup

    Un solo piano di backup copre insieme il sito PHP e il servizio Node.

Restare attivi e aggiornati

  • Riavvio in caso di guasto

    PM2, o un'unità systemd dove basta un solo processo, riporta in vita un processo caduto.

  • Ricarica senza interruzioni

    Una nuova versione supera il controllo di salute prima di ricevere traffico.

  • Log e avvisi

    Log strutturati e ruotati, e un avviso quando il processo si riavvia, la memoria sale o gli errori aumentano.

  • LTS e audit

    Una versione Node a supporto a lungo termine, npm audit a ogni rilascio e segreti tenuti fuori dal codice.

Raccontaci cosa deve fare la tua app Node

Un nuovo servizio, un sito Next.js o un'app che gira già da qualche parte e ha bisogno di una casa come si deve. La esaminiamo e ti facciamo un preventivo dopo una breve conversazione.

Richiedi un preventivo Server dedicati

Servizi correlati

Laravel Applicazioni Laravel con code, pianificazioni e rilasci che non fermano il sito.Database MySQL, MariaDB, PostgreSQL, Redis, MongoDB e altri: messi a punto, replicati, ripristini provati.Server dedicati Una macchina intera, pronta in poche ore, gestita dalla stessa squadra.Hosting gestito Nginx e LiteSpeed su NVMe, calibrati sito per sito, sorvegliati giorno e notte.
MickeyRisponde in pochi secondi