O que é frontstage e por que as pessoas confundem isso o tempo todo
Você provavelmente já ouviu esse termo em reuniões sobre arquitetura de plataformas ou serviços internos. Frontstage é a camada de interface que um usuário final vê e interage. É o que fica do lado de fora, do lado de dentro não existe nada visível. Em termos práticos, imagine uma empresa de tecnologia com uma plataforma de autoatendimento onde colaboradores pedem um acesso novo. O formulário que eles preenchem, os botões, as opções de busca — isso é frontstage. Por trás disso, existindo sem que ninguém veja, tem toda uma cadeia de automações, aprovações, integrações com outros sistemas e talvez um agente humano revisando casos borderline. Isso é o backstage.
O conceito não é difícil. O difícil é quando a equipe de produto, a de infraestrutura e a de atendimento entram numa sala e cada um acha que está falando de uma coisa diferente. Isso acontece porque frontstage não é um termo técnico nativo de nenhuma linguagem de programação ou framework específico. Veio de áreas como Service Design e depois entrou no universo de Platform Engineering e SRE (Site Reliability Engineering).
o que significa frontstage na prática
Na verdade, na indústria de tecnologia hoje, frontstage ganhou um significado bem mais concreto do que a definição original. Estamos falando de uma arquitetura específica onde uma interface web ou aplicativo entrega experiências compostas a partir de múltiplas origens. Funciona assim: em vez de cada equipe construir do zero seu próprio painel com backend próprio, banco de dados próprio e autenticação própria, existe uma camada de frontstage que consome APIs unificadas expostas pelo que chamamos de Product Surface ou internal developer portal. O frontstage orquestra dados de várias fontes e os apresenta num único ponto de acesso coerente.
Algo que poucas pessoas mencionam: frontstage não é sinônimo de portal de serviços. Um portal de serviços pode perfeitamente existir sem uma estratégia de frontstage. A diferença é sutil mas importante. Frontstage pressupõe composição de dados, abstração da complexidade interna e uma experiência intencionalmente desenhada para um tipo de usuário. Um portal genérico muitas vezes é apenas uma lista de links para outras ferramentas que cada um precisa aprender a usar separadamente. Aqui vai uma experiência que tive recentemente e que ilustra bem onde a coisa costuma dar errado. Estávamos consolidando o acesso interno de uma empresa com cerca de 8.000 colaboradores usando uma plataforma do tipo Backstage da Spotify como base. O time de produto decidiu que o frontstage seria uma interface personalizada com busca unificada, catálogo de serviços e dashboards. Até aí simples. O problema veio quando percebemos que o tempo de resposta do frontstage para buscas no catálogo de serviços passava de 4 segundos em 60% das requisições.
A causa não era o frontstage em si. Era que cada serviço no catálogo vinha com campos customizados diferentes, alguns com metadados ausentes, e o sistema de busca fazia consultas em cascata para validar permissões de cada usuário contra múltiplos provedores de identidade. A solução foi criar uma camada de pré-agregação com cache de 30 segundos, indexar os campos mais consultados separadamente e eliminar a validação em tempo real de permissões para resultados que só precisavam ser lidos, não modificados. O tempo caiu para 400ms médios. A validação em tempo real ficou restrita apenas a operações de escrita. O que eu quero destacar aqui é que a complexidade raramente está na interface. Está nos dados que ela consome e na forma como esses dados são agregados. Você pode ter o frontstage mais bonito do mundo, mas se ele depender de APIs síncronas encadeadas sem fallback, ele vai ser lento independentemente de quão bom seja o design.
Como construir um frontstage funcional
Vamos começar pelo que realmente importa: arquitetura. Um frontstage eficiente precisa de pelo menos três camadas separadas. A primeira é a camada de descoberta. Aqui você define como os usuários encontram serviços, ferramentas, documentação ou pessoas. Isso pode ser um catálogo, um mapa de serviços, um sistema de buscas com filtros. A maioria dos times erra nessa parte achando que o problema é a qualidade da busca. Na prática, o problema é quase sempre a qualidade dos metadados dos serviços que estão sendo buscados. Se um serviço não tem descrição, dono definido, SLA claro e tags consistentes, a melhor busca do mundo não vai ajudar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A segunda camada é a camada de composição. Aqui é onde os dados de múltiplas origens são reunidos e apresentados de forma coerente. Você precisa de um orquestrador que consome múltiplas APIs, trata falhas individuais sem derrubar a resposta toda, normaliza formatos diferentes e entrega algo que parece vir de um único sistema. Ferramentas como BFF (Backend for Frontend) são úteis nesse contexto. Não é obrigatório, mas ajuda muito quando você tem 15 fontes de dados diferentes que precisam ser apresentadas em 3 telas diferentes. A terceira camada é a camada de interação. O que o usuário efetivamente vê: formulários, botões, navegação, notificações, estados de loading, erros amigáveis. Essa parte recebe muita atenção e, honestamente, deveria receber menos. A maioria dos problemas de frontstage que eu vejo em produção não é culpa do design da interface. É culpa de uma API que não responde, de um fluxo de aprovação truncado ou de dados inconsistentes vindo do sistema original.
Um detalhe importante sobre stack tecnológica: não existe uma resposta certa. Já vi frontstage construído com React, Vue, Angular, até com frameworks server-side como Next.js e Nuxt. O que importa é a capacidade de integração, performance de carregamento e manutenibilidade. Se você escolher uma tecnologia que seu time não domina, o frontstage vai virar um problema em 6 meses. Escolha o que seu time sabe fazer bem. Sobre autenticação, isso merece um parágrafo separado porque é onde tudo mais desandae facilmente. Frontstage precisa resolver a identidade do usuário de forma transparente. Se cada serviço consultado exigir login separado, sua experiência é ruins. O ideal é usar SAML, OAuth 2.0 ou OpenID Connect como protocolo único de auth. Token único, validação centralizada, permissões gerenciadas em um só lugar. Já passei por projetos onde 12 diferentes sistemas de identidade precisavam ser integrados. Isso levou 4 meses e gerou 3 incidentes de segurança. Centralize ou não tente.
Erros comuns que eu vejo todo dia
Um erro muito frequente é tratar frontstage como um projeto único com prazo de entrega. Isso não funciona. Frontstage é um produto que precisa evoluir. Ele nunca vai estar pronto. A interface muda conforme novos serviços são adicionados, novos fluxos são criados, novos tipos de usuário surgem. Se você tratar como algo que se constrói e se entrega, vai entregar algo que já estará defasado. Outro erro grave é não prever o caso em que o backend falha. Frontstage que não tem tratamento de erro, timeout configurado, fallback ou estado de degraded mode é uma bomba. Quando uma API sob jacente está instável, seu frontstage não pode simplesmente quebrar junto. Configure timeouts sensíveis (3 a 5 segundos é razoável para a maioria das operações de leitura), implemente retry com backoff exponencial, e tenha fallbacks claros. Se um serviço de catálogo não responde, o usuário ainda deve conseguir ver o que já está em cache ou pelo menos receber uma mensagem útil em vez de uma tela em branco.
Performance também merece atenção séria. Métricas que eu uso como referência: Time to Interactive abaixo de 3 segundos, First Contentful Paint abaixo de 1 segundo, Latência de API medianas abaixo de 500ms. Se seus números estão acima disso, o problema provavelmente não é o frontstage em si. Verifique a camada deComposition e a qualidade das integrações. Um problema específico que aparece com frequência é a inconsistência de dados entre o frontstage e as fontes originais. Usuários começam a reclamar que veem informações erradas. Isso quase sempre acontece porque o frontstage está lendo dados que não são atualizados em tempo real, ou porque alguma ETL está falhando silenciosamente. Implemente monitoramento de data freshness: se um dado não foi atualizado há mais de X horas, o frontstage deve avisar o usuário. Isso evita que ninguém tome decisões com base em informações desatualizadas.
Quando frontstage não é a solução certa
Vou ser direto: frontstage não faz sentido para todas as situações. Se você tem menos de 20 serviços internos, equipes pequenas e poucas integrações, um portal simples ou até mesmo uma página com links organizados resolve. A complexidade de construir um frontstage robusto custa tempo, dinheiro e especialização. O breakpoint real onde vale a pena investir é quando você começa a ter problemas reais de descoberta, consistência e onboarding — normalmente acima de 50 serviços internos e mais de 5 equipes diferentes mantendo cada um. Também não funciona bem em organizações onde a governança de dados é fraca ou inexistente. Frontstage expõe a realidade dos seus serviços. Se seus serviços não têm donos definidos, documentação atualizada ou SLAs conhecidos, o frontstage vai apenas tornar essa falta de estrutura visível de forma muito mais clara do que ela já era.
Alternativas existem. Para times menores, um internal developer portal mais simples com ferramentas como o próprio Backstage fora do modo frontstage pode ser suficiente. Para organizações que só precisam de autoatendimento, um service catalog integrado a uma plataforma de ITSM como ServiceNow ou Jira Service Management pode cobrir as necessidades sem a complexidade adicional. Uma última consideração sobre mensuração. Você precisa saber se o frontstage está funcionando. Métricas que eu recomendo acompanhar: tempo médio para completar um fluxo do início ao fim, taxa de sucesso de operações, número de tickets de suporte gerados por problemas que poderiam ser resolvidos pelo próprio usuário, NPS ou CSAT específico do frontstage, e tempo de atividade do serviço. Se você não estiver medindo isso, não sabe se está entregando valor ou apenas custo.
