Arquitectura

EmDash se ejecuta dentro de una aplicación Astro. Las páginas públicas y el panel de administración comparten el runtime de EmDash, la base de datos y el almacenamiento de medios. Son partes de una única aplicación desplegada en lugar de un frontend y un servicio CMS separado.

Las partes de un sitio EmDash

La siguiente tabla muestra cómo cada parte se conecta a través del runtime de EmDash:

Los editores usan el panel de administración para trabajar con el contenido. Los desarrolladores del sitio deciden cómo aparece ese contenido escribiendo páginas y componentes Astro. Ambos lados usan el mismo modelo de contenido: las definiciones de colecciones y campos que describen cada entrada.

La base de datos almacena el modelo de contenido, entradas, usuarios, configuraciones y otros registros del CMS. El adaptador de almacenamiento de medios mantiene los archivos subidos. Un campo de medios en una entrada hace referencia a un elemento de medios almacenado en lugar de colocar los bytes del archivo en la tabla de contenido.

Qué configura Astro

Un sitio EmDash necesita renderizado del servidor porque el admin, las rutas de API y el contenido actual se sirven en tiempo de ejecución. Configura Astro con output: "server" y un adaptador para la plataforma de despliegue.

Registra tanto React como EmDash en el array de integraciones de Astro. React hidrata el panel de administración; si @astrojs/react está instalado pero react() falta en el array, la página de administración permanece en Cargando EmDash….

El siguiente ejemplo de Node.js proporciona una base de datos SQLite y almacenamiento de medios 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",
			}),
		}),
	],
});

La integración puede usar otros adaptadores de base de datos y almacenamiento soportados. Un adaptador de almacenamiento local es el predeterminado cuando se omite storage, pero los despliegues en producción necesitan almacenamiento que persista entre las versiones e instancias de la aplicación. Consulta Configuración para los adaptadores y opciones disponibles.

Cómo las páginas consultan contenido

src/live.config.ts registra el cargador de EmDash como una Colección de Contenido en Vivo de Astro:

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

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

Las páginas luego llaman a getEmDashCollection() para una lista o getEmDashEntry() para una entrada. La siguiente consulta carga publicaciones cuando la página se renderiza:

---
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 página renderizada en el servidor ejecuta esta consulta para las solicitudes entrantes, sujeta a cualquier caché que configures. Una página pre-renderizada la ejecuta durante la compilación y no puede mostrar ediciones posteriores hasta otra compilación.

Cómo cambia el modelo

Los administradores pueden crear colecciones y campos en el panel de administración. EmDash cambia el esquema de la base de datos para que las entradas y consultas posteriores usen el nuevo modelo. Los archivos seed proporcionan una forma controlada por versiones de describir un modelo inicial para otro entorno, y las declaraciones TypeScript generadas ayudan a los desarrolladores a usar el modelo actual en el código.

Estas herramientas describen y cambian el mismo modelo; no crean copias paralelas. Lee Modelo de contenido para el flujo de trabajo y los límites de seguridad de datos.

Cómo los plugins extienden el runtime

Los plugins pueden responder a eventos de contenido y medios y agregar rutas de API, configuraciones o interfaces de administración. Los plugins nativos se ejecutan con el acceso de la aplicación host. Los plugins de formato estándar pueden ejecutarse en un runtime aislado cuando el sitio configura un ejecutor sandbox y otorga capacidades. Lee Elegir un formato de plugin antes de instalar o construir uno.