Pular para o conteúdo principal

Functions

Última atualização: 16 de julho de 2026

A lógica de servidor do seu jogo — rodando globalmente, escalando sozinha. Escreva em TypeScript, JavaScript, Python ou Go, e implante com a CLI do PlayServ — sem infraestrutura para gerenciar.

MultirregiãoAuto-scalingOverrides por envLogs em tempo real

A seção Functions fica em Engineering, na barra lateral do Project. Cinco abas dão conta de tudo: Overview, Functions, Bindings, Logs e History.

informação

As Functions são criadas e implantadas com a CLI do PlayServ, rodando a partir do seu projeto local. Assim que um deploy termina, a Function aparece nas abas abaixo com status, métricas e logs ao vivo.

Overview​

Um dashboard de saúde ao vivo de todas as suas Functions no Environment atual.

Functions — aba Overview com métricas ao vivo

Functions live
Quantidade de Functions aceitando tráfego neste momento. Um delta abaixo mostra quantas foram adicionadas recentemente.
Replicas running
Total de instâncias ativas em todas as regiões, detalhado por número de regiões e por quantas estão escalando ativamente.
Invocations 24h
Contagens de chamadas das últimas 24 horas e do período anterior lado a lado, com um sparkline e um delta de tendência contra o período anterior.
Error rate 24h
Percentual de invocações que falharam. Verde com within target quando saudável; vermelho quando elevado, com um delta mostrando a direção da mudança.
P95 latency 24h
Tempo de resposta no percentil 95. within target confirma que você está dentro do seu SLA. Um sinal rápido de regressão depois de cada deploy.

Lista de Functions​

Todas as Functions do Project, em uma tabela só.

Functions — aba com a lista de Functions

Busque por nome, descrição ou linguagem. Use os dropdowns Status e Runtime para filtrar — útil em projetos maiores, onde você só precisa ver, digamos, as Functions Python que estão falhando.

Cada linha traz o que importa de relance:

Identidade

Selo da linguagem (Js, Py, Go, C#), nome da Function e uma descrição de uma linha vinda do manifesto.

Saúde

Selo de status, contagem de réplicas (rodando / desejadas), invocações no período atual e no anterior de 24h, taxa de erro, latência P95 e a data do deploy com o SHA do commit.

Status​

live

Implantada e servindo tráfego ativamente. O estado saudável normal.

staged

Implantada, mas sem receber tráfego. Use para testes canário antes de promover para live.

failing

As réplicas estão caindo ou os erros passaram do limite configurado. Precisa de atenção.

disabled

Parada manualmente. Todas as réplicas estão fora; a Function não aceita invocações.

Clique em + New function no canto superior direito para criar uma Function a partir de um template. Este recurso ainda está por vir — use a CLI para criar Functions novas.

Painel de detalhes da Function​

Clique em qualquer linha para abrir o painel de detalhes à direita. O cabeçalho mostra o nome da Function, a política de escala, a data do último deploy com o SHA do commit, e o status ao vivo. Quatro abas dão controle total.

Status​

Saúde ao vivo de uma única Function. Três áreas de estatística no topo:

Detalhe da Function — aba Status com réplicas e At a glance

Status & Auth
Status atual com a data do deploy. Auth mostra o que quem chama precisa ter — none para endpoints públicos, ou player para os protegidos.
Last Invocation
Há quanto tempo a Function foi chamada pela última vez e a latência P95 daquela janela.
Replicas & Calls
Contagem de réplicas rodando, invocações de 24h divididas em dois períodos, e a taxa de erro de 24h com a contagem total de erros.

Replicas lista cada instância ativa com ID, região, uptime, memória e CPU. Clique em Scale para ajustar a contagem de réplicas na hora — sem redeploy. Clique em qualquer linha de réplica para expandir At a glance:

Status
Estado ao vivo e uptime
Region
Região da implantação
Memory
Pico de uso (MB atuais / MB limite)
CPU
Média de 15 minutos
Started
Quando esta instância de réplica subiu
Deploy
SHA do commit em execução, marcado como (current)
Last error
Mensagem de erro mais recente, ou — se não houver

Bindings​

Toda a configuração injetada nesta Function em runtime. Duas seções.

Detalhe da Function — aba Bindings com env vars e secrets

Env vars — a tabela completa de variáveis:

Name
Chave da variável — por exemplo LOG_LEVEL, NODE_ENV
Effective value
O valor de fato recebido em runtime
Source
Sempre manifest — declarado em platform.json
Manifest default
O padrão declarado, exibido com autofix
Override (this env)
Override por Environment; editável ali mesmo. Destacado quando ativo.

Os overrides valem imediatamente e reiniciam as réplicas — sem precisar de redeploy. Os padrões do manifesto são somente leitura aqui.

Secrets — credenciais ligadas a esta Function:

Name
Chave do secret — por exemplo STRIPE_WEBHOOK_SECRET, DATABASE_URL
Status
linked quando resolvido; missing quando o secret ainda não foi definido
Used by
Quantas Functions compartilham este secret
Rotated
Data da última rotação do secret

Clique em Rotate para gerar um valor novo. Clique em Open project Bindings → para gerenciar todo o conjunto de secrets no nível do Project.

Settings​

Comportamento de runtime desta Function. Salvo de forma independente — não exige redeploy do código.

Detalhe da Function — aba Settings

Runtime
Memory tier
RAM por réplica. Padrão: Standard (256 MB). Precisa ser um dos cinco tiers declarados no manifesto — valores intermediários são recusados na hora do deploy.
Timeout
Tempo máximo de execução do handler. Padrão: 300 s. O teto rígido é 3600 s. Vale para todos os tipos de invocação.
Max concurrency
Teto rígido de invocações simultâneas por réplica. Padrão: 50. Quando a política de escala é auto e a métrica é concorrência de requisições, o valor Target do card Scaling atua como gatilho suave de autoscale em relação a este teto.
Access
Auth requirement
none — chamadores anônimos permitidos; bom para webhooks públicos e endpoints abertos. player — quem chama precisa apresentar uma sessão de Player logado (um JWT de Player sobreposto à key pk_* do Project); o PlayServ preenche ctx.player dentro do handler.
Scaling
Policy
manual — você controla a contagem de réplicas. auto — a plataforma escala com base na concorrência de requisições em relação a Max concurrency.
Replicas (desired)
Contagem de instâncias desejada quando a política é manual. Clique em Scale para aplicar na hora.

Deploys​

O histórico completo de deploys desta Function específica — cada build que passou por ela, o mais recente primeiro.

Status
live · draining (tráfego migrando para a versão mais nova) · archived
Deployed at
Timestamp do deploy
Revision
Branch do git · SHA curto do commit
By
Avatar e e-mail de quem implantou
Build
succeeded, ou Build failed com um link para os logs de build
Action
locked para os deploys live e draining; ícone de exclusão para os archived

Um deploy entra em draining enquanto as requisições em voo da versão anterior terminam, antes de o tráfego migrar por completo.

informação

O painel Deploys é somente leitura. A fonte da verdade de todos os deploys é a sua CLI — você não pode disparar nem reverter por aqui.

Versões de Function​

Por padrão, cada deploy substitui a latest sem tag, que serve 100% do tráfego. Para rodar uma segunda versão endereçável da mesma Function lado a lado — para teste canário ou um client fixado — implante-a sob uma version tag:

playserv-cli deploy --tag ver2

Um deploy com tag ganha a própria URL endereçável e não recebe tráfego por padrão — a latest sem tag segue atendendo todas as chamadas normais. Reimplantar a mesma tag a reaponta no lugar (vence a última escrita); tags diferentes nunca substituem umas às outras.

Invoque uma versão específica enviando a tag dela em um header na chamada a /fn/{slug}:

X-Playserv-Function-Version: ver2

Se nenhum header de versão for enviado, a chamada vai para a latest. Se o header nomear uma tag que não está no ar, a chamada falha com function_version_not_found — não há fallback silencioso para a latest. A partir de outra Function, o SDK seleciona a versão com target_version na chamada, em vez do header.

Regras de tag

Uma version tag tem 3 a 22 caracteres, letras minúsculas, dígitos e hifens, e precisa começar com uma letra — por exemplo ver2 ou v2-canary. v1 tem um caractere a menos do que uma tag válida.

A promoção mantém a tag

Promover um deploy de dev para prod leva a tag junto: uma origem com tag chega em prod sob a mesma tag e sem migração de tráfego (acessível pelo mesmo header); uma origem sem tag vira a nova latest de prod.

Deploys automáticos por branch​

Um Project pode vincular uma branch do git a um Environment, de modo que um push naquela branch implanta automaticamente no Environment mapeado — por exemplo main → prod, develop → dev. Existindo o vínculo, um merge na branch dispara um deploy sem etapa manual de CLI; o build resultante aparece nas visões Deploys e History com a branch e o commit, exatamente como um deploy pela CLI.

Os vínculos de branch são gerenciados por Project (listar, criar, atualizar, remover) e cada um mapeia uma branch para um Environment de destino. Uma branch sem vínculo simplesmente não faz auto-deploy — pushes nela são ignorados pelo pipeline de deploy até você adicionar um.

observação

O auto-deploy e os deploys manuais pela CLI usam o mesmo pipeline por baixo — um vínculo de branch só decide em qual Environment um build automatizado vai cair. Version tags e promoção se comportam igual, tenha o deploy sido disparado por um push ou pela CLI.

Aba Bindings​

A aba Bindings, no topo da seção Functions, é uma visão de todo o Project — cada env var de cada Function em uma tabela plana, com as mesmas colunas da visão por Function.

Auditar overrides
Veja de relance quais Functions têm overrides por env ativos no Environment atual.
Pegar desvios
Identifique, em uma única visão, as variáveis que divergem dos padrões do manifesto em todo o Project.
Edições em massa
Faça uma mudança por env em várias Functions sem abrir cada uma. Vale imediatamente.

Logs​

Um stream de logs em tempo real, cruzando todas as Functions do Environment.

Functions — aba Logs com stream ao vivo

Seletor de Function

O painel esquerdo lista todas as Functions com a contagem de não lidos. Clique para filtrar; use as caixas para selecionar várias. Mark all / Unmark all alterna a seleção inteira.

Stream de logs

Cada entrada: timestamp com milissegundos, selo de nível (INFO azul · WARN âmbar · ERROR vermelho), nome da Function e mensagem. Chamadas rastreadas trazem um sufixo trace: <id> — todas as linhas da mesma invocação compartilham esse ID.

Controles do stream:

Time range
Últimas 24 horas (padrão) · Últimos 7 dias · intervalo customizado
Level
INFO · WARN · ERROR · NONE
Search
Busca em texto completo em todas as mensagens de log
Live
Transmite novas entradas em tempo real quando ligado
dica

Filtre por uma Function e ligue Live enquanto depura — você vai ver a saída em tempo real conforme dispara as invocações.

History​

Todo deploy que passou por qualquer Function do Project — o log de deploys de todo o Project. Ordenado do mais recente para o mais antigo.

Cada entrada mostra um ponto de status (verde = sucesso, vermelho = falhou), a revisão do git com branch e SHA curto do commit, a mensagem do commit, o autor, o tempo relativo, o número de Functions alteradas e a duração do build. Builds que falharam trazem um selo Build failed com um link View build logs.

Use os dropdowns Time range e Environment para filtrar.

informação

O History inclui todo deploy formado — inclusive builds que falharam e pushes sem nenhuma Function. Use o filtro Environment para separar os históricos de dev e prod.

Próximos passos​

Etiquetas:
Última atualização em