React, Vue und statische Websites mit externen APIs hosten

Ja, Sie können ein Projekt mit React, Vue oder einem anderen JavaScript-Framework hosten, wenn das Ergebnis des Builds eine statische Website ist. Das Hosting liefert die fertigen HTML-, CSS-, JavaScript- und Bilddateien aus; Node.js muss dafür nicht dauerhaft laufen.

Eine moderne Anwendung besteht meist aus zwei Teilen:

• Frontend: Es wird mit Vite, Webpack, Rollup oder einem anderen Tool gebaut und erzeugt ein Verzeichnis wie dist, build oder out. Sie können es in Ihrem Konto mit Node.js und npm bauen, auch innerhalb von Deploy+, und das Ergebnis ganz normal veröffentlichen.
• Externes Backend: Datenbank, Authentifizierung oder Speicher bleiben bei Supabase, Firebase, Strapi Cloud, Sanity, Airtable oder einem anderen Anbieter. Der Browser des Besuchers verbindet sich per HTTPS mit dessen API, daher wird dieser Dienst auf dem Hosting weder installiert noch ausgeführt.

Das Hosting muss nur mit dem kompatibel sein, was darauf läuft. Eine externe API erfordert keine besondere Unterstützung durch das Hosting.

Zwei Wege, die externe API aufzurufen

Bei einem vollständig statischen Frontend läuft die Kommunikation so ab:

Visitante → HTML, CSS y JS del hosting → API del proveedor

In diesem Fall ruft der Browser den Anbieter direkt auf. Dessen API muss per CORS Anfragen von Ihrer Domain akzeptieren, und Sie müssen dort die erlaubten Domains und die Rückleitungs-URLs der Authentifizierung konfigurieren.

Sie können auch ein PHP-Backend im Konto dazwischenschalten:

Visitante → frontend del hosting → PHP del hosting → API del proveedor

PHP kann ausgehende HTTPS-Anfragen an externe APIs senden, etwa mit cURL, Guzzle oder dem HTTP-Client von Frameworks wie Laravel. Die API muss erreichbar sein und den Netzwerkursprung, die Zugangsdaten und den Vorgang zulassen; ihre Einschränkungen oder die des Servers können eine bestimmte Verbindung begrenzen. Diese Architektur ist nützlich, wenn Sie einen privaten Schlüssel aufbewahren, Daten vor dem Senden prüfen oder umwandeln oder verhindern müssen, dass ein sensibler Vorgang im Browser ausgeführt wird. PHP ist an diesen Anfragen beteiligt, die API und ihre Daten bleiben aber beim externen Anbieter.

Die CORS-Beschränkungen des Browsers gelten nicht für die Kommunikation zwischen PHP und dem Anbieter. Die API verlangt weiterhin ihre üblichen Zugangsdaten, Berechtigungen und Nutzungslimits.

Welche Projekte passen und welche eine andere Umgebung brauchen

Für Fälle, die einen Server oder einen dauerhaften Node-Prozess benötigen, verwenden Sie eine Umgebung, die diese Runtime unterstützt und verwaltet, etwa eine Anwendungsplattform oder einen VPS. Queue-Worker und Consumer in PHP können in den Tarifen Avanza, Max und Elastic als dauerhafte Prozesse laufen, und Echtzeit in einer Laravel-Anwendung lässt sich mit einem Pusher-kompatiblen Dienst umsetzen. Root-Zugang ist nicht immer nötig: Das hängt vom gewählten Dienst ab. Der Name des Frameworks entscheidet nicht allein über die Kompatibilität: Entscheidend ist, ob der Build in statischen Dateien endet oder ob die Anwendung einen laufenden Server verlangt.

Der Fall Next.js

Next.js kann auf beide Arten arbeiten und sorgt deshalb oft für Fragen. Um eine statische Website zu erzeugen, konfigurieren Sie den Export, zum Beispiel in next.config.mjs:

const nextConfig = {
  output: 'export',
};

export default nextConfig;

Beim Ausführen von next build erstellt Next.js das Verzeichnis out mit den Dateien, die Sie veröffentlichen müssen. Die Next.js-Dokumentation zu statischen Exporten beschreibt, welche Funktionen dieser Modus unterstützt.

Ein statischer Export kann Logik, die von einem Next.js-Server abhängt, nicht bei jedem Besuch ausführen, etwa SSR, serverseitig gelesene Cookies, Server Actions oder dynamische API-Routen. Wenn das Projekt diese Funktionen nutzt, müssen Sie sie auf eine externe API oder PHP-Endpunkte umstellen oder die Anwendung in einer Umgebung hosten, die ihre Server-Runtime unterstützt.

Das Projekt mit Deploy+ veröffentlichen

Sie können ein gebautes Frontend mit Deploy+ veröffentlichen: Jedes Deployment klont das Repository in eine neue Version, führt dort den Build aus und macht sie erst öffentlich, wenn alle Befehle erfolgreich abgeschlossen sind.

Beim Verbinden des Repositorys:

1. Wählen Sie im Schritt Projekt die Option Kompiliertes Frontend. Deploy+ schlägt dist als Web-Stammverzeichnis und ein Skript vor, das npm ci und npm run build ausführt.
2. Prüfen Sie das Verzeichnis, das Ihr Projekt erzeugt. Behalten Sie dist für die übliche Vite-Konfiguration bei, ändern Sie es aber in build, out oder einen anderen Pfad, wenn Ihr Tool einen anderen Namen verwendet. Ein statischer Next.js-Export verwendet out.
3. Prüfen Sie das vorgeschlagene Skript. Jede Zeile läuft in einer eigenen Shell, daher müssen alle Zeilen mit npm, npx oder node NVM in derselben Zeile aktivieren. Die Vorlage ist bereits so vorbereitet.
4. Aktivieren Sie unter Automatisierung die Option Bei Push deployen, wenn jede Änderung im gewählten Branch eine neue Version erzeugen soll.

Deploy+ prüft Node.js, bevor ein Skript ausgeführt wird, das es benötigt, und installiert es automatisch, wenn es im Konto noch nicht verfügbar ist. Wenn Ihre package.json eine bestimmte Version verlangt, wählen Sie diese vor dem ersten Deployment unter Hosting → Ihr Dienst → Paketmanager aus, wie in der Anleitung zur Installation von Node.js und npm beschrieben.

Wenn npm ci meldet, dass die Lock-Datei fehlt oder nicht passt, erstellen Sie sie in der Entwicklung, testen Sie die Abhängigkeiten und speichern Sie package-lock.json neben package.json, bevor Sie deployen. Mit der Lock-Datei werden bei jedem Build dieselben Versionen der Abhängigkeiten installiert.

Das Skript läuft, bevor das Release aktiviert wird. Schlägt die Installation der Abhängigkeiten oder der Build fehl, bleibt die vorherige Version veröffentlicht, und Besucher erhalten keine halb gebaute Website. Wenn Sie nach der Veröffentlichung ein Problem bemerken, öffnen Sie den Verlauf und verwenden Sie Zu dieser Version zurückkehren bei einem früheren Release. Ist dieses Release noch gespeichert, ändert Deploy+ nur den symbolischen Link und die Rückkehr dauert Sekunden; wurde es bei der Bereinigung alter Versionen bereits gelöscht, muss es aus dem Repository neu gebaut werden und es dauert länger.

Die Rückkehr ändert den veröffentlichten Code und die Assets, macht aber bereits ausgeführte Vorgänge in der externen API nicht rückgängig und stellt weder Daten noch Konfiguration des Anbieters wieder her.

Die .env von Deploy+ und die Schlüssel des externen Dienstes

Deploy+ bewahrt die Datei .env im gemeinsamen Ordner auf und verlinkt sie in jedes Release, bevor das Skript läuft. Bei einem statischen Frontend liest der Bundler die Variablen während des Builds: Es gibt keinen Node.js-Prozess, der .env bei einem Besuch erneut liest.

Jeder Wert im gebauten JavaScript ist für Besucher in ihrem Browser sichtbar. Den Variablennamen zu ändern oder den Wert in einer .env-Datei abzulegen, macht ihn nicht geheim.

Nehmen Sie nur öffentliche Werte in das Bundle auf, zum Beispiel:

• Die URL der API oder die Projektkennung.
• Einen Schlüssel, den der Anbieter ausdrücklich als öffentlich, publishable oder für den Browser bestimmt bezeichnet.
• Öffentliche Kennungen für Analyse oder Konfiguration.

Nehmen Sie keine Passwörter, Admin-Schlüssel, geheimen Schlüssel, service_role-Schlüssel, privaten Tokens oder Datenbank-Zugangsdaten auf. Wenn ein Vorgang eines dieser Geheimnisse benötigt, führen Sie ihn in PHP aus und bewahren Sie die Zugangsdaten in der gemeinsamen .env oder einer anderen Konfigurationsdatei außerhalb des Web-Stammverzeichnisses auf. Laden Sie sie in PHP über das Konfigurationssystem des Frameworks oder eine Bibliothek für .env, ohne sie an den Browser zu senden oder in Logs zu schreiben.

Vite übernimmt Variablen mit dem Präfix VITE_ in das Bundle, wie seine Dokumentation zu Umgebungsvariablen warnt. Next.js macht dasselbe mit NEXT_PUBLIC_. Außerdem werden diese Werte beim Build festgeschrieben: Wenn Sie einen ändern, müssen Sie den Build erneut ausführen und das Ergebnis deployen.

Nicht alle Anbieter benennen ihre Zugangsdaten gleich oder bieten einen Schlüssel an, der für den Browser geeignet ist. Lesen Sie immer deren Dokumentation. Zum Beispiel:

• Supabase sieht den publishable-Schlüssel für den Browser vor und reserviert den secret-Schlüssel für den Server. Die alten Namen anon und service_role sind ihre früheren Entsprechungen. Laut der Dokumentation zu Schlüsseln muss der öffentliche Schlüssel mit Row Level Security und minimalen Berechtigungen kombiniert werden.
• Die Web-Konfiguration und die Schlüssel von Firebase sind absichtlich öffentlich. Firebase schützt die Daten mit Security Rules und App Check, nicht durch das Verbergen dieser Konfiguration.

Öffentliche Schlüssel ersetzen keine Zugriffskontrollen. Aktivieren Sie beim Anbieter die passenden Regeln pro Benutzer, Zeilenrichtlinien, Speicherberechtigungen, Nutzungsbeschränkungen und weiteren Schutzmaßnahmen.

Interne Routen einer SPA

Wenn Ihre Anwendung eine SPA mit einer einzigen index.html ist und die Routen im Browser verwaltet, kann ein direktes Neuladen von /panel einen 404-Fehler liefern. Legen Sie in diesem Fall in ihrem öffentlichen Verzeichnis eine .htaccess an, die echte Dateien beibehält und alle anderen Routen an index.html weiterleitet:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.html [L]

Legen Sie die .htaccess in das Verzeichnis, das das Tool in den Build kopiert; es reicht nicht, sie in einem Repository-Ordner zu lassen, der nicht veröffentlicht wird. Die Regel darf nur für das Frontend gelten: Wenn Sie das Stammverzeichnis mit PHP-Endpunkten oder API-Routen teilen, schließen Sie diese ausdrücklich aus, damit sie kein HTML zurückbekommen.

Diese Regel ist für SPAs mit clientseitigem Routing gedacht. Verwenden Sie sie nicht ungeprüft bei einem Export, der bereits für jede Route eine eigene HTML-Datei erzeugt.

Öffnen Sie die Website nach der Veröffentlichung über ihre endgültige Domain und testen Sie den direkten Aufruf einer internen Route, die Anmeldung, die API-Aufrufe und, falls vorhanden, das Hochladen von Dateien.

CORS authentifiziert keine Benutzer und schützt die API allein nicht vor anderen Clients. Wenn Sie einen PHP-Vermittler einsetzen, prüfen Sie Sitzung und Berechtigungen und begrenzen Sie Ziele und Vorgänge: Erstellen Sie keinen offenen Proxy, der jede URL des Besuchers annimmt. Konfigurieren Sie außerdem Timeouts und prüfen Sie das Ergebnis, bevor Sie Vorgänge mit Nebenwirkungen wiederholen.