A realidade do arranque a frio
Embora o setor tenha feito grandes avanços na minimização dos tempos de inicialização, especialmente com redes de borda leves, as funções tradicionais sem servidor baseadas em Node.js ainda apresentam inicializações a frio. Se uma função não tiver sido invocada recentemente, ou se picos de tráfego exigirem que uma nova instância seja ativada simultaneamente, a primeira solicitação sofrerá um impacto perceptível na latência à medida que o contêiner for provisionado e o código for carregado.
API em vez de RAM
Em um ambiente de servidor tradicional, você pode armazenar dados transitórios na RAM global, permitindo que solicitações subsequentes acessem o contexto compartilhado instantaneamente. No modelo sem servidor, cada solicitação pode atingir um novo contêiner. Portanto, todos o contexto compartilhado deve ser externalizado. Embora o Firestore atue de maneira brilhante como gerente de estado, contar com um banco de dados para armazenamento em cache efêmero de alta frequência, abaixo de um milissegundo, introduz latência de rede e custos por operação. Dito isso, usar um estado de RAM compartilhado em um servidor também não é trivial, a menos que você esteja usando um único servidor de aplicativos e VM (porque os requisitos de alta disponibilidade ou failover diminuirão o ganho de RAM em um servidor tradicional).
Ajuste de velocidade e controle
Cada decisão arquitetônica é uma troca. Não existem escolhas gratuitas. Ao adotar a pilha GitHub, Vercel e Firestore, você está maximizando explicitamente a velocidade dos recursos em vez do controle refinado.
