Arquitetura

Nesta página

O EmDash é executado dentro de uma aplicação Astro. As páginas públicas e o painel de administração compartilham o runtime do EmDash, o banco de dados e o armazenamento de mídia. São partes de uma única aplicação implantada, e não um frontend e um serviço CMS separado.

As partes de um site EmDash

A tabela a seguir mostra como cada parte se conecta através do runtime do EmDash:

ParteAçãoConexão
Painel de administraçãoSalva entradas e mídiaEnvia alterações para o runtime do EmDash
Páginas e componentes AstroConsultam entradas para o site públicoLeem conteúdo através do runtime do EmDash
Runtime do EmDashAplica o modelo de conteúdo, regras de publicação, consultas, plugins e comportamento da APILê e escreve no banco de dados e no armazenamento de mídia
Banco de dados SQLArmazena o modelo de conteúdo, entradas, usuários, configurações e outros registrosUsado pelo runtime do EmDash
Armazenamento de mídiaArmazena arquivos enviadosUsado pelo runtime do EmDash

Os editores usam o painel de administração para trabalhar com o conteúdo. Os desenvolvedores do site decidem como esse conteúdo aparece escrevendo páginas e componentes Astro. Ambos os lados usam o mesmo modelo de conteúdo: as definições de coleções e campos que descrevem cada entrada.

O banco de dados armazena o modelo de conteúdo, entradas, usuários, configurações e outros registros do CMS. O adaptador de armazenamento de mídia mantém os arquivos enviados. Um campo de mídia em uma entrada se refere a um item de mídia armazenado em vez de colocar os bytes do arquivo na tabela de conteúdo.

O que o Astro configura

Um site EmDash precisa de renderização no servidor porque o admin, as rotas da API e o conteúdo atual são servidos em tempo de execução. Configure o Astro com output: "server" e um adaptador para a plataforma de implantação.

Registre tanto React quanto EmDash no array de integrações do Astro. O React hidrata o painel de administração; se @astrojs/react estiver instalado mas react() estiver faltando no array, a página do admin permanece em Carregando EmDash….

O seguinte exemplo Node.js fornece um banco de dados SQLite e armazenamento de mídia 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",
			}),
		}),
	],
});

A integração pode usar outros adaptadores de banco de dados e armazenamento suportados. Um adaptador de armazenamento local é o padrão quando storage é omitido, mas implantações em produção precisam de armazenamento que persista entre versões e instâncias da aplicação. Veja Configuração para os adaptadores e opções disponíveis.

Como as páginas consultam conteúdo

src/live.config.ts registra o carregador do EmDash como uma Coleção de Conteúdo ao Vivo do Astro:

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

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

As páginas então chamam getEmDashCollection() para uma lista ou getEmDashEntry() para uma entrada. A seguinte consulta carrega publicações quando a página é renderizada:

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

Uma página renderizada no servidor executa esta consulta para requisições recebidas, sujeita a qualquer cache que você configure. Uma página pré-renderizada a executa durante a compilação e não pode mostrar edições posteriores até outra compilação.

Como o modelo muda

Os administradores podem criar coleções e campos no painel de administração. O EmDash altera o esquema do banco de dados para que entradas e consultas posteriores usem o novo modelo. Arquivos seed fornecem uma forma controlada por versão de descrever um modelo inicial para outro ambiente, e declarações TypeScript geradas ajudam os desenvolvedores a usar o modelo atual no código.

Essas ferramentas descrevem e alteram o mesmo modelo; não criam cópias paralelas. Leia Modelo de conteúdo para o fluxo de trabalho e os limites de segurança de dados.

Como os plugins estendem o runtime

Os plugins podem responder a eventos de conteúdo e mídia e adicionar rotas de API, configurações ou interfaces de administração. Plugins nativos são executados com o acesso da aplicação host. Plugins em formato padrão podem ser executados em um runtime isolado quando o site configura um executor sandbox e concede capacidades. Leia Escolher um formato de plugin antes de instalar ou criar um.