Entender a hospedagem de apps e como ela funciona

O App Hosting processa uma série complexa de tarefas em segundo plano para simplificar a implantação do app. Esta página descreve as principais partes desse fluxo de tarefas, fornecendo informações sobre os pontos em que você pode querer personalizar o fluxo de acordo com as necessidades do app.

Suporte do framework

O App Hosting oferece suporte de build e implantação sem necessidade de configuração para apps da Web desenvolvidos nestes frameworks:

  • Next.js 13 ou mais recente
  • Angular 17.2 ou mais recente

App Hosting identifica qual framework você está usando inspecionando o arquivo package-lock.json ou outro arquivo de bloqueio no repositório. Se você tentar implantar um aplicativo Node.js que não tenha um arquivo de bloqueio, o App Hosting não criará e executará o app. É possível criar package-lock.json executando npm install no diretório raiz.

Os adaptadores de framework App Hosting têm dois papéis principais:

  1. Eles analisam o código-fonte e todos os arquivos de configuração específicos do framework (como next.config.js) para entender o comportamento configurado do app.
  2. Eles executam o comando de build do app para gerar recursos estáticos e criar uma versão otimizada do app para produção.

Os adaptadores de framework criam seu app Node.js com npm run build, funcionando melhor com os scripts de build padrão para cada framework: next build para Next.js e ng build para Angular. O App Hosting vai tentar criar builds com comandos de build personalizados, mas não pode garantir o sucesso.

Como funciona a integração do repositório App Hosting

A conexão importante entre o repositório do GitHub e o back-end App Hosting é processada pelo Developer Connect, a plataforma de conectividade do Google Cloud para ferramentas externas de DevOps. Durante a criação de um back-end App Hosting, o fluxo de trabalho da interface do Developer Connect orienta você na instalação do app GitHub do Firebase. As principais etapas desse processo são:

  1. Você concede ao Developer Connect o papel Administrador do Secret Manager. Isso permite que o sistema armazene credenciais com segurança como "secrets" no Cloud Secret Manager.
  2. Você autoriza o app GitHub do Firebase a acessar seu repositório do GitHub.
  3. O Developer Connect armazena um token de autorização do GitHub dedicado no repositório do gerenciador de segredos do projeto. Não modifique nem exclua esse token.

Além disso, App Hosting se integra à API GitHub Checks para verificar os lançamentos. Essa verificação permite que você confira o status do seu lançamento no GitHub e depure o processo de implantação em caso de erros.

Integração com o Firebase e outros serviços do Google

App Hosting configura seus ambientes de criação e ambiente de execução para que você possa inicializar o SDK Admin do Firebase com o Google Application Default Credentials. Dessa forma, o back-end pode se comunicar com outros produtos do Firebase durante a criação e o deploy.

App Hosting locais

A implantação App Hosting cria os recursos de back-end em um local específico. Essa flexibilidade no local do app da Web tem vantagens importantes:

  • Melhor desempenho e latência reduzida, trazendo os dados geograficamente mais próximos dos usuários.
  • Uma falha catastrófica para App Hosting em uma região não afeta os apps da Web implantados em outras regiões.

Você pode escolher qualquer uma dessas regiões ao criar um back-end App Hosting no console ou na CLI Firebase:

  • us-central1 (Iowa)
  • asia-east1 (Taiwan)

A conta de serviço de back-end App Hosting

Durante a criação e no ambiente de execução, seu back-end App Hosting se autentica em outros serviços do Google com uma conta de serviço. Uma conta de serviço padrão para esses fins é criada na primeira vez que você ativa App Hosting em um projeto do Firebase:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

Essa conta de serviço se aplica a todos os back-ends por padrão e tem um conjunto mínimo de permissões para permitir que você crie, execute e monitore seu app. Ela também tem permissão para autenticar o SDK Admin com as credenciais padrão do aplicativo para realizar operações como o carregamento de dados de Cloud Firestore. Consulte Papéis do App Hosting do Firebase.

Caso seu app precise interagir com outros serviços do Google no tempo de build ou em um back-end em execução, personalize a conta de serviço padrão adicionando papéis. Por exemplo, se o app exigir permissões para a Vertex AI, talvez seja necessário adicionar roles/aiplatform.user ou algum papel relacionado.

Principais termos e definições

  • Back-end: a coleção de recursos gerenciados que App Hosting cria para criar e executar seu app da Web.
  • Lançamento: uma versão específica do seu app ativo, vinculada a uma confirmação do git.
  • Ramificação ativa: a ramificação do repositório do GitHub que é implantada no URL ativo. Geralmente, é a ramificação em que as ramificações de recursos ou de desenvolvimento são mescladas.

Limitações e problemas conhecidos

A visualização de App Hosting tem algumas limitações conhecidas:

  • A exclusão de back-ends não está funcionando.
  • Em alguns casos, um back-end App Hosting pode retornar mensagens Intermittent connection error no URL do app. Uma correção estará disponível em uma versão posterior.
  • Os cabeçalhos Cache-Control são modificados para limitar os caches do CDN a 60 segundos. No futuro, quando o App Hosting puder limpar rapidamente o cache na implantação, esse limite será removido.
  • A otimização de imagens é feita em Cloud Run por padrão, e as imagens otimizadas não são mantidas. Recomendamos desativar a otimização ou especificar manualmente um carregador até que uma solução melhor esteja disponível.
  • Os arquivos estáticos sem cache são exibidos fora de Cloud Run. Em uma versão posterior, eles serão armazenados e exibidos da origem App Hosting para melhor desempenho.
  • É possível que as SKUs App Hosting não apareçam na página de uso de back-end no console do Firebase. Eles estarão disponíveis em uma próxima versão.
  • O console Firebase pode mostrar intermitentemente um erro "O build não foi encontrado e é inválido" na criação do back-end.
  • Atualmente, todos os back-ends no mesmo projeto compartilham uma organização/conta do GitHub. Eles podem ser conectados a diferentes repositórios nessa organização/conta. Para criar back-ends conectados a diferentes contas do GitHub, coloque-os em projetos separados.
  • O middleware, as substituições e os redirecionamentos do Next.js são executados em Cloud Run, atrás da CDN. Como isso não protegerá as respostas armazenadas em cache, defina diretivas de controle apropriadas para o conteúdo que você estiver renderizando.