Guia do Sanity CMS: Como o Usamos para Publicar em 10 Idiomas

Guia do Sanity CMS: Como o Usamos para Publicar em 10 Idiomas

Já publicámos mais de 400 peças de conteúdo em 4 websites e 10 idiomas através do Sanity CMS. Eis o que aprendemos, desde o design do schema até à publicação multilingue automatizada.

O Sanity CMS é uma plataforma de conteúdo headless construída em torno de conteúdo estruturado, um Content Lake em tempo real e um editor personalizável baseado em React chamado Sanity Studio. Utiliza GROQ para consultas, Portable Text para conteúdo rico e schema-as-code para modelação de conteúdo. Este guia abrange a configuração, o design de schemas, GROQ, Portable Text, arquitetura multilingue e preços.

O Que É o Sanity CMS?

O Sanity é uma plataforma de conteúdo estruturado, aquilo que a equipa da Sanity.io chama de "sistema operativo de conteúdo". Ao contrário dos CMS tradicionais que armazenam blobs de HTML numa base de dados, o Sanity armazena cada peça de conteúdo como JSON estruturado num backend gerido chamado Content Lake. Pode consultá-lo com GROQ ou GraphQL e renderizar o conteúdo em qualquer frontend que deseje: Next.js, React Native, Svelte, uma aplicação móvel, uma ferramenta CLI, qualquer coisa.

As empresas que o utilizam abrangem todo o espectro. A Nike, a Figma, a Puma e a Cloudflare executam o Sanity à escala empresarial. As startups usam-no porque o nível gratuito é genuinamente utilizável (mais sobre os preços adiante). Nós usamo-lo porque nada mais nos deu a flexibilidade para construir um pipeline de publicação totalmente automatizado em 10 idiomas.

Arquitetura do Content Lake

O Content Lake é o backend gerido do Sanity. Pense nele como um repositório de documentos alojado que sincroniza em tempo real todos os clientes ligados. Quando um editor altera um parágrafo no Sanity Studio, outro editor vê a alteração instantaneamente, sem botão de guardar, sem conflitos de merge, sem migrações de base de dados.

Nos bastidores, os documentos são armazenados como JSON estruturado com campos tipados. Cada mutação é rastreada através de um registo de transações, por isso obtém um histórico de versões completo por defeito. A sincronização em tempo real utiliza uma arquitetura baseada em listeners (descrita na documentação de arquitetura do GitHub da Sanity) que envia alterações para todos os subscritores via observáveis RxJS.

O que torna isto diferente de, digamos, uma base de dados PostgreSQL com uma API REST? O Content Lake trata da modelação de conteúdo, controlo de acesso, cache de CDN, transformações de imagem e colaboração em tempo real como um único serviço gerido. Não executa migrações. Não gere réplicas. Apenas define schemas e consulta o conteúdo.

Sanity Studio: O Seu Editor Personalizável

O Sanity Studio é uma aplicação React de código aberto que serve como a sua interface de edição. Não é um painel de administração alojado, é uma aplicação React que vive no seu codebase. Pode personalizar todos os aspetos: componentes de input personalizados, campos condicionais, ações de documento, padrões de structure builder e plugins.

A colaboração em tempo real está integrada. Vários editores podem trabalhar no mesmo documento simultaneamente com indicadores de presença e atualizações ao vivo. Se já utilizou o Google Docs, a experiência é semelhante: vê os cursores e as alterações de outras pessoas em tempo real.

Implementamos o nosso Studio com npx sanity deploy, o que o aloja na CDN da Sanity num subdomínio personalizado. Também pode autoalojá-lo, já que é apenas uma aplicação React. Classificámos o Sanity altamente na nossa comparação de CMS headless largamente devido à flexibilidade do Studio.

Como Configurar um Projeto Sanity

Para configurar o Sanity CMS, instale a CLI com npm create sanity@latest, escolha um modelo de projeto, configure os seus ficheiros de schema e execute npx sanity dev para iniciar o Studio localmente. Todo o processo demora menos de 5 minutos.

Pré-requisitos e Instalação

Precisa do Node.js 18+ e npm (ou pnpm). É tudo. Execute o comando de inicialização:

npm create sanity@latest

# You'll be prompted for:
# - Login method (Google, GitHub, email)
# - Project name
# - Dataset name (default: "production")
# - Project template (blog, ecommerce, clean)
# - TypeScript? (recommended: yes)

A CLI cria a estrutura de um projeto com tudo o que precisa. Eis como se parece a estrutura do projeto:

Estrutura do Projeto Explicada

my-sanity-project/
├── schemas/              # Your content schemas (this is where you'll spend time)
│   ├── index.ts          # Schema registry -- imports and exports all types
│   ├── post.ts           # Document type definitions
│   └── blockContent.ts   # Rich text / Portable Text config
├── sanity.config.ts      # Main config -- plugins, Studio structure, dataset
├── sanity.cli.ts         # CLI config -- project ID, dataset
├── package.json
└── tsconfig.json

O ficheiro sanity.config.ts é o seu ponto de entrada. Eis um mínimo:

// sanity.config.ts
import { defineConfig } from 'sanity'
import { structureTool } from 'sanity/structure'
import { visionTool } from '@sanity/vision'
import { schemaTypes } from './schemas'

export default defineConfig({
  name: 'default',
  title: 'My Blog',
  projectId: 'your-project-id',
  dataset: 'production',
  plugins: [structureTool(), visionTool()],
  schema: { types: schemaTypes },
})

O plugin visionTool() oferece-lhe um playground GROQ dentro do Studio, irá utilizá-lo constantemente durante o desenvolvimento.

Implementação do Seu Studio

Inicie localmente com npx sanity dev (executa em localhost:3333). Quando estiver pronto para partilhar com os editores, implemente na CDN da Sanity:

npx sanity deploy
# Prompts for a hostname, e.g., "my-blog"
# Deploys to https://my-blog.sanity.studio

Dica profissional: execute npx sanity@latest schema deploy após qualquer alteração ao schema. Isto carrega o seu schema para a API da Sanity, o que ativa funcionalidades como a API GraphQL e ferramentas conscientes do schema (incluindo o servidor MCP que abordaremos mais tarde).

Design de Schema no Sanity CMS

Os schemas do Sanity são definidos como objetos JavaScript ou TypeScript no seu codebase. Cada schema especifica um tipo de documento com campos, regras de validação e componentes de input personalizados. As alterações aos schemas são instantâneas, não são necessárias migrações de base de dados. Esta é a abordagem "schema-as-code", e foi o que nos convenceu a escolher o Sanity em vez do Contentful.

Tipos de Campo e Validação

O Sanity vem com um conjunto rico de tipos de campo. Eis os que mais utilizamos:

Cada campo suporta validação através de um callback validation. Pode impor campos obrigatórios, valores mínimos/máximos, padrões regex e regras personalizadas:

defineField({
  name: 'seoDescription',
  title: 'Meta Description',
  type: 'string',
  validation: (Rule) =>
    Rule.required()
      .min(145)
      .max(160)
      .warning('Meta description should be 145-160 characters'),
})

Tipos de Bloco Personalizados (Os Nossos Exemplos de Produção)

É aqui que o Sanity se torna interessante, e onde 0 em 6 guias concorrentes mostram algum código. No nosso schema de produção, definimos cinco tipos de bloco personalizados dentro do array do corpo: block (texto padrão), table, codeBlock, chartBlock e inlineImage.

Eis a nossa definição de codeBlock:

// schemas/objects/codeBlock.ts
import { defineType } from 'sanity'

export const codeBlock = defineType({
  name: 'codeBlock',
  title: 'Code Block',
  type: 'object',
  fields: [
    {
      name: 'language',
      title: 'Language',
      type: 'string',
      options: {
        list: [
          { title: 'JavaScript', value: 'javascript' },
          { title: 'TypeScript', value: 'typescript' },
          { title: 'Python', value: 'python' },
          { title: 'Bash', value: 'bash' },
          { title: 'JSON', value: 'json' },
          { title: 'GROQ', value: 'groq' },
        ],
      },
    },
    {
      name: 'code',
      title: 'Code',
      type: 'text',
    },
  ],
})

E eis como o campo do corpo referencia todos os nossos tipos personalizados em conjunto:

// schemas/fields/body.ts
defineField({
  name: 'body',
  title: 'Body',
  type: 'array',
  of: [
    { type: 'block' },         // Standard Portable Text (paragraphs, headings, lists)
    { type: 'table' },         // @sanity/table plugin
    { type: 'codeBlock' },     // Our custom code block
    { type: 'chartBlock' },    // Data visualization (bar, line, pie)
    { type: 'inlineImage' },   // Images with alt text and captions
  ],
})

Isto dá aos nossos editores um kit de ferramentas de conteúdo rico, mantendo ao mesmo tempo cada elemento tipado e consultável. Um chartBlock não é apenas um embed HTML opaco, são dados estruturados com campos chartType, title, dataPoints e dataLabels. Isso importa quando tenta renderizar o mesmo conteúdo na web, email e mobile.

Melhores Práticas de Organização de Schemas

Mantenha os schemas modulares. Dividimos os nossos por tipo em ficheiros: schemas/documents/post.ts, schemas/objects/codeBlock.ts, schemas/objects/chartBlock.ts. Importe-os todos em schemas/index.ts:

// schemas/index.ts
import { post } from './documents/post'
import { codeBlock } from './objects/codeBlock'
import { chartBlock } from './objects/chartBlock'
import { inlineImage } from './objects/inlineImage'

export const schemaTypes = [post, codeBlock, chartBlock, inlineImage]

A ideia chave que ganhámos ao trabalhar com conteúdo estruturado: o seu schema É o seu modelo de conteúdo. Se pensar nisso como engenharia de contexto para a sua equipa de conteúdo, tomará melhores decisões de design. Cada campo que adiciona deve servir um propósito, seja para editores, para renderização ou para consultas.

GROQ: A Linguagem de Consulta do Sanity

GROQ (Graph-Relational Object Queries) é a linguagem de consulta de código aberto do Sanity para filtrar, juntar e projetar documentos JSON. A sintaxe básica é *[filter]{projection}, seleciona todos os documentos que correspondem a um filtro e depois molda a saída. É mais concisa que o GraphQL para consultas específicas do Sanity e, na nossa experiência, mais rápida de aprender.

Consultas Básicas: Filtrar e Projetar

A consulta mais simples obtém todos os documentos de um tipo:

// Fetch all posts -- just title and slug
*[_type == "post"]{
  title,
  "slug": slug.current
}

// Filter by language, expand author reference
*[_type == "post" && language == "en"]{
  title,
  "slug": slug.current,
  "authorName": author->name,
  "authorImage": author->image,
  "categoryTitle": category->title,
  publishedAt
}

O operador -> segue referências. author->name significa "segue a referência do autor e devolve o campo name". Sem consultas separadas, sem problemas N+1, sem JOINs, é tudo uma única expressão.

Junções, Ordenação e Paginação

Para as nossas páginas de índice do blog, precisamos de posts ordenados e paginados com referências expandidas:

// Paginated posts with full metadata
*[_type == "post" && language == "en"] | order(publishedAt desc) [0...10] {
  title,
  "slug": slug.current,
  excerpt,
  publishedAt,
  readTime,
  "author": author->{name, image},
  "category": category->{title, "slug": slug.current},
  "coverImage": coverImage{
    "src": asset->url,
    alt
  }
}

[0...10] dá-lhe os primeiros 10 resultados (indexado a 0, fim exclusivo). | order(publishedAt desc) ordena do mais recente para o mais antigo. A projeção molda a saída para incluir exatamente o que o seu frontend precisa, nada mais.

Pode testar todas estas consultas interativamente utilizando o plugin Vision dentro do Sanity Studio. É invaluable durante o desenvolvimento. Para mais padrões, consulte a folha de dicas GROQ.

GROQ vs GraphQL

O Sanity suporta tanto GROQ como GraphQL. Quando deve usar qual?

O GROQ é a linguagem nativa do Sanity. Lida com junções, projeções e campos computados numa única string de consulta. É para isso que o Content Lake está otimizado.

O GraphQL está disponível depois de implementar o seu schema (npx sanity@latest schema deploy). Use-o quando precisar de ferramentas standardizadas, por exemplo, se o seu frontend já usa o Apollo Client ou se a sua equipa conhece GraphQL mas não GROQ.

Nós usamos exclusivamente o GROQ. É mais expressivo para dados do Sanity, e o plugin Vision torna a depuração de consultas trivial.

Portable Text: Conteúdo Rico Feito Corretamente

O Portable Text é a especificação do Sanity para texto rico estruturado. Em vez de armazenar conteúdo como strings HTML, armazena um array de blocos tipados, parágrafos, cabeçalhos, imagens, snippets de código, tabelas, cada um como um objeto JSON. Isto torna o conteúdo renderizável em qualquer framework, qualquer plataforma, qualquer formato.

A Estrutura de Dados

Eis como um parágrafo e um bloco de código se parecem como JSON Portable Text:

[
  {
    "_type": "block",
    "_key": "a1b2c3",
    "style": "normal",
    "markDefs": [],
    "children": [
      {
        "_type": "span",
        "_key": "d4e5f6",
        "text": "Here's an example of our pipeline config:",
        "marks": []
      }
    ]
  },
  {
    "_type": "codeBlock",
    "_key": "g7h8i9",
    "language": "typescript",
    "code": "export default defineConfig({ ... })"
  }
]

Cada bloco tem um _type e um _key. Os blocos de texto padrão usam "block" com children spans (que suportam marcas como negrito, itálico e ligações). Blocos personalizados, como o nosso codeBlock, chartBlock, table e inlineImage, usam o seu próprio _type e carregam campos estruturados.

Porque é que isto importa? Porque o HTML é um formato de renderização, não um formato de armazenamento. Se armazenar <h2>Título</h2><p>Algum <strong>texto</strong></p> na sua base de dados, bloqueou-se na renderização web. Não pode extrair isso limpidamente para uma app móvel, uma newsletter de email, um PDF ou a janela de contexto de um agente de IA. O Portable Text separa o conteúdo da apresentação. A especificação Portable Text é de código aberto, não é um lock-in da Sanity.

Blocos Personalizados em Produção

O nosso pipeline converte Markdown para Portable Text usando um script Python (scripts/md_to_portable_text.py). O conversor lida com blocos padrão, mais os nossos quatro tipos personalizados:

• table, usa o schema do plugin @sanity/table. Linhas e células armazenadas como dados estruturados.
• codeBlock, linguagem e código como campos separados, permitindo realce de sintaxe na renderização.
• chartBlock, tipo de gráfico, título, rótulos dos eixos, nomes das séries e pontos de dados como JSON estruturado. O frontend renderiza estes com Chart.js.
• inlineImage, texto alt, fonte e legenda opcional como campos separados.

Esta estrutura significa que podemos consultar todos os exemplos de código no nosso blog (*[body[]._type == "codeBlock"]), encontrar posts com gráficos ou extrair todas as imagens com texto alt em falta, tudo através do GROQ.

Renderização de Portable Text

No frontend, use @portabletext/react (ou os equivalentes Svelte/Vue). Regista componentes personalizados para cada tipo de bloco:

import { PortableText } from '@portabletext/react'

const components = {
  types: {
    codeBlock: ({ value }) => (
      <pre className={`language-${value.language}`}>
        <code>{value.code}</code>
      </pre>
    ),
    chartBlock: ({ value }) => <Chart data={value} />,
    inlineImage: ({ value }) => (
      <figure>
        <img src={value.src} alt={value.alt} />
        {value.caption && <figcaption>{value.caption}</figcaption>}
      </figure>
    ),
  },
}

// In your component:
<PortableText value={post.body} components={components} />

Esse é o pipeline de renderização completo. O componente PortableText lida com blocos padrão (parágrafos, cabeçalhos, listas, marcas) automaticamente. Apenas define componentes personalizados para os seus tipos personalizados.

Conteúdo Multilingue com Sanity CMS

O Sanity suporta conteúdo multilingue através de localização ao nível do documento (documentos separados por idioma ligados por uma referência canónica) ou localização ao nível do campo (campos traduzidos dentro de um documento). A localização ao nível do documento funciona melhor para SEO e publicação em larga escala, é o que usamos no nosso pipeline de 10 idiomas.

Localização ao Nível do Documento vs ao Nível do Campo

Escolhemos a localização ao nível do documento porque cada tradução obtém o seu próprio slug, o seu próprio URL e os seus próprios metadados. A versão turca de um post sobre Supabase vs Firebase obtém o slug supabase-firebase-karsilastirma, turco adequado, não um hack de parâmetro de URL.

A Nossa Arquitetura de Pipeline de 10 Idiomas

Eis como funciona o nosso pipeline automatizado: escrevemos um post em inglês, depois traduzimos para 9 idiomas adicionais (alemão, francês, holandês, espanhol, turco, italiano, sueco, norueguês, árabe). Cada tradução passa pela conversão de Markdown, geração de Portable Text e publicação via API do Sanity.

A arquitetura parece-se com isto:

1. Escrever, Markdown em inglês com frontmatter YAML
2. Traduzir, tradução por IA para 9 idiomas (verificada quanto à completude e diacríticos)
3. Converter, script Python converte cada ficheiro .md para JSON Portable Text
4. Publicar, chamadas API para o Sanity: criar documento, carregar imagens, patch de referências

Cada documento tem um campo language e uma referência canonicalPost que aponta para o original em inglês. Eis a consulta GROQ para obter um post e todas as suas traduções:

// Fetch a post and all its translations
*[_type == "post" && slug.current == "sanity-cms-guide" && language == "en"][0]{
  title,
  language,
  "translations": *[
    _type == "post" &&
    canonicalPost._ref == ^._id
  ]{
    title,
    language,
    "slug": slug.current
  }
}

O lado do schema é direto, um campo language com um enum de idiomas suportados:

defineField({
  name: 'language',
  title: 'Language',
  type: 'string',
  options: {
    list: [
      { title: 'English', value: 'en' },
      { title: 'German', value: 'de' },
      { title: 'French', value: 'fr' },
      { title: 'Dutch', value: 'nl' },
      { title: 'Spanish', value: 'es' },
      { title: 'Turkish', value: 'tr' },
      { title: 'Italian', value: 'it' },
      { title: 'Swedish', value: 'sv' },
      { title: 'Norwegian', value: 'no' },
      { title: 'Arabic', value: 'ar' },
    ],
  },
  validation: (Rule) => Rule.required(),
})

Uma armadilha que aprendemos da maneira difícil: publique o documento em inglês primeiro, depois faça patch das referências canonicalPost nas traduções usando o ID do documento publicado, não o prefixo drafts.. O Sanity trata documentos de rascunho e publicados como entidades separadas internamente.

Para mais detalhes sobre como este pipeline se liga ao Model Context Protocol, veja a próxima secção.

Funcionalidades de IA do Sanity: MCP, Canvas e Contexto do Agente

O Sanity posiciona-se como o sistema operativo de conteúdo para a era da IA. As principais funcionalidades de IA incluem um servidor MCP para agentes de IA lerem e escreverem conteúdo, Canvas para edição assistida por IA dentro do Studio e Agent Context para agentes de IA de produção consultarem conteúdo estruturado com consciência do schema.

Integração do Servidor MCP

O servidor MCP do Sanity permite que agentes de IA, Claude Code, Cursor, Windsurf e outros, interajam programaticamente com o seu espaço de trabalho Sanity. Os agentes podem ler schemas, executar consultas GROQ, criar documentos e gerir conteúdo sem wrappers de API personalizados.

Usamos o servidor MCP do Sanity diariamente no nosso pipeline de conteúdo. Os nossos agentes de IA consultam o schema para compreender a estrutura do documento, obtêm posts existentes para encontrar oportunidades de linking interno e publicam novos documentos. O protocolo MCP dá aos agentes consciência do schema, eles sabem que campos existem, que tipos esperam e que regras de validação se aplicam. Se está a construir fluxos de trabalho de agentes de IA para negócios, este é um padrão poderoso.

Agent Context para IA de Produção

O Agent Context é uma funcionalidade separada para integrações de IA de grau de produção. Ao contrário do servidor MCP (que é desenhado para ferramentas de developer), o Agent Context fornece acesso de leitura apenas, com scope, para agentes de IA que precisam de consultar o seu conteúdo em runtime, pense em chatbots, motores de recomendação ou sistemas de personalização de conteúdo.

A diferença importa: o MCP é para workflows de build-time e editoriais (ferramentas de desenvolvimento conscientes do schema), enquanto o Agent Context é para acesso a conteúdo em runtime com autenticação adequada e limitação de taxa.

O conteúdo estruturado do Sanity dá-lhe uma vantagem real aqui. Um site WordPress armazena conteúdo como blobs HTML, um agente de IA tem de analisar HTML para compreender o conteúdo. O Sanity armazena documentos JSON tipados com schemas definidos. Um agente pode consultar *[_type == "product" && category == "electronics"]{name, price, features} e obter dados limpos e estruturados de volta. Sem scraping, sem análise, sem adivinhação.

Como Usamos o Sanity na Techsy

Esta não é uma secção hipotética. Executamos o Sanity CMS em 4 websites de produção, publicando em 10 idiomas com um pipeline automatizado que construímos ao longo do último ano. Eis a arquitetura.

A Nossa Arquitetura de Pipeline de Conteúdo

O pipeline vai da pesquisa ao post publicado em todos os 10 idiomas:

1. Pesquisa, análise de palavras-chave, identificação de lacunas da concorrência, padrões SERP
2. Brief, especificação de escrita estruturada com orientação de secções, contagens de palavras, links internos
3. Escrever, produzir Markdown em inglês com frontmatter YAML
4. Converter, script Python transforma Markdown em JSON Portable Text com os nossos 5 tipos de bloco personalizados
5. Publicar, chamadas API para o Sanity: documento createOrReplace, carregar imagens para a CDN do Sanity, patch de referências de autor/categoria
6. Traduzir, tradução por IA para 9 idiomas, verificada quanto à completude
7. Publicar traduções, mesmo fluxo de converter/publicar por idioma, com referência canonicalPost patched para o original em inglês

O schema personalizado suporta tipos block, table, codeBlock, chartBlock e inlineImage, todos definidos como objetos de schema de produção do Sanity com regras de validação. Entre as ferramentas de IA para startups que testámos, este pipeline baseado no Sanity tem sido o mais fiável para conteúdo estruturado em escala.

Lições de Mais de 400 Peças Publicadas

Algumas coisas que gostaríamos que alguém nos tivesse dito:

A ordem do patch de referências importa. As referências do Sanity não podem apontar para documentos que ainda não existem. Publique o post em inglês primeiro, depois crie traduções com canonicalPost a apontar para o ID publicado do documento em inglês. Partimos isto várias vezes no início.

A implementação do schema é por espaço de trabalho. Se executa vários projetos Sanity (nós executamos 4), precisa de implementar schemas em cada um separadamente: npx sanity@latest schema deploy por configuração de projeto.

O nível gratuito é real. Executámos dois dos nossos quatro sites no plano gratuito durante meses. 20 utilizadores, 500K pedidos de API/mês, 100K pedidos de CDN, isso é suficiente para um site de produção real, não apenas um projeto de brincadeira.

A conversão de Portable Text é o gargalo. Markdown para Portable Text não é trivial. Listas aninhadas, tabelas dentro de blockquotes, blocos de código com caracteres especiais, casos extremos por todo o lado. Temos iterado sobre o nosso script conversor há meses.

Precisa de ajuda para configurar o Sanity para o seu projeto? Construímos pipelines de conteúdo multilingues para 4 sites de produção. Obtenha uma consulta gratuita

Detalhe dos Preços do Sanity CMS

O Sanity oferece três planos: Free (20 utilizadores, 500K pedidos de API/mês), Growth ($15/utilizador/mês com funções avançadas e rascunhos agendados) e Enterprise (preço personalizado com SLA e funcionalidades de conformidade). O nível gratuito é o mais generoso no mercado de CMS headless.

No nível gratuito, executamos dois dos nossos sites sem atingir limites. O plano Growth a $15/utilizador/mês adicionou acesso baseado em funções (importante assim que tivemos editores não técnicos) e publicação agendada. Os Viewers são gratuitos no Growth, o que é um toque agradável, não é penalizado por dar acesso de leitura às partes interessadas.

Como se compara aos concorrentes?

O nível gratuito de 20 utilizadores do Sanity é excepcional. O Contentful limita-o a 1 utilizador no gratuito e salta para $300/mês para o seu plano Team. Se é uma startup ou uma pequena equipa, o plano gratuito do Sanity permite-lhe executar cargas de trabalho de produção reais sem gastar nada.

O Sanity também oferece um programa para startups que dá às startups elegíveis um ano de acesso gratuito ao Growth. Vale a pena candidatar-se se se qualificar.

Perguntas Frequentes

O que é o Sanity CMS e como funciona?

O Sanity CMS é uma plataforma de conteúdo headless que armazena documentos JSON estruturados num backend gerido chamado Content Lake. Edita conteúdo através do Sanity Studio (uma aplicação React personalizável), consulta-o com GROQ ou GraphQL e renderiza-o em qualquer framework de frontend. O conteúdo sincroniza em tempo real em todos os clientes ligados.

O Sanity CMS é gratuito?

Sim. O nível gratuito do Sanity inclui 20 utilizadores, 500K pedidos de API por mês e 100K pedidos de CDN, o plano gratuito mais generoso entre as plataformas de CMS headless. O plano Growth custa $15 por utilizador por mês e adiciona acesso baseado em funções, publicação agendada e limites mais elevados. O preço Enterprise é personalizado.

Qual é a diferença entre Sanity e Contentful?

O Sanity usa schema-as-code (os schemas vivem no seu codebase), GROQ para consultas e um Studio de código aberto totalmente personalizável. O Contentful usa modelação de conteúdo baseada em GUI, GraphQL e um editor alojado com menos personalização. O nível gratuito do Sanity inclui 20 utilizadores contra 1 do Contentful. O Contentful tem um marketplace de plugins maior.

O Sanity CMS é bom para iniciantes?

O Sanity Studio é intuitivo para editores de conteúdo, a experiência de edição não requer conhecimento técnico. No entanto, a configuração de schemas requer proficiência em JavaScript ou TypeScript. O Sanity fornece documentação excelente, modelos de projeto e um Slack da comunidade com suporte ativo. Comece com npm create sanity@latest e um modelo de blog.

Posso autoalojar o Sanity?

O Sanity Studio é totalmente autoalojável porque é uma aplicação React de código aberto. Pode implementá-lo na Vercel, Netlify ou qualquer provider de hospedagem estática. O backend Content Lake é um serviço gerido, não existe opção de autoalojamento para a camada de dados. Esta é uma troca: obtém zero gestão de infraestrutura mas nenhum controlo de dados on-premises.

Que tipo de base de dados usa o Sanity?

O Content Lake do Sanity não é uma base de dados SQL ou NoSQL tradicional. É um repositório de documentos gerido que armazena conteúdo como JSON estruturado com uma camada de consulta GROQ por cima. Não interage diretamente com a base de dados subjacente, interage através das APIs do Sanity. Os documentos têm histórico de versões completo e sincronização em tempo real integrados.

O Sanity CMS é de código aberto?

O Sanity Studio é de código aberto sob a licença MIT, pode fazer fork, personalizá-lo e autoalojá-lo. O backend Content Lake é SaaS proprietário. A especificação da linguagem de consulta GROQ também é de código aberto, publicada no GitHub. A especificação Portable Text também é de código aberto, mantida em portabletext.org.

O que é o Portable Text no Sanity?

O Portable Text é a especificação do Sanity para texto rico estruturado. Em vez de armazenar conteúdo como strings HTML, representa parágrafos, cabeçalhos, imagens e blocos personalizados como objetos JSON tipados num array. Isto torna o conteúdo portável entre frameworks e plataformas. Pode definir tipos de bloco personalizados como snippets de código, gráficos e tabelas com os seus próprios campos estruturados.

O que é o GROQ e como é diferente do GraphQL?

GROQ (Graph-Relational Object Queries) é a linguagem de consulta nativa do Sanity. A sua sintaxe, *[filter]{projection}, é mais concisa que o GraphQL para dados do Sanity, com suporte integrado para junções via o operador -> e campos computados. O GraphQL também está disponível para equipas que preferem ferramentas standardizadas ou já usam o Apollo Client.

Como lida o Sanity com conteúdo multilingue?

O Sanity suporta localização ao nível do documento (documentos separados por idioma ligados por referências canónicas) e localização ao nível do campo (campos traduzidos dentro de um documento). A localização ao nível do documento é melhor para SEO porque cada tradução obtém o seu próprio URL e metadados. Usamos localização ao nível do documento para publicar em 10 idiomas com pipelines automatizados de tradução e publicação.