O Starlight nasceu com a missão de simplificar o processo de gerenciamento de conteúdo ao máximo, permitindo que qualquer pessoa possa criar e gerenciar conteúdo com pouco ou nenhum treinamento necessário. Ao longo do caminho, mudamos a maneira como alguns recursos funcionavam para facilitar cada vez mais o processo de encontrar e gerenciar conteúdo.

Quando foram adicionados ao Starlight, os Singletons&nbsp;possibilitaram criar conteúdo único numa área de trabalho, como as páginas de um site ou os menus de uma aplicação para celulares. Apesar de serem usados em praticamente todas as aplicações feitas com o Starlight, recebemos vários comentários ao longo do tempo de que encontrar conteúdo guardado em Singletons era difícil, e que o próprio nome Singleton era confuso.

Não mais! Com a atualização 2025.2, simplificamos a maneira que conteúdo único é mostrado na interface do Starlight, além de adicionar várias outras melhorias na edição de conteúdo.

Mudamos a maneira de como Singletons são organizados na interface do Starlight, e a maior mudança é no nome: Singletons agora se chama Seções. Apesar do nome diferente, o conteúdo dos seus Singletons, agora chamados de Seções, permanece intacto.

Embora a palavra <a href="https://pt.wikipedia.org/wiki/Singleton">Singleton</a>&nbsp;tenha um significado claro para pessoas com experiência em programação, pessoas com menos ou nenhuma experiência relataram achar o nome confuso e sem sentido, o que nos levou a procurar um nome melhor para esse tipo de conteúdo.

Além da mudança do nome, adicionamos categorias mais claras às Seções para facilitar a organização de conteúdo relacionado.

Para resumir melhor essas alterações, dê uma olhada nesse antes e depois da interface do Starlight:

Talvez você tenha notado que o menu lateral na segunda imagem tem uma nova opção chamada "Páginas". Essa opção é um atalho no menu para facilitar o acesso às Seções dessa categoria.

Membros da sua área de trabalho com permissão para gerenciar categorias de Seções podem adicionar e remover esses atalhos livremente ao acessar a opção "Gerenciar categorias" na página de Seções. Para facilitar a adaptação de todos, adicionamos um atalho para a categoria principal de cada área de trabalho aos seus menus laterais automaticamente.

Além disso, todas as categorias de Seções podem ser visualizadas ao clicar no item "Seções" do menu lateral do Starlight:

Por último, para pessoas desenvolvedoras, nada mudou. Seções ainda serão chamadas de Singletons nas versões 1 e 2 das APIs do Starlight. Na versão 3, que será lançada no futuro, a nomenclatura será devidamente atualizada.

Singletons agoram se chamam Seções, além de várias melhorias no gerenciamento de conteúdo.

featured-imagepng-htS6gtQjsO

Novidades do Starlight 2025.2

Artigos

CMS é a sigla de “Content Management System”, ou sistema de gerenciamento de conteúdo em português. São softwares que formam a fundação de praticamente qualquer website ou aplicativo que você usa, onde seus conteúdos são criados, editados e gerenciados.

Por exemplo, o texto que você está lendo nesse exato segundo foi escrito e armazenado em um CMS (mais especificamente, no <a href="https://www.starlight.sh/">Starlight</a>). O principal trabalho do CMS é guardar esse conteúdo e mostrá-lo sempre que um leitor visita essa página.

A ideia de sistemas que gerenciam conteúdo é quase tão antiga quanto a ideia de websites, e CMSs comerciais começaram a ser vendidos nos anos 90. Décadas depois, esses sistemas são cada vez mais importantes, principalmente por conta da popularização de estratégias de conteúdo adotadas por empresas de todos os tamanhos e setores.

Se observarmos o cenário de tecnologias para criação de websites e aplicações nos últimos anos, podemos destacar algumas mudanças de paradigma: a popularização dos microsserviços, a criação da arquitetura serverless, e a explosão do JavaScript no frontend, servidor, e até nos dispositivos móveis.

Essas e outras mudanças de paradigma culminaram no aparecimento dos CMSs headless, que são a evolução natural dos CMSs tradicionais (também conhecidos como CMSs monolíticos). Mas, antes de conversarmos sobre CMSs headless, você sabe como um CMS tradicional funciona?

CMSs tradicionais, também chamados de monolíticos, contém todos (ou quase todos) os componentes necessários para a criação e o gerenciamento de um website e seu conteúdo.

Você deve conhecer o WordPress, certo? É o CMS mais utilizado no mundo, e sua vantagem é exatamente a de conter praticamente todos os componentes que você precisa para criar um website: uma interface para gerenciar conteúdo, temas para criar sites rapidamente, armazenamento de arquivos de mídia, dentre outros. Para começar, você só precisa de um servidor, uma cópia do WordPress e um banco de dados.

Se pensarmos em termos de arquitetura, CMSs tradicionais combinam o backend e o frontend dos websites em um só lugar, daí o nome monolítico. O back e o front são interligados e, por compartilharem código-fonte, utilizam a mesma linguagem de programação e ferramentas de desenvolvimento.

CMSs tradicionais como o WordPress, Joomla e Drupal ganharam espaço no começo dos anos 2000, quando a demanda de criação de websites disparou e pessoas e empresas não tinham como investir alto para criarem seus websites do zero. Porém, com o avanço das tecnologias de desenvolvimento web e a necessidade de criar aplicações cada vez mais rápidas, flexíveis e seguras, CMSs começaram a evoluir para uma arquitetura menos rígida, e daí nasceram os CMSs headless.

Diferente dos monolíticos, os CMSs headless não incluem um frontend. Em outras palavras, o objetivo principal de um CMS headless é de gerenciar o conteúdo de uma aplicação, independente dessa aplicação ser um website, um aplicativo de celular ou uma tela conectada em um aeroporto.

Nessa arquitetura, o frontend requisita conteúdo para o CMS via APIs, que geralmente o retorna no formato JSON. A partir daí, o trabalho do frontend é de exibir esse conteúdo para o usuário da maneira que preferir.

Dessa maneira, o frontend é totalmente independente do backend. Em termos de arquitetura, uma das principais vantagens é que, com essa separação de conceitos, pessoas desenvolvedoras podem criar frontends melhores e com maior agilidade, sem se preocupar com detalhes de implementação do backend, além de conseguirem conectar vários frontends no mesmo backend.

CMSs headless conferem várias vantagens em relação aos CMSs tradicionais. Essas são algumas delas:

Com o frontend independente do backend, você tem a liberdade de utilizar qualquer linguagem de programação ou ferramenta para desenvolver a interface que apresenta o conteúdo da sua aplicação.

No desenvolvimento web, frameworks como <a href="https://react.dev/">React</a> e <a href="https://vuejs.org/">Vue</a> ganharam ainda mais popularidade com o aparecimento de CMSs headless, já que conectar aplicações feitas com essas ferramentas a um CMS headless via APIs é uma tarefa trivial. Alguns CMSs headless oferecem ferramentas de desenvolvimentos para simplificar ainda mais essas conexões.

Ferramentas de desenvolvimento multi-dispositivo como o <a href="https://flutter.dev/">Flutter</a> e o <a href="https://reactnative.dev/">React Native</a> também viram opções muito atrativas, permitindo criar apenas uma aplicação para vários tipos de dispositivos, utilizando as mesmas APIs para requisitar conteúdo do backend.

Além disso, é possível “adicionar” conteúdo de um CMS headless a praticamente qualquer aplicação já existente, inclusive aplicações criadas com CMSs tradicionais como o WordPress. Isso permite que o conteúdo de uma aplicação feita com um CMS tradicional seja gradualmente migrada para um CMS headless.

Com a possibilidade de utilizar qualquer linguagem e framework para criar seus frontends, você tem a liberdade de escolher as ferramentas que mais fazem sentido para as pessoas que vão desenvolvê-los.

Por exemplo, ferramentas como o <a href="https://nextjs.org/">Next.js</a> e o <a href="https://www.gatsbyjs.com/">Gatsby</a> criam websites do zero em segundos, removendo praticamente todo o atrito gerado pela instalação e configuração de CMSs tradicionais ao iniciar um novo projeto. Com a base da aplicação criada, requisitar conteúdo de um CMS headless via APIs é simples, principalmente quando estes oferecem SDKs para simplificarem a conexão.

O tempo de desenvolvimento pode ser ainda menor se você utilizar modelos prontos para dar o pontapé inicial de um projeto, e alguns CMSs headless oferecem essa opção.

Ao se desvincular dos frontends, CMSs headless tendem a ser muito mais rápidos ao retornar conteúdo pelas suas APIs. Além disso, como o conteúdo é geralmente retornado em JSON, as respostas das APIs também são menores, retornando apenas o necessário para o frontend construir suas interfaces.

Consequentemente, frontends que requisitam dados de CMSs headless podem ter um desempenho muito melhor que aplicações feitas com CMSs tradicionais. Por exemplo, websites estáticos podem carregar instantaneamente ao serem acessados e mostrar uma interface provisória ao usuário, enquanto o conteúdo é requisitado pelo navegador ao CMS em paralelo, e atualizando a página após seu carregamento.

Ferramentas como o Next.js também permitem que páginas com o conteúdo carregado <a href="https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration">sejam salvas em cache dinamicamente</a> ao serem acessadas, possivelmente diminuindo o tempo de carregamento para míseros milissegundos, e diminuindo consideravelmente a quantidade de requisições feitas ao backend.

Já que acessar conteúdo de CMSs headless é apenas uma questão de fazer requisições para suas APIs, é possível criar várias aplicações que acessam o mesmo conteúdo. Dessa maneira, ao criar ou atualizar conteúdo no CMS, todas as aplicações que requisitam conteúdo a ele também se atualizam.

Por exemplo, se você precisa criar uma aplicação que funcione em vários dispositivos, como um website e aplicativos para dispositivos Android e iOS, todos esses frontends podem acessar o conteúdo de um mesmo CMS headless, mesmo que eles sejam criados com linguagens e ferramentas distintas, como JavaScript para a Web, Kotlin para Android e Swift para iOS.

Essa propriedade de CMSs headless não é útil apenas para simplificar o desenvolvimento das suas aplicações, mas também para as pessoas que vão gerenciar seus conteúdos. Criar e atualizar conteúdo em CMSs headless significa que todos os canais que consomem seu conteúdo também serão atualizados.

Ao acessar conteúdo via APIs, frontends que se comunicam com CMSs headless são potencialmente mais seguros, já que, geralmente, APIs de conteúdo são “somente leitura”.

Além disso, ao permitir que suas aplicações utilizem qualquer linguagem e framework, seus frontends podem ser criados com tecnologias mais recentes, e até emergentes, que tendem a ser mais seguras e com menos problemas e limitações do que as tecnologias usadas por CMSs tradicionais.

Na web, ferramentas como o Jekyll, o Next.js e o Gatsby popularizaram o conceito de websites estáticos, que são naturalmente mais seguros por não precisarem de um servidor para funcionar. Aliar essas ferramentas com um CMSs headless é o melhor dos dois mundos: você pode criar sites estáticos, sem a necessidade de um servidor, que consomem e renderizam conteúdo do CMS em tempo de build.

💡 Dica: Alguns CMSs headless suportam webhooks que podem instruir um website a ser reconstruído sempre que algum conteúdo for criado, atualizado ou removido. Ferramentas como o Next.js vão além e permitem que páginas específicas sejam <a href="https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration#on-demand-revalidation">reconstruídas sob demanda</a> individualmente, diminuindo o tempo de build.

Quais as desvantagens de um CMS headless?

Como toda tecnologia, CMSs headless também contam com algumas desvantagens:

Transicionar para um novo paradigma pode ser difícil no começo, e isso também é verdade quando falamos em transicionar entre CMSs tradicionais e headless. Criar aplicações com CMSs headless em mente pode ser complicado num primeiro contato já que, ao ter que se conectar com um backend separado, a arquitetura dessas aplicações pode ser bem diferente do que esperamos ao utilizarmos CMSs tradicionais.

Além disso, a liberdade de utilizar qualquer linguagem de programação e ferramenta pode causar <a href="https://pt.wikipedia.org/wiki/Paralisia_por_an%C3%A1lise">paralisia por análise</a> até nas pessoas desenvolvedoras mais experientes. Nesse caso, é importante lembrar que novos projetos não precisam ser necessariamente criados com tecnologias novas ou complexas.

Se seu time de desenvolvimento se sente confortável utilizando tecnologias mais tradicionais como PHP e jQuery, não tenha medo de criar projetos aliando essas tecnologias com um CMS headless. Para aplicações já existentes, também existe a possibilidade de migrar seu conteúdo para um CMS headless aos poucos, atualizando a aplicação gradualmente para requisitar conteúdo do novo CMS.

Alguns CMSs tradicionais permitem que pessoas e empresas criem sites com pouco esforço, sem se preocupar em escrever código, mas abrindo mão da flexibilidade. Em contrapartida, CMSs headless maximizam a flexibilidade no desenvolvimento, mas exigem que alguém desenvolva as aplicações que os utilizam como fonte de conteúdo.

Esse requisito pode ser um impeditivo para pessoas que não sabem ou não querem programar suas aplicações, ou para empresas que não podem investir em uma ou mais pessoas programadoras para criá-las.

Alguns CMSs headless remediam essa desvantagem oferecendo modelos prontos para tipos comuns de aplicação, como sites institucionais, blogs e landing pages, que já incluem o código necessário para se conectar ao CMS, minimizando o tempo de desenvolvimento necessário para colocar uma aplicação no ar.

Você também pode procurar por agências de desenvolvimento que trabalham com o CMS headless que você quer utilizar. Algumas plataformas CMS gerenciadas firmam parcerias com agências certificadas para usarem suas ferramentas.

O <a href="https://www.starlight.sh/">Starlight</a> é um CMS headless gerenciado altamente flexível projetado para ter uma experiência de desenvolvimento simples e uma interface de gerenciamento de conteúdo fácil de usar, além de ter planos acessíveis criados especialmente para o mercado brasileiro e templates para criar websites personalizados em tempo recorde.

Além das vantagens que discutimos nas seções anteriores, o Starlight conta com vários recursos úteis:

O Starlight permite que você crie aplicações até 60% mais rápido quando comparado a CMSs tradicionais. Para começar a usá-lo numa nova aplicação, basta definir a estrutura do conteúdo em poucos minutos, utilizando um editor de campos drag-and-drop fácil de usar. Com a estrutura do conteúdo definida, o desenvolvimento da aplicação e a criação do conteúdo em si podem acontecer paralelamente.

Com modelos, você pode definir estruturas de conteúdo que se repetem numa aplicação, como postagens, notícias, eventos, cursos, etc. Com singletons, defina a estrutura de páginas e outros blocos de conteúdo únicos na sua aplicação. E com as coleções, é fácil criar listas de conteúdo, como galerias de imagem e listas de links.

Com SDKs oficiais para <a href="https://js.sdk.starlight.sh/">JavaScript</a>, <a href="https://react.sdk.starlight.sh/">React</a> e <a href="https://github.com/starlightcms/next-sdk">Next.js</a>, requisitar conteúdo do Starlight se torna uma tarefa simples. Requisite conteúdo com poucas linhas de código:

E com templates oficiais, é possível criar aplicações do zero a produção em tempo recorde. Os templates do Starlight usam os SDKs oficiais para criar websites em segundos, da estrutura do conteúdo no Starlight até o código-fonte necessário para rodar sua aplicação.

Com os formulários do Starlight, você pode receber dados dos usuários das suas aplicações facilmente. Usando o mesmo editor drag-and-drop que modelos e singletons, você pode definir quais campos e dados seu formulário deve salvar no Starlight. Assim, você pode criar formulários de contato ou de listas de e-mail em minutos.

Com o SDK do Starlight para React, você pode adicionar formulários do Starlight nas suas aplicações em segundos. O SDK renderiza seus formulários automaticamente, sem a necessidade de definir os campos do formulário no código explicitamente.

Pré-visualize conteúdo não publicado ao vivo na sua aplicação. Após configurado, você pode visualizar conteúdo diretamente na sua aplicação antes de criar ou atualizar entradas. E com o histórico de alterações, fica fácil de voltar a uma versão antiga do seu conteúdo a qualquer momento, sem perder nenhuma alteração.

Crie papéis para os membros da sua organização e defina suas permissões com controles granulares. Assim, é possível convidar membros sem receio de que alguém consiga alterar a estrutura do conteúdo das suas aplicações sem querer.

O que é e como funciona um CMS headless? Descubra e compare com um CMS tradicional.

Novidades do Starlight 2025.2

Copyright © 2025 Starlight

Starlight