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
Läuft auf und gebaut mit
  • Node.js
  • Express
  • npm
  • NGINX
  • MySQL
  • PostgreSQL
  • Redis

Was wir in Node bauen

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

  1. 01

    Express

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

    APIs und Backends
  2. 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
  3. 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
  4. 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
  5. 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.

Der Node.js-Event-Loop, vereinfacht
  1. Ihr Code läuft auf dem Call Stack, eine Funktion nach der anderen.
  2. Langsame Arbeit verlässt den Thread: Dateien, DNS und Hashing gehen an den libuv-Pool, Sockets überwacht das Betriebssystem.
  3. Ist die Arbeit erledigt, wartet ihr Callback in der Task-Queue.
  4. Vor dem nächsten Task laufen alle Promise-Callbacks aus der Microtask-Queue.
  5. 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.

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

    Holen und installieren

    git pull && npm ci

    Exakt die Versionen aus der Lockfile, nichts Neueres als Überraschung.

  2. 02

    Bauen

    npm run build

    TypeScript und Assets werden kompiliert, bevor irgendetwas neu startet.

  3. 03

    Neben dem alten starten

    pm2 reload app

    Das neue Release fährt neben dem hoch, das noch ausliefert.

  4. 04

    Warten, bis es bereit ist

    wait_ready: true

    Es muss seinen Health Check bestehen, bevor es einen Besucher bekommt.

  5. 05

    Den Traffic übernehmen

    cluster → new workers

    Neue Verbindungen gehen an das neue Release.

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

Vier Zahlen hinter jedem Node-Dienst

Jede Zahl stammt aus der Dokumentation von Node.js, libuv oder WebSocket und nicht aus eigenen Messungen, sodass Sie sie an der Quelle nachprüfen können.

  • 30Monate

    Fehlerbehebungen für jede Node.js-LTS-Version: 12 Monate aktive Unterstützung, danach 18 Monate Wartung.

    Quelle: Node.js Release Working Group

  • 4Threads

    im libuv-Pool standardmäßig, für Dateien, DNS und Hashing. Eine Einstellung kann den Pool bis auf 1024 erhöhen.

    Quelle: libuv-Dokumentation

  • 101Statuscode

    ist die Antwort, mit der ein Server die Umstellung einer Anfrage auf WebSocket bestätigt: Switching Protocols.

    Quelle: RFC 6455

  • 443Port

    ist der Standardport für eine gesicherte WebSocket-Verbindung, derselbe wie bei HTTPS, sodass der eine Nginx-Eingang beides trägt.

    Quelle: RFC 6455

Was ein Node-Dienst kann, auf einen Blick

Die Fähigkeiten in vier Gruppen: was er ausliefert, was er abgibt, wo er seine Daten hält und wie er in Betrieb bleibt.

Bauen und ausliefern

  • HTTP- und REST-APIs

    Express allein oder NestJS, das standardmäßig auf Express läuft und stattdessen Fastify nutzen kann.

  • TypeScript

    Typisierte Schnittstellen zwischen Modulen, beim Build geprüft, bevor irgendetwas neu startet.

  • Server-Rendering

    Next.js und Nuxt rendern Seiten auf dem Server, sodass Suchmaschinen und Erstbesucher fertiges HTML erhalten.

  • Echtzeit

    Socket.IO startet über einfaches HTTP und wechselt dann auf WebSocket, verbindet sich also auch dort, wo ein Proxy WebSockets blockiert, und baut die Verbindung selbstständig wieder auf.

Schwere Arbeit abgeben

  • Worker-Threads

    Rechenintensives JavaScript läuft in eigenen Threads und lässt die Anfrageschleife frei. Sie helfen beim Rechnen, nicht beim Warten auf I/O.

  • Warteschlangen mit Redis

    Langsame Jobs werden eingereiht und im Hintergrund erledigt, abseits der Anfrage des Besuchers.

  • Geplante Aufgaben

    Jobs, die zu festen Zeiten laufen, statt darauf zu warten, dass ein Besucher sie auslöst.

  • Cluster-Modus

    PM2 startet einen Worker pro Kern, sodass ein stark genutzter Dienst die ganze Maschine nutzt statt nur einen Thread.

Daten in der Nähe halten

  • MySQL und PostgreSQL

    Der Node-Dienst und die PHP-Website können dieselbe Datenbank lesen.

  • Redis

    Sitzungen, Cache und Warteschlangen im Arbeitsspeicher, von beiden Laufzeiten gemeinsam genutzt.

  • Statische Dateien

    Nginx liefert CSS, Bilder und Downloads direkt von der Platte aus, sodass Node nur bearbeitet, was Code braucht.

  • Ein Backup-Plan

    Ein Backup-Plan deckt die PHP-Website und den Node-Dienst gemeinsam ab.

Laufen und aktuell bleiben

  • Neustart bei Ausfall

    PM2 oder, wo ein Prozess genügt, eine systemd-Unit holt einen abgestürzten Prozess zurück.

  • Neu laden ohne Lücke

    Ein neues Release besteht seinen Health-Check, bevor es Datenverkehr übernimmt.

  • Logs und Alarme

    Strukturierte, rotierte Logs und ein Alarm, wenn der Prozess neu startet, der Speicher steigt oder Fehler zunehmen.

  • LTS und Audits

    Ein Node-Release mit Langzeitunterstützung, npm audit bei jedem Release und Geheimnisse außerhalb des Codes.

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

Passende Leistungen

Laravel Anwendungen auf Laravel mit Queues, Zeitplänen und Deploys, die die Website nicht stoppen.Datenbanken MySQL, MariaDB, PostgreSQL, Redis, MongoDB und mehr: abgestimmt, repliziert, Wiederherstellung getestet.Dedizierte Server Eine ganze Maschine, in Stunden bereitgestellt, vom selben Team betreut.Managed Hosting Nginx und LiteSpeed auf NVMe, pro Site abgestimmt, rund um die Uhr überwacht.
MickeyAntwortet in Sekunden