Applications Node.js

Node.js, développé et exploité à côté de votre PHP.

Nous développons en Node des API, des sites rendus côté serveur, des services temps réel et des workers, et nous les faisons tourner sur les mêmes serveurs que vos sites PHP, derrière un seul Nginx.

Demander un devis Serveurs dédiés

Ce que nous développons en Node

Cinq types de travaux, chacun ici parce que Node lui convient.

01
Express

Des API et des back-ends petits et directs : quelques routes, des middlewares clairs, rien de caché.
API et back-ends
02
NestJS

Des services plus grands, avec modules, injection de dépendances et contrats typés en TypeScript, pour un code qu'une équipe fera grandir pendant des années.
Services structurés
03
Next.js · Nuxt

Le rendu côté serveur pour React et Vue : les pages arrivent prêtes pour les moteurs de recherche et un premier affichage rapide, puis se comportent comme une application.
Sites rendus côté serveur
04
Socket.IO · WebSockets

Chat, notifications, tableaux de bord en direct et suivi qui se mettent à jour dès que quelque chose change, sur une seule connexion ouverte.
Temps réel
05
Workers et files d'attente

Tâches de fond, tâches planifiées et consommateurs de files sur Redis, qui gardent le travail lent hors de la requête.
Travail en arrière-plan

Pourquoi Node sait si bien attendre

Un processus Node exécute votre JavaScript sur un seul thread et confie l'attente - disque, réseau, base de données - au système. C'est ainsi qu'un seul processus garde de nombreuses connexions ouvertes à la fois.

1Pile d'appels

JSON.parse(body)
handler(req, res)
(main)

un thread, une fonction à la fois

Boucle d'événementslibuv

5

4File des microtâches

promise.then()
await
queueMicrotask()

vidée avant la tâche suivante

3File des tâches

setTimeout()
setImmediate()
socket.on('data')

des callbacks qui attendent leur tour

2Pool de threads libuvquatre threads par défaut

fs.readFile()
dns.lookup()
crypto.pbkdf2()
zlib.gzip()

Système d'exploitation epoll · kqueue surveille chaque socket réseau

La boucle d'événements de Node.js, simplifiée

Votre code s'exécute sur la pile d'appels, une fonction à la fois.
Le travail lent quitte le thread : fichiers, DNS et hachage partent vers le pool libuv, et les sockets sont surveillés par le système d'exploitation.
Une fois le travail fini, son callback attend dans la file des tâches.
Avant la tâche suivante, tous les callbacks de promesses de la file des microtâches s'exécutent.
La boucle parcourt ses phases et prend la tâche suivante.

PHP et Node sur un seul serveur

Nginx répond à chaque requête et envoie chaque chemin au processus qui en a la charge. Votre site PHP et votre service Node partagent la machine, la base de données et le certificat - pas la mémoire l'un de l'autre.

https://example.com //checkout.php/api//socket.io/

Nginxune seule entrée : TLS, routage, fichiers statiques

/css//images/sendfile
/*.phpphp-fpm
/api//socket.io/node :3000

server {
    listen 443 ssl;
    server_name example.com;

    location / {
        try_files $uri /index.php?$query_string;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
    location /api/ {
        proxy_pass http://127.0.0.1:3000;
    }
    location /socket.io/ {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

fastcgi

Côté PHP

php-fpm: pool www

Un pool de workers. Chaque requête commence proprement et se termine proprement.

Laravel · WordPress · WooCommerce

proxy_pass :3000

Côté Node

pm2: app (cluster)

Des processus qui tournent en continu. Un seul d'entre eux tient de nombreuses connexions ouvertes.

Express · NestJS · Next.js · Socket.IO

Partagé par les deux

MySQL · PostgreSQL
Redis sessions, cache, files d'attente
un seul certificat TLS
un seul plan de sauvegarde

Exemple d'un serveur qui fait tourner les deux

Lequel pour quel travail

Nous développons avec les deux : la réponse vient donc du travail à faire, pas d'une habitude.

Choisissez PHP quand

Le site est surtout fait de pages, de formulaires et d'une administration : boutiques, sites de contenu, systèmes de gestion.
Vous voulez WordPress, WooCommerce ou Laravel, et tout ce qui existe déjà pour eux.
Chaque requête est indépendante et se termine vite.
Les personnes qui le maintiendront connaissent déjà PHP.

Choisissez Node quand

Les connexions restent ouvertes : chat, tableaux de bord en direct, notifications, suivi.
Des pages React ou Vue sont rendues sur le serveur avec Next.js ou Nuxt.
Le service attend surtout d'autres API et fait transiter des flux de données.
Un seul langage dans le navigateur et sur le serveur aide votre équipe.

Souvent, la réponse est : les deux

PHP garde le site, la boutique et l'administration ; un petit service Node prend en charge la partie temps réel à côté. Les deux lisent la même base de données et se trouvent derrière le même Nginx.

Des mises en production sans trou

Une nouvelle version démarre à côté de l'ancienne, prouve qu'elle est en bonne santé, et seulement ensuite prend le trafic. Les anciens workers terminent les requêtes qu'ils ont déjà avant de s'arrêter.

Visiteurs servis
Version actuelle
Nouvelle version

01
Récupérer et installer
git pull && npm ci
Les versions exactes du fichier de verrouillage, rien de plus récent par surprise.
02
Compiler
npm run build
Le TypeScript et les ressources sont compilés avant que quoi que ce soit ne redémarre.
03
Démarrer à côté de l'ancienne
pm2 reload app
La nouvelle version démarre à côté de celle qui sert encore.
04
Attendre qu'elle soit prête
wait_ready: true
Elle doit répondre à son contrôle de santé avant de recevoir un visiteur.
05
Prendre le trafic
cluster → new workers
Les nouvelles connexions vont à la nouvelle version.
06
Vider l'ancienne
SIGINT → server.close()
Les anciens workers terminent les requêtes en cours, puis s'arrêtent.

Si la nouvelle version échoue à son contrôle de santé, elle ne reçoit jamais de trafic : l'ancienne continue simplement de servir.

Le serveur autour du code

Ce qui fait tenir un service Node est écrit sur le serveur, dans des fichiers que nous maintenons et que vous pouvez lire.

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

Proxy inverse

TLS, compression, fichiers statiques en cache et passage en WebSocket, devant chaque processus.
/srv/app/ecosystem.config.js

Gestionnaire de processus

PM2 maintient le processus en vie, le redémarre s'il plante et utilise chaque cœur en mode cluster. Là où un seul processus suffit, une unité systemd fait le même travail.
/srv/app/.env (0600)

Environnement et secrets

Les clés et les mots de passe vivent hors du code et hors de git, lisibles seulement par l'utilisateur propre à l'application.
/srv/app/package-lock.json

Audit des dépendances

npm audit à chaque mise en production ; les mises à jour sont lues et testées avant d'atteindre la production.
/srv/app/.nvmrc

Mises à niveau entre versions LTS de Node

L'application tourne sur une version à support long terme, et nous la passons à la suivante avant que l'ancienne ne quitte le support.
/var/log/app/

Journaux et supervision

Des journaux structurés, avec rotation, et une alerte quand le processus redémarre, que la mémoire grimpe ou que les erreurs augmentent.

Dites-nous ce que votre application Node doit faire

Un nouveau service, un site Next.js, ou une application qui tourne déjà quelque part et mérite un vrai foyer. Nous l'examinons et établissons un devis après un court échange.

Demander un devis Serveurs dédiés