Astro 5 Content Layer e Server Actions: Guia Prático de Migração e Performance

O Astro 5 reformulou a maneira como projetos gerenciam dados estáticos e dinâmicos com a introdução da Content Layer e a estabilização das Server Actions. Nas versões anteriores, a pasta src/content/ era restrita a arquivos locais Markdown e MDX. Com a nova arquitetura, qualquer fonte de dados — de APIs Headless CMS como Sanity e Strapi até bancos de dados SQL — pode ser consumida com validação de esquema estrita via Zod.

Se você está planejando preparar sua base de código para os próximos lançamentos ou quer entender os fundamentos que antecedem inovações futuras demonstradas na evolução do Astro 7 e sua arquitetura de rotas, este guia cobre a reestruturação das coleções e formulários.

O que muda no arquivo src/content.config.ts com a nova Content Layer?

A principal mudança estrutural é a substituição do utilitário defineCollection baseado no sistema de arquivos implícito pelo carregador explícito glob ou carregadores de API personalizados.

Como era no Astro 4 (Sintaxe antiga)

// src/content/config.ts (Legado)
import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
  }),
});

export const collections = { blog };

Como fica no Astro 5 (Sintaxe atual recomendada)

// src/content.config.ts (Astro 5+)
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ base: './src/content/blog', pattern: '**/*.{md,mdx}' }),
  schema: z.object({
    title: z.string(),
    pubDate: z.coerce.date(),
  }),
});

export const collections = { blog };

Note que o arquivo de configuração foi movido da subpasta para a raiz do código fonte em src/content.config.ts. Essa alteração reduz o tempo de build em projetos com milhares de arquivos, pois o Astro deixa de varrer diretórios não especificados.

Como implementar Server Actions nativas para processamento de formulários seguros?

Antes das Server Actions, enviar formulários para interatividade (como um cadastro de newsletter ou comentários) exigia a criação manual de rotas de API em src/pages/api/newsletter.ts com manipulação de objetos Request e Response.

No Astro 5, você define a ação diretamente no servidor com validação tipada:

// src/actions/index.ts
import { defineAction } from 'astro:actions';
import { z } from 'astro:schema';

export const server = {
  subscribeNewsletter: defineAction({
    accept: 'form',
    input: z.object({
      email: z.string().email('Digite um e-mail válido.'),
    }),
    handler: async (input) => {
      // Integração direta com serviço de e-mail ou banco de dados
      return { success: true, message: `Inscrição confirmada para ${input.email}` };
    },
  }),
};

E no seu componente .astro, o envio é tratado de forma totalmente integrada:

---
import { actions } from 'astro:actions';
const result = Astro.getActionResult(actions.subscribeNewsletter);
---

<form method="POST" action={actions.subscribeNewsletter}>
  <input type="email" name="email" required />
  <button type="submit">Inscrever-se</button>
</form>

{result?.data?.success && <p class="sucesso">{result.data.message}</p>}

A combinação dessa manipulação de ações no servidor com a entrega estática de páginas garante o menor envio de JavaScript possível para o cliente. Se o seu foco é otimizar o ranqueamento e o tempo de carregamento no Google, vale aprofundar na estratégia de rotas dinâmicas, desempenho e SEO no Astro para manter pontuações máximas no Core Web Vitals.