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
Fonctionne sur et construit avec
  • Node.js
  • Express
  • npm
  • NGINX
  • MySQL
  • PostgreSQL
  • Redis

Ce que nous développons en Node

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

  1. 01

    Express

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

    API et back-ends
  2. 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
  3. 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
  4. 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
  5. 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.

La boucle d'événements de Node.js, simplifiée
  1. Votre code s'exécute sur la pile d'appels, une fonction à la fois.
  2. 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.
  3. Une fois le travail fini, son callback attend dans la file des tâches.
  4. Avant la tâche suivante, tous les callbacks de promesses de la file des microtâches s'exécutent.
  5. 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.

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
  1. 01

    Récupérer et installer

    git pull && npm ci

    Les versions exactes du fichier de verrouillage, rien de plus récent par surprise.

  2. 02

    Compiler

    npm run build

    Le TypeScript et les ressources sont compilés avant que quoi que ce soit ne redémarre.

  3. 03

    Démarrer à côté de l'ancienne

    pm2 reload app

    La nouvelle version démarre à côté de celle qui sert encore.

  4. 04

    Attendre qu'elle soit prête

    wait_ready: true

    Elle doit répondre à son contrôle de santé avant de recevoir un visiteur.

  5. 05

    Prendre le trafic

    cluster → new workers

    Les nouvelles connexions vont à la nouvelle version.

  6. 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.

Quatre chiffres derrière chaque service Node

Chaque chiffre vient de la documentation de Node.js, de libuv ou de WebSocket, pas de nos propres mesures : vous pouvez le vérifier à la source.

  • 30mois

    de correctifs pour chaque version LTS de Node.js : 12 mois de support actif, puis 18 mois de maintenance.

    Source : Node.js Release Working Group

  • 4threads

    dans le pool libuv par défaut, pour les fichiers, le DNS et le hachage. Un réglage peut porter le pool jusqu'à 1024.

    Source : documentation de libuv

  • 101code d'état

    est la réponse d'un serveur à une demande de passage en WebSocket : Switching Protocols.

    Source : RFC 6455

  • 443port

    est le port par défaut d'un WebSocket sécurisé, le même que HTTPS : l'unique entrée Nginx porte donc les deux.

    Source : RFC 6455

Ce qu'un service Node sait faire, en un coup d'œil

Les capacités en quatre groupes : ce qu'il sert, ce qu'il délègue, où il garde ses données et comment il reste en ligne.

Construire et servir

  • API HTTP et REST

    Express seul, ou NestJS, qui s'appuie par défaut sur Express et peut utiliser Fastify à la place.

  • TypeScript

    Des contrats typés entre les modules, vérifiés à la compilation, avant que quoi que ce soit ne redémarre.

  • Rendu côté serveur

    Next.js et Nuxt génèrent les pages sur le serveur : moteurs de recherche et premiers visiteurs reçoivent un HTML terminé.

  • Temps réel

    Socket.IO démarre en HTTP simple puis passe en WebSocket ; il se connecte donc même là où un proxy bloque les WebSockets, et se reconnecte tout seul.

Déléguer le travail lourd

  • Worker threads

    Le JavaScript gourmand en calcul tourne dans ses propres threads et laisse libre la boucle des requêtes. Ils aident pour le calcul, pas pour l'attente d'E/S.

  • Files d'attente sur Redis

    Les tâches lentes sont mises en file et terminées en arrière-plan, hors de la requête du visiteur.

  • Tâches planifiées

    Des tâches qui s'exécutent à heures fixes au lieu d'attendre qu'un visiteur les déclenche.

  • Mode cluster

    PM2 lance un worker par cœur : un service très sollicité exploite toute la machine et non un seul thread.

Garder les données proches

  • MySQL et PostgreSQL

    Le service Node et le site PHP peuvent lire la même base de données.

  • Redis

    Sessions, cache et files d'attente en mémoire, partagés par les deux environnements.

  • Fichiers statiques

    Nginx sert CSS, images et téléchargements directement depuis le disque ; Node ne traite que ce qui demande du code.

  • Un seul plan de sauvegarde

    Un seul plan de sauvegarde couvre le site PHP et le service Node ensemble.

Rester en ligne et à jour

  • Redémarrage en cas de panne

    PM2, ou une unité systemd quand un seul processus suffit, relance un processus tombé.

  • Rechargement sans coupure

    Une nouvelle version réussit son contrôle de santé avant de recevoir du trafic.

  • Journaux et alertes

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

  • LTS et audits

    Une version Node à support long terme, npm audit à chaque livraison et des secrets gardés hors du code.

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

Services liés

Laravel Des applications Laravel avec files d’attente, tâches planifiées et déploiements sans coupure.Bases de données MySQL, MariaDB, PostgreSQL, Redis, MongoDB et d’autres : réglées, répliquées, restaurations testées.Serveurs dédiés Une machine entière, provisionnée en quelques heures, gérée par la même équipe.Hébergement infogéré Nginx et LiteSpeed sur NVMe, réglés site par site, surveillés 24h/24.
MickeyRépond en quelques secondes