Architecture

EmDash s’exécute à l’intérieur d’une application Astro. Les pages publiques et le panneau d’administration partagent le runtime EmDash, la base de données et le stockage de médias. Ce sont des parties d’une seule application déployée plutôt qu’un frontend et un service CMS séparé.

Les composants d’un site EmDash

Le tableau suivant montre comment chaque partie se connecte via le runtime EmDash :

Les éditeurs utilisent le panneau d’administration pour travailler avec le contenu. Les développeurs du site décident comment ce contenu apparaît en écrivant des pages et des composants Astro. Les deux côtés utilisent le même modèle de contenu : les définitions de collections et de champs qui décrivent chaque entrée.

La base de données stocke le modèle de contenu, les entrées, les utilisateurs, les paramètres et autres enregistrements CMS. L’adaptateur de stockage de médias conserve les fichiers téléversés. Un champ média dans une entrée fait référence à un élément média stocké plutôt que de placer les octets du fichier dans la table de contenu.

Ce qu’Astro configure

Un site EmDash a besoin du rendu serveur car l’admin, les routes API et le contenu actuel sont servis à l’exécution. Configurez Astro avec output: "server" et un adaptateur pour la plateforme de déploiement.

Enregistrez React et EmDash dans le tableau d’intégrations Astro. React hydrate le panneau d’administration ; si @astrojs/react est installé mais que react() manque dans le tableau, la page admin reste sur Chargement d’EmDash….

L’exemple Node.js suivant fournit une base de données SQLite et un stockage de médias local :

import node from "@astrojs/node";
import react from "@astrojs/react";
import { defineConfig } from "astro/config";
import emdash, { local } from "emdash/astro";
import { sqlite } from "emdash/db";

export default defineConfig({
	output: "server",
	adapter: node({ mode: "standalone" }),
	integrations: [
		react(),
		emdash({
			database: sqlite({ url: "file:./data.db" }),
			storage: local({
				directory: "./uploads",
				baseUrl: "/_emdash/api/media/file",
			}),
		}),
	],
});

L’intégration peut utiliser d’autres adaptateurs de base de données et de stockage pris en charge. Un adaptateur de stockage local est la valeur par défaut quand storage est omis, mais les déploiements en production ont besoin d’un stockage qui persiste à travers les versions et instances de l’application. Voir Configuration pour les adaptateurs et options disponibles.

Comment les pages interrogent le contenu

src/live.config.ts enregistre le chargeur EmDash comme une Collection de Contenu Live Astro :

import { defineLiveCollection } from "astro:content";
import { emdashLoader } from "emdash/runtime";

export const collections = {
	_emdash: defineLiveCollection({ loader: emdashLoader() }),
};

Les pages appellent ensuite getEmDashCollection() pour une liste ou getEmDashEntry() pour une entrée. La requête suivante charge les articles quand la page est rendue :

---
import { getEmDashCollection } from "emdash";

const { entries: posts, error } = await getEmDashCollection("posts");

if (error) throw error;
---

<ul>{posts.map((post) => <li>{post.data.title}</li>)}</ul>

Une page rendue côté serveur exécute cette requête pour les requêtes entrantes, sous réserve de tout cache que vous configurez. Une page pré-rendue l’exécute pendant la compilation et ne peut pas afficher les modifications ultérieures avant une autre compilation.

Comment le modèle change

Les administrateurs peuvent créer des collections et des champs dans le panneau d’administration. EmDash modifie le schéma de la base de données pour que les entrées et requêtes ultérieures utilisent le nouveau modèle. Les fichiers seed fournissent un moyen contrôlé par version de décrire un modèle de départ pour un autre environnement, et les déclarations TypeScript générées aident les développeurs à utiliser le modèle actuel dans le code.

Ces outils décrivent et modifient le même modèle ; ils ne créent pas de copies parallèles. Lisez Modèle de contenu pour le flux de travail et les limites de sécurité des données.

Comment les plugins étendent le runtime

Les plugins peuvent répondre aux événements de contenu et de médias et ajouter des routes API, des paramètres ou des interfaces d’administration. Les plugins natifs s’exécutent avec l’accès de l’application hôte. Les plugins au format standard peuvent s’exécuter dans un runtime isolé quand le site configure un exécuteur sandbox et accorde des capacités. Lisez Choisir un format de plugin avant d’en installer ou d’en créer un.