Cadres sur bext

bext, c'est deux choses à la fois :

1. Une interface HTTP Rust à terminaison TLS qui se fait passer pour nginx pour des raisons de compatibilité, puis achemine par hôte via le cadre déclaré par le site.
2. Un framework natif appelé PRISM — TSX → string-builder rendu du serveur, pas de React sur le serveur, avec une passe de compilation au moment de la construction d'une moyenne de 15,7 µs sur le luminaire actuel de 38,3 Ko validé par octet, contre 75,3 µs via JSX automatique. Voir PRISM et passe de compilation.

Vous pouvez exécuter un site sur PRISM, ou vous pouvez exécuter un site sur Next.js / Hono / Express / Laravel / Symfony / une application de gestionnaire d'extraction et utiliser les adaptateurs de bext pour appeler ses services de plate-forme. Le choix se fait par site, dans chaque bext.config.toml.

Quand choisir quoi#

PRISM est le choix recommandé pour les nouveaux projets bext uniquement. Il a la surcharge de configuration la plus faible (zéro configuration par défaut pour n'importe quel répertoire avec [framework] type = "prism" et src/app/page.tsx ) et les meilleures performances par rendu (la passe de compilation rend bien avant Marko 5 et Solid 1.9 sur le même appareil - voir les benchmarks passe de compilation).

PRISM (natif)#

Le propre framework de bext. JSX compile pour diriger les chaînes HTML via le Exécution h() ; une passe de compilation au moment de la construction plie des arborescences de composants entières en concaténations de chaînes uniques. Pas de React sur le serveur, pas de DOM virtuel, pas de différence. Ilots optionnels ( "use client" ) pour l'interactivité.

PRISM comprend deux modèles d'hydratation  : "use client" (îlots basés sur React) et "use signals" (exécution des signaux de bext - réactivité à grain fin, pas de DOM virtuel, environ 3 Ko d'exécution d'hydrate). Les deux peuvent coexister sur la même page ; le script de chargement sélectionne le bon bundle en Attribut data-runtime.

PRISM est utilisé sur les sites de production propriétaires, notamment bext.dev, docs.bext.dev, status.bext.dev et blog.bext.dev ; sites/prism-demo reste la fonctionnalité exécutable.

Adaptateurs de cadre ( Next.js, Hono, Laravel, etc.)#

Pour les sites construits sur un framework différent, bext fournit des adaptateurs SDK qui exposent ses services de plateforme (invalidation du cache, pub/sub en temps réel, magasin KV, files d'attente durables, tâches planifiées) via une API idiomatique.

Détection automatique#

bext détecte automatiquement votre framework sans configuration :

1. Next.js — next.config.{js,ts,mjs} présent
2. Hono — hono dans les dépendances package.json
3. Express / Fastify — Modèle .listen() dans le point d'entrée
4. FetchHandler — Modèle export default { fetch } (Bun/Deno/Workers)
5. bext Natif — bext.config.toml présent
6. Site statique — uniquement les répertoires public/ ou static/

Le framework détecté détermine quelles transformations sources sont appliquées :

• Next.js obtient 14 transformations (suppression d'importation, optimisation du barillet, optimisation des polices, actions du serveur, modules CSS, etc.)
• Hono obtient 3 transformations (env en ligne, bande d'importation, réécriture d'alias)
• Les frameworks génériques obtiennent 3 transformations (env en ligne, réécriture d'alias, processus polyfill)
• Les sites statiques ne reçoivent aucune transformation

Architecture#

Tous les adaptateurs SDK communiquent avec bext via des appels HTTP vers un side-car local :

┌──────────────┐     HTTP (localhost:3061)     ┌──────────────┐
│  Your App    │  ──────────────────────────→  │  bext Server │
│  (Next.js,   │  ← cache, realtime, kv,      │              │
│   Laravel,   │    queue, tasks               │  ISR Cache   │
│   etc.)      │                               │  PubSub Hub  │
└──────────────┘                               │  KV Store    │
                                               │  Queue       │
                                               │  Scheduler   │
                                               └──────────────┘

Variables d'environnement :

• BEXT_SDK_URL — URL de base du side-car (par défaut : http://127.0.0.1:3061)
• BEXT_APP_ID — identifiant d'application pour l'isolation multi-applications (par défaut : default )

Services communs#

Chaque adaptateur donne accès aux cinq mêmes services :

Invalidation du cache#

Invalidez les pages mises en cache ISR par balise ou chemin :

// TypeScript
await cache.invalidateTag("products");
await cache.invalidatePath("/api/products");

// PHP
bext_invalidate("products");
app('bext.cache')->invalidatePath("/api/products");

Pub/Sub en temps réel#

Push les événements vers les navigateurs connectés via SSE/ WebSocket :

await realtime.publish("orders", { id: 123, status: "shipped" });

bext_publish("orders", ["id" => 123, "status" => "shipped"]);

Magasin KV#

Stockage clé-valeur avec une durée de vie facultative (secondes) comme troisième argument :

await kv.set("session:abc", userData, 3600);
const data = await kv.get("session:abc");
await kv.delete("session:abc");

Files d'attente durables#

Traitement des tâches en arrière-plan avec prise en charge des nouvelles tentatives :

await queue.push("emails", { to: "user@example.com", template: "welcome" });
const msg = await queue.pull("emails");
await queue.ack("emails", msg.id);

Tâches planifiées#

Enregistrement des tâches de style Cron :

await tasks.register("cleanup", { cron: "0 2 * * *", command: "cache::gc" });
const all = await tasks.list();
await tasks.cancel("cleanup");

Mode Travailleur PHP#

Les adaptateurs PHP ( Laravel, Symfony ) prennent en charge le mode travailleur pour des performances considérablement améliorées :

Le mode Worker maintient le noyau du framework chargé en mémoire et traite les requêtes en boucle, éliminant ainsi la surcharge d'amorçage par requête. Consultez les pages Laravel et Symfony pour les détails de configuration.

Modes de rendu#

Chaque application de votre bext.config.toml peut utiliser une stratégie de rendu différente :

[[apps]]
hostname = "blog.example.com"
root = "./blog"
rendering = "isr"        # Cached with background revalidation
revalidate = 3600

[[apps]]
hostname = "api.example.com"
root = "./api"
rendering = "ssr"        # Fresh render every request

[[apps]]
hostname = "docs.example.com"
root = "./docs"
rendering = "static"     # Pre-built at deploy time

Modes disponibles : isr (par défaut), ssr, static, swr.

En rapport#

• Cadre PRISM — Framework TSX natif de bext, zéro-JS par défaut
• Passe de compilation — comment PRISM plie les arborescences de composants au moment de la construction
• Îles — ajout d'une interactivité côté client aux pages PRISM
• Rendu à la demande Next.js — servir une application Next.js sans étape de génération
• Mise en cache — TTL, périmé pendant la revalidation et garde de bousculade
• Modes de déploiement — Comparaison ISR vs SSR vs statique vs SWR