Architettura

EmDash viene eseguito all’interno di un’applicazione Astro. Le pagine pubbliche e il pannello di amministrazione condividono il runtime EmDash, il database e l’archivio media. Sono parti di un’unica applicazione distribuita piuttosto che un frontend e un servizio CMS separato.

Le parti di un sito EmDash

La seguente tabella mostra come ogni parte si connette attraverso il runtime EmDash:

Gli editor usano il pannello di amministrazione per lavorare con i contenuti. Gli sviluppatori del sito decidono come quei contenuti appaiono scrivendo pagine e componenti Astro. Entrambi i lati usano lo stesso modello di contenuto: le definizioni di collezioni e campi che descrivono ogni voce.

Il database archivia il modello di contenuto, le voci, gli utenti, le impostazioni e altri record del CMS. L’adattatore di archiviazione media mantiene i file caricati. Un campo media in una voce fa riferimento a un elemento media archiviato anziché posizionare i byte del file nella tabella dei contenuti.

Cosa configura Astro

Un sito EmDash necessita del rendering lato server perché l’admin, le route API e i contenuti attuali vengono serviti a runtime. Configura Astro con output: "server" e un adattatore per la piattaforma di distribuzione.

Registra sia React che EmDash nell’array delle integrazioni di Astro. React idrata il pannello di amministrazione; se @astrojs/react è installato ma react() manca dall’array, la pagina admin rimane su Caricamento di EmDash….

Il seguente esempio Node.js fornisce un database SQLite e archiviazione media locale:

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’integrazione può usare altri adattatori di database e archiviazione supportati. Un adattatore di archiviazione locale è il predefinito quando storage viene omesso, ma le distribuzioni in produzione necessitano di archiviazione che persista tra le versioni e le istanze dell’applicazione. Vedi Configurazione per gli adattatori e le opzioni disponibili.

Come le pagine interrogano i contenuti

src/live.config.ts registra il loader EmDash come una Collezione di Contenuti Live di Astro:

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

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

Le pagine poi chiamano getEmDashCollection() per una lista o getEmDashEntry() per una voce. La seguente query carica gli articoli quando la pagina viene renderizzata:

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

Una pagina renderizzata lato server esegue questa query per le richieste in arrivo, soggetta a qualsiasi cache configurata. Una pagina pre-renderizzata la esegue durante la compilazione e non può mostrare le modifiche successive fino a un’altra compilazione.

Come cambia il modello

Gli amministratori possono creare collezioni e campi nel pannello di amministrazione. EmDash modifica lo schema del database in modo che le voci e le query successive usino il nuovo modello. I file seed forniscono un modo controllato dalla versione per descrivere un modello iniziale per un altro ambiente, e le dichiarazioni TypeScript generate aiutano gli sviluppatori a usare il modello corrente nel codice.

Questi strumenti descrivono e modificano lo stesso modello; non creano copie parallele. Leggi Modello di contenuto per il flusso di lavoro e i limiti di sicurezza dei dati.

Come i plugin estendono il runtime

I plugin possono rispondere agli eventi di contenuto e media e aggiungere route API, impostazioni o interfacce di amministrazione. I plugin nativi vengono eseguiti con l’accesso dell’applicazione host. I plugin in formato standard possono essere eseguiti in un runtime isolato quando il sito configura un esecutore sandbox e concede capacità. Leggi Scegliere un formato di plugin prima di installarne o crearne uno.