Tudo o que o Fóir faz

Defina o formato dos seus dados a partir de dezesseis tipos de campo nativos, incluindo rich text, decimais exatos, mídia, referências e geopontos, no console ou em código.

Aponte um modelo para outro com um campo de referência e leia através dele em uma só consulta, com tipos de relacionamento que decidem se o acesso e as exclusões acompanham a referência.

Rich text que guarda os seus próprios modelos entre os parágrafos, em qualquer ordem, modelos inline que você define uma vez e reutiliza como tipos de campo, e listas tipadas.

Declare um campo de referência como a hierarquia de um modelo e os registros dele formam uma árvore, com toda leitura devolvendo o caminho do registro e seus ancestrais.

Traduza campos de texto e de prosa por locale, com uma cadeia de fallback percorrida campo a campo e um modo estrito que informa quais campos ficaram sem tradução.

O servidor escolhe a versão de um registro que uma requisição recebe, a partir do contexto que a leitura envia e dos segmentos em que o usuário logado está. Inclui um exemplo prático.

Varie um registro inteiro, um único campo ou uma única entrada de prosa por público, com a variante selecionada no servidor a partir de regras de segmentação reutilizáveis e priorizadas.

Monte públicos a partir de dimensões de contexto como dispositivo, plataforma, locale e status de login, e de segmentos baseados em regras que o servidor avalia a cada requisição.

Identifique um registro por uma chave legível e declare chaves de lookup únicas extras em um modelo, para que um handle ou um SKU o encontre em uma única consulta tipada.

Cor, tipografia e espaçamento guardados como tokens no projeto e servidos pela API, para que um app que os lê em tempo de execução mostre uma mudança de marca assim que ela for publicada.

Em um modelo com publicação ativada, cada salvamento grava um rascunho enquanto a API continua servindo a versão publicada. O console mostra o rascunho como a API o serviria.

Em modelos versionados, cada salvamento é uma versão numerada, mantida por uma janela definida pelo seu plano. Restaurar adiciona uma nova versão, e uma execução de teste informa o efeito antes.

Defina um horário de publicação em uma versão de registro e um horário de despublicação se o conteúdo deve sair do ar de novo. Um agendamento pode ser alterado ou cancelado até disparar.

Um rollout publica um lote nomeado de versões de registros em um único momento agendado. Um item que falha é ignorado e pode ser tentado de novo, e o lote pode ser revertido.

Mudanças em modelos e na configuração são preparadas como rascunhos e liberadas juntas, agora ou em um horário definido, com um diff de breaking changes e uma reversão.

Versionamento, publicação e variantes são ativados por modelo e vêm desativados por padrão, de modo que cada modelo assume só o fluxo de trabalho de que os seus registros precisam.

O Fóir gera um schema GraphQL a partir dos seus modelos. A produção serve o schema publicado, e uma verificação da CLI faz o seu build falhar quando os tipos commitados ficam para trás em relação ao projeto.

Uma leitura envia um locale, um contexto e uma flag de preview. O servidor aplica o fallback de locale, escolhe a variante e seleciona a versão em rascunho ou publicada.

Assine por WebSocket para saber quando registros mudam. Os eventos trazem o id do que mudou, e o módulo live do SDK os aplica ao seu cache de consultas.

Cada chave é pública ou secreta e pertence a um projeto. Ela guarda os escopos que você der e pode ser restringida a modelos e operações escolhidos ou a uma organização.

A API GraphQL faz cache das respostas resolvidas por 60 segundos por padrão e as descarta quando um registro que elas contêm é gravado. Um comando da CLI faz purge manualmente.

Um cliente tipado que escreve o GraphQL da sua aplicação, com tipos gerados por chave, e uma CLI para conteúdo, schema, publicação e configuração, com saída JSON para scripts.

As taxas de requisição são definidas por chave pelo seu plano, e a profundidade da consulta, o número de campos e os aliases têm teto antes de uma consulta rodar. As respostas informam os limites nos cabeçalhos.

Uma página de login que o Fóir hospeda para os seus usuários em um domínio de login que você verifica, com o nome, o logo e a cor do seu projeto, com login por senha, por código enviado por e-mail e por provedor.

Seus usuários entram por qualquer provedor de identidade que publique um documento de discovery do OpenID Connect. Você informa a URL de discovery e as suas credenciais de cliente, e o Fóir executa a troca.

Exija uma passkey ou um código de aplicativo autenticador como segunda etapa depois da senha, antes de uma operação sensível ou em todo login em um app.

Um papel é um conjunto de permissões que você compõe, concedido em um workspace inteiro ou em um projeto. Os papéis dos seus usuários são declarados por projeto na configuração ou na CLI.

Um modelo declara quem é dono dos seus registros, e cada registro é privado ou público. Um registro privado pode ser compartilhado com uma pessoa específica por uma concessão que você pode revogar.

Um campo pode indicar quais tipos de chamador podem lê-lo e quais podem gravá-lo. Há cinco tipos, definidos pela credencial que a requisição traz.

O console lista as sessões que os seus usuários mantêm em um domínio de login personalizado, por aplicação de login, e revoga qualquer uma. Os outros logins terminam por revogação do token ou por expiração.

Quem fez o quê e quando, registrado junto com a mudança e legível no console pelos membros da equipe que têm a permissão. As entradas são mantidas por 90 dias.

As regras de acesso são compiladas em row-level security do Postgres, de modo que o banco de dados filtra o que uma requisição pode ler e uma verificação esquecida no código da aplicação não expõe uma linha.

Um workspace é a sua conta. Toda linha governada carrega o id dele, e a política da tabela compara esse id com a sessão do chamador antes de qualquer outra coisa ser considerada.

Cada projeto tem o seu próprio conteúdo, usuários, arquivos, chaves, segredos e domínios de login. Uma chave de API pertence a exatamente um projeto e não pode ser apontada para outro.

Quando o seu produto tem tenants próprios, cada um é uma organização. O banco de dados marca toda linha com a sua organização e filtra toda leitura por ela.

Quando a equipe do Fóir precisa olhar dentro de um workspace para ajudar, um dos administradores dele aprova a solicitação com um código de uso único. A visita dura uma hora e fica registrada.

O mecanismo que compila as regras é open source, então você pode ler como as políticas são escritas e executar os testes dele por conta própria.

Cada cliente recebe um projeto com o seu próprio conteúdo, chaves, usuários e login. Um workspace administra todos eles, e um cliente que você convida alcança apenas o próprio projeto.

Dê ao seu produto tenants próprios. Cada cliente seu é uma organização dentro do seu projeto, com os próprios membros, usuários, dados e limites.

As organizações se aninham em qualquer profundidade. Uma organização pai lê tudo o que está abaixo dela e altera apenas as próprias linhas, e modelos e configurações são herdados descendo pela árvore.

Uma chamada cria uma organização com a sua marca, as suas configurações, o primeiro membro e uma chave restrita a ela. Execute duas vezes e você continua com uma só organização.

Um arquivo de configuração declara staging e produção como projetos nomeados, e a CLI faz push para um por execução. Eles permanecem idênticos, exceto pelos destinos declarados, e o drift é informado.

Um projeto pode servir a sua API a partir de um domínio que você verifica, e uma aplicação de login pode servir a página de login hospedada a partir de um. Ambos são opcionais, com TLS emitido automaticamente.

Faça upload de um arquivo uma vez e referencie-o por id a partir de qualquer registro, com dimensões e um placeholder lidos das imagens quando o upload é confirmado.

Cada imagem é servida em oito tamanhos nomeados e quatro formatos, renderizada na primeira vez que uma URL é solicitada, com recortes e pontos focais definidos por uso.

Um arquivo tem o seu próprio dono e a sua própria visibilidade, com arquivos públicos servidos de uma URL simples e arquivos privados por um link assinado que expira.

Todo vídeo enviado recebe uma miniatura, uma prévia animada curta e a sua duração, e o streaming adaptativo em HLS está incluído em alguns planos.

Um agendamento executa uma das suas operações com uma expressão cron, em um fuso horário que você indica, e pode ser pausado, retomado ou disparado manualmente.

Um hook executa uma das suas operações quando algo acontece em um projeto, como um registro sendo publicado, e cada entrega é guardada com o seu status.

Uma operação é um endpoint HTTP que você hospeda e registra no Fóir, que o chama com um payload assinado, faz novas tentativas em caso de falha e registra cada execução.

Uma cota limita a frequência com que uma operação pode ser executada em uma janela móvel, por usuário logado ou em um conjunto mais amplo, e devolve uma mensagem que você escreve.

Uma pré-condição decide se uma operação pode ser executada, pela participação do chamador em um segmento ou por uma regra sobre a entrada, e recusa com uma mensagem que você escreve.

Um cofre para as credenciais que as suas operações usam, guardadas criptografadas, endereçadas por referência e rotacionadas sem um novo deploy.

Envie e-mails, notificações in-app e notificações push aos seus usuários, diretamente ou a partir de um evento, com preferências que cada usuário define por categoria e canal.

Busca por palavra-chave nos registros de um projeto, ordenada por relevância e restrita aos registros que o chamador tem permissão para ler.

O Fóir gera embeddings para os modelos que você ativar, de modo que os registros possam ser recuperados por significado, associados a um registro semelhante ou buscados com os seus próprios vetores.

Adicione um campo de geoponto a um modelo e consulte os registros mais próximos de um ponto ou de outro registro, ordenados por distância e, opcionalmente, limitados a um raio.

Comentários em thread que a sua equipe anexa a um registro, a um arquivo, a um modelo ou a outro assunto, até um único campo ou uma única passagem, com menções e uma caixa de entrada por projeto.

Atribua uma nota a um membro da equipe e ela vira uma tarefa, com data de entrega, subtarefas e uma fila por pessoa. Resolver a nota a marca como concluída.

Um assistente no console que trabalha com as permissões da própria pessoa logada. As edições dele chegam como alterações não salvas, como rascunhos ou como solicitações que você aprova.

Passe uma thread de notas ao assistente para uma execução curta e sem supervisão. Ele lê o projeto e responde na thread, e não pode editar, publicar nem excluir conteúdo.

Conecte o seu próprio agente ao servidor MCP hospedado do Fóir. Ele trabalha dentro das permissões de quem o conectou, ou dos escopos da chave secreta que recebeu.

Usuários logados podem escrever notas sobre um registro e ler as respostas da sua equipe. Um widget React registra a nota para você, e um projeto pode aceitar feedback de visitantes.

Um comando exporta um projeto como tabelas Postgres tipadas geradas a partir dos seus modelos, com chaves estrangeiras, o seu conteúdo publicado e links de download dos seus arquivos.

O pacote de exportação inclui row-level security do Postgres para as linhas que cada usuário pode ler. Você a aplica por conta própria. Permissões de campo, escopos de API e regras de escrita ficam para trás.

O Fóir não hospeda o seu código. Você registra uma função que hospeda como operação, e o Fóir a chama com um token assinado e com escopo, faz novas tentativas em caso de falha e registra cada execução.

Estenda o console com as suas próprias ferramentas. Um app é uma página web que você hospeda, incorporada como uma página, uma aba de editor, uma barra lateral ou um editor de campo.

Modelos, chaves de API, hooks, provedores de login e o resto da configuração de um projeto em um único arquivo que você commita. Um push prepara um rascunho e uma release o publica.