Por que o Fóir existe
Oito anos construindo software para outras pessoas, e a mesma lacuna em quase todo projeto. Um sistema de gerenciamento de conteúdo leva você até quase o fim. A parte que ele não cobre é onde o orçamento vai.
Começou como trabalho para clientes
O Fóir nasce de um estúdio que entrega software para clientes. Os produtos eram diferentes de um projeto para o outro. Por baixo, cada um precisava das mesmas partes: conteúdo que um editor pudesse alterar sem um desenvolvedor, dados que pertenciam a usuários específicos, login, armazenamento de arquivos, trabalho agendado e regras sobre quem podia ver o quê.
Construímos essas partes projeto após projeto, e cada uma nos ensinou algo sobre como elas deveriam se encaixar. Depois de projetos suficientes, os padrões pararam de mudar, e fazia cada vez menos sentido construí-los de novo para cada cliente.
Os últimos dez por cento
Um CMS pronto quase atende ao briefing. Depois vem a parte que ele nunca ia fazer: a área logada, o conteúdo que muda por cliente, o fluxo de trabalho que alcança outro sistema.
Nesse ponto há três caminhos, e cada um custa. Rodar dois sistemas e escrever a integração entre eles. Construir o backend e acoplar um CMS de terceiros ao lado. Ou construir o backend e reconstruir as ferramentas de edição que sua equipe já sabia usar. Já orçamos os três mais de uma vez, e nenhum deles é a coisa que alguém queria comprar.
Um agente reconstrói tudo toda vez
O desenvolvimento mais barato deveria ter tornado essa última parte acessível. Ele a tornou frequente. Um agente a quem se pede para construir uma aplicação monta as mesmas peças que faltam em todo projeto: login, um banco de dados, armazenamento de arquivos, permissões, uma fila de jobs. A maioria delas é crítica para a segurança, e você está confiando que ele juntou cada uma corretamente, toda vez, em uma base de código que ninguém leu de ponta a ponta.
Com o Fóir, essas peças chegam já unidas, e nós as operamos. O agente escreve o que é particular do seu produto, sobre um backend cujas regras de acesso ele não tem como deixar de fora.
Os bugs nesse código são ausências
As falhas em um backend montado são silenciosas: uma verificação em um caminho que ninguém exercitou, uma consulta sem uma cláusula, uma chave que alcança mais longe do que a pessoa que a segura.
Você não consegue revisar até chegar à confiança sobre algo que não está lá. O que funciona é um sistema em que a verificação não pode ser deixada de fora. No Fóir, as regras de acesso são compiladas na própria row-level security do banco de dados, então uma consulta que esquece uma verificação retorna apenas o que o chamador pode ver, e uma tabela nova falha nos nossos testes até que alguém decida como ela é protegida. O mecanismo que faz a compilação é o Demesne, e ele é open source.
Nós construímos em cima dele
O Fóir é a base a partir da qual começamos nosso próprio trabalho. Este site roda nele, e é nele que nossos novos projetos de clientes são entregues. As decisões que costumávamos tomar de novo a cada build, como a modelagem do conteúdo e a forma de manter os dados de um usuário como dele, são tomadas uma vez e mantidas.
Um backend precisa ser operado, além de escrito, então o Fóir é um serviço gerenciado. A parte dele que decide quem pode ver seus dados é publicada para qualquer pessoa ler.
Então construímos aquele para o qual vivíamos orçando
Todo projeto pagava para ter a mesma base construída de novo.
O Fóir é essa base, operada para você: conteúdo estruturado e dados de aplicação em um único runtime, com login hospedado, mídia, personalização, automação e uma API gerada, tudo já conectado. Você começa pela sua própria lógica de negócio.
O que ele substitui
As assinaturas e os projetos de construção que ele substitui, em um só lugar e em uma só fatura.
Um CMS headless
A interface editorial, o schema, os rascunhos e o histórico de versões.
Um provedor de auth
Login para os seus próprios usuários, no seu próprio domínio, com os papéis que o acompanham.
Armazenamento e uma CDN
Uploads, transformações de imagem, streaming de vídeo e a entrega que vem na frente deles.
Um serviço de busca
Texto completo nos seus registros e vetores para recuperação por significado.
Um executor de jobs
Agendamentos, operações em segundo plano, novas tentativas e um lugar para onde as falhas vão.
Um provedor de mensagens
E-mail transacional, in-app e push, com preferências guardadas por cliente.
A camada de integração
O código que de outro modo manteria esses seis juntos, e o drift entre eles.
As pessoas que aplicam as correções
Não há servidor seu para manter atualizado, nem fim de semana de atualização.
Veja se ele se sustenta
Cada capacidade, e as comparações em que dizemos com clareza qual ferramenta nós escolheríamos no lugar.