NextPDF Cloudflare: Boot und Discovery

Auf einen Blick

Die Bridge bringt weder einen eigenen Service Provider noch ein Bundle oder einen eigenen Auto-Discovery-Hook mit. Es handelt sich um eine Reihe von final-Klassen mit expliziten Konstruktoren. „Discovery“ bedeutet hier, dass Sie entscheiden, welche Kollaborateure injiziert werden, und diese im Container Ihres Frameworks binden. Diese Seite beschreibt genau diese Verdrahtung. Sie führt keinen Registrierungsmechanismus ein, den das Paket nicht besitzt.

Wie die Renderer-Bridge erkannt wird

Sie instanziieren CloudflareHtmlRenderer; er wird nicht automatisch erkannt. Seine Abhängigkeiten bestehen aus Schnittstellen aus PSR-18, PSR-17 und PSR-3 sowie den paketeigenen Config- und Contract-Typen. Jedes Framework, das diese Kollaborateure aufbauen kann, kann auch den Renderer instanziieren. Da das Paket ausschließlich von PSR-Contracts abhängt — der Test tests/Unit/Architecture/PsrConformanceTest.php stellt sicher, dass keine Kopplung an einen konkreten Client besteht —, kann Ihre Host-Anwendung ihr bestehendes HTTP-Client-Binding unverändert weiterverwenden. Die NextPDF-Adapter für Laravel, Symfony und CodeIgniter verwenden dasselbe PSR-18-Binding ebenfalls weiter. Dieses Paket bringt kein eigenes Framework-Paket mit.

Boot-Sequenz

Lösen Sie die folgenden Komponenten in dieser Reihenfolge auf, entsprechend dem Konstruktor von CloudflareHtmlRenderer:

1. Lösen Sie ein PSR-18-ClientInterface auf (das bestehende HTTP-Client-Binding der Anwendung).
2. Lösen Sie das PSR-17-RequestFactoryInterface und StreamFactoryInterface auf; lösen Sie außerdem ResponseFactoryInterface auf, wenn der fest verdrahtete cURL-Transport gewünscht ist.
3. Erstellen Sie aus der aufgelösten Konfiguration eine CloudflareRendererConfig (siehe „Reihenfolge der Konfigurationsauflösung“).
4. Lösen Sie optional ein PSR-3-LoggerInterface, ein LocalRendererFactoryInterface und ein explizites HtmlSecurityPolicyInterface auf.
5. Konstruieren Sie CloudflareHtmlRenderer mit diesen Abhängigkeiten.

Keiner dieser Schritte kontaktiert das Netzwerk. Die erste Netzwerkinteraktion erfolgt beim ersten render()-Aufruf oder beim ersten isAvailable()-Aufruf.

Container-Bindings

Ein exemplarisches Binding (Pseudocode, unabhängig vom Framework):

<?php

declare(strict_types=1);

use NextPDF\Cloudflare\CloudflareHtmlRenderer;
use NextPDF\Cloudflare\CloudflareRendererConfig;
use Psr\Http\Client\ClientInterface;
use Psr\Http\Message\RequestFactoryInterface;
use Psr\Http\Message\ResponseFactoryInterface;
use Psr\Http\Message\StreamFactoryInterface;
use Psr\Log\LoggerInterface;

$container->singleton(CloudflareHtmlRenderer::class, function ($c) {
    return new CloudflareHtmlRenderer(
        config:          CloudflareRendererConfig::fromArray($c->get('config')['cloudflare']),
        httpClient:      $c->get(ClientInterface::class),
        requestFactory:  $c->get(RequestFactoryInterface::class),
        streamFactory:   $c->get(StreamFactoryInterface::class),
        logger:          $c->get(LoggerInterface::class),
        responseFactory: $c->get(ResponseFactoryInterface::class),
    );
});

Reihenfolge der Konfigurationsauflösung

Das Paket liest selbst keine Umgebungsvariablen. Es akzeptiert eine vollständig aufgebaute CloudflareRendererConfig. In der Host-Anwendung lautet die empfohlene Auflösungsreihenfolge: zuerst Umgebungsvariablen, dann veröffentlichte Konfiguration oder Framework-Konfiguration, dann die im Konstruktor festgelegten Paketstandards (dokumentiert unter /integrations/cloudflare/configuration/). CloudflareRendererConfig::fromArray() wendet für jeden fehlenden oder falsch typisierten Schlüssel die Konstruktorstandards an, sodass ein unvollständiges Config-Array vorhersehbar auf die Standards zurückfällt, statt fehlzuschlagen.

Diagnose

Das Signal zur Boot-Zeit ist CloudflareRendererConfig::isValid() — eine reine Prüfung, ob sowohl workerUrl als auch apiToken nicht leer sind, ohne Netzwerkaufruf, sodass sie sich für ein Deploy-Gate eignet. Das Laufzeitsignal ist CloudflareHtmlRenderer::isAvailable(), ein authentifizierter HTTP-HEAD: Er gibt bei einem Status unter 500 true und andernfalls false zurück, ohne jemals eine Exception zu werfen. Damit eignet er sich für einen Readiness-Probe. Eine erfolgreiche Probe ist ein Hinweis, keine Garantie: Der nachfolgende POST kann dennoch fehlschlagen.

Siehe auch

• /integrations/cloudflare/integration/ — die durchgängige Integrationsanleitung.
• /integrations/cloudflare/overview/ — was die Bridge ist und welche Grenze sie überschreitet.
• /integrations/cloudflare/configuration/ — jedes Feld und sein Standard.
• /integrations/cloudflare/security-and-operations/ — wann der fest verdrahtete Transport aktiviert wird.