Node.js-Anwendungen

Node.js, entwickelt und betrieben neben Ihrem PHP.

Wir bauen APIs, serverseitig gerenderte Websites, Echtzeit-Services und Worker in Node und betreiben sie auf denselben Servern wie Ihre PHP-Websites, hinter einem Nginx.

Angebot anfordern Dedizierte Server

Was wir in Node bauen

Fünf Arten von Arbeit, jede davon hier, weil Node zu ihr passt.

01
Express

Kleine, direkte APIs und Backends: wenige Routen, klare Middleware, nichts Verstecktes.
APIs und Backends
02
NestJS

Größere Services mit Modulen, Dependency Injection und typisierten Schnittstellen in TypeScript, für Code, den ein Team über Jahre weiterentwickelt.
Strukturierte Services
03
Next.js · Nuxt

Serverseitiges Rendering für React und Vue: Seiten kommen fertig für Suchmaschinen und eine schnelle erste Ansicht an und verhalten sich danach wie eine App.
Serverseitig gerenderte Websites
04
Socket.IO · WebSockets

Chat, Benachrichtigungen, Live-Dashboards und Tracking, die sich in dem Moment aktualisieren, in dem sich etwas ändert - über eine einzige offene Verbindung.
Echtzeit
05
Worker und Queues

Hintergrundjobs, geplante Aufgaben und Queue-Consumer auf Redis, die langsame Arbeit aus der Anfrage heraushalten.
Hintergrundarbeit

Warum Node gut im Warten ist

Ein Node-Prozess führt Ihr JavaScript auf einem Thread aus und überlässt das Warten - auf Festplatte, Netzwerk, Datenbank - dem System. So hält ein einziger Prozess viele Verbindungen gleichzeitig offen.

1Call Stack

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

ein Thread, eine Funktion nach der anderen

Event Looplibuv

5

4Microtask-Queue

promise.then()
await
queueMicrotask()

wird vor dem nächsten Task geleert

3Task-Queue

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

Callbacks, die auf ihren Einsatz warten

2libuv-Threadpoolstandardmäßig vier Threads

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

Betriebssystem epoll · kqueue überwacht jeden Netzwerk-Socket

Der Node.js-Event-Loop, vereinfacht

Ihr Code läuft auf dem Call Stack, eine Funktion nach der anderen.
Langsame Arbeit verlässt den Thread: Dateien, DNS und Hashing gehen an den libuv-Pool, Sockets überwacht das Betriebssystem.
Ist die Arbeit erledigt, wartet ihr Callback in der Task-Queue.
Vor dem nächsten Task laufen alle Promise-Callbacks aus der Microtask-Queue.
Der Loop durchläuft seine Phasen und nimmt den nächsten Task.

PHP und Node auf einem Server

Nginx nimmt jede Anfrage an und schickt jeden Pfad an den Prozess, dem er gehört. Ihre PHP-Website und Ihr Node-Service teilen sich die Maschine, die Datenbank und das Zertifikat - nicht aber den Arbeitsspeicher des anderen.

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

Nginxein Eingang: TLS, Routing, statische Dateien

/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

PHP-Seite

php-fpm: pool www

Ein Pool von Workern. Jede Anfrage beginnt sauber und endet sauber.

Laravel · WordPress · WooCommerce

proxy_pass :3000

Node-Seite

pm2: app (cluster)

Dauerhaft laufende Prozesse. Ein einziger hält viele offene Verbindungen.

Express · NestJS · Next.js · Socket.IO

Von beiden geteilt

MySQL · PostgreSQL
Redis Sessions, Cache, Queues
ein TLS-Zertifikat
ein Backup-Plan

Beispiel eines Servers, der beides betreibt

Was für welche Aufgabe

Wir entwickeln in beiden, also ergibt sich die Antwort aus der Aufgabe, nicht aus Gewohnheit.

Greifen Sie zu PHP, wenn

die Website vor allem aus Seiten, Formularen und einem Adminbereich besteht: Shops, Content-Websites, Geschäftssysteme.
Sie WordPress, WooCommerce oder Laravel wollen und alles, was es dafür bereits gibt.
jede Anfrage für sich steht und schnell fertig ist.
die Menschen, die sie pflegen werden, PHP bereits kennen.

Greifen Sie zu Node, wenn

Verbindungen offen bleiben: Chat, Live-Dashboards, Benachrichtigungen, Tracking.
React- oder Vue-Seiten mit Next.js oder Nuxt auf dem Server gerendert werden.
der Service meist auf andere APIs wartet und Daten durchströmen lässt.
eine Sprache im Browser und auf dem Server Ihrem Team hilft.

Oft lautet die Antwort: beides

PHP behält die Website, den Shop und den Adminbereich; ein kleiner Node-Service übernimmt daneben den Live-Teil. Beide lesen dieselbe Datenbank und stehen hinter demselben Nginx.

Releases ohne Lücke

Ein neues Release startet neben dem alten, beweist, dass es gesund ist, und übernimmt erst dann den Traffic. Die alten Worker beenden die Anfragen, die sie bereits haben, bevor sie stoppen.

Bediente Besucher
Aktuelles Release
Neues Release

01
Holen und installieren
git pull && npm ci
Exakt die Versionen aus der Lockfile, nichts Neueres als Überraschung.
02
Bauen
npm run build
TypeScript und Assets werden kompiliert, bevor irgendetwas neu startet.
03
Neben dem alten starten
pm2 reload app
Das neue Release fährt neben dem hoch, das noch ausliefert.
04
Warten, bis es bereit ist
wait_ready: true
Es muss seinen Health Check bestehen, bevor es einen Besucher bekommt.
05
Den Traffic übernehmen
cluster → new workers
Neue Verbindungen gehen an das neue Release.
06
Das alte leerlaufen lassen
SIGINT → server.close()
Die alten Worker beenden ihre laufenden Anfragen und fahren dann herunter.

Besteht das neue Release seinen Health Check nicht, bekommt es keinen Traffic: Das alte liefert einfach weiter aus.

Der Server rund um den Code

Was einen Node-Service am Laufen hält, steht auf dem Server - in Dateien, die wir pflegen und die Sie lesen können.

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

Reverse Proxy

TLS, Komprimierung, zwischengespeicherte statische Dateien und WebSocket-Upgrades, vor jedem Prozess.
/srv/app/ecosystem.config.js

Prozessmanager

PM2 hält den Prozess am Leben, startet ihn nach einem Absturz neu und nutzt im Cluster-Modus jeden Kern. Wo ein Prozess genügt, erledigt eine systemd-Unit dieselbe Aufgabe.
/srv/app/.env (0600)

Umgebung und Geheimnisse

Schlüssel und Passwörter liegen außerhalb des Codes und außerhalb von git, lesbar nur für den eigenen Benutzer der Anwendung.
/srv/app/package-lock.json

Abhängigkeitsprüfung

npm audit bei jedem Release; Upgrades werden gelesen und getestet, bevor sie in die Produktion gehen.
/srv/app/.nvmrc

Upgrades zwischen Node-LTS-Versionen

Die Anwendung läuft auf einer Long-Term-Support-Version, und wir heben sie auf die nächste, bevor die alte aus dem Support fällt.
/var/log/app/

Logs und Monitoring

Strukturierte, rotierte Logs, mit einer Warnung, wenn der Prozess neu startet, der Speicher steigt oder Fehler zunehmen.

Sagen Sie uns, was Ihre Node-Anwendung leisten muss

Ein neuer Service, eine Next.js-Website oder eine Anwendung, die schon irgendwo läuft und ein ordentliches Zuhause braucht. Wir sehen sie uns an und erstellen nach einem kurzen Gespräch ein Angebot.

Angebot anfordern Dedizierte Server