# Próximo passo: Threeebs Editor em tempo real, PHP e quotas por projeto
2026-09-06 15:03:21
O Threeebs :3 entrou em uma nova etapa.
Depois da evolução da base de projetos, ambientes, Editor Threeebs e fluxo de parceiros, o próximo ciclo será concentrado na infraestrutura necessária para transformar o Editor em um ambiente de desenvolvimento mais completo.
O objetivo não é simplesmente adicionar novas linguagens ou recursos visuais.
A próxima etapa estabelece três fundamentos:
- limites e medição de armazenamento por projeto;
- edição colaborativa em tempo real com WebSocket + CRDT;
- suporte a projetos PHP com banco de dados isolado por ambiente.
A arquitetura deve continuar priorizando isolamento entre projetos, autorização no servidor e crescimento progressivo de recursos.
---
Visão da próxima etapa
A estrutura pretendida passa a ser:
THREEEBS :3
│
Projeto / Ambiente
│
┌────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
STORAGE REALTIME SERVICES
│ │ │
Quotas WebSocket ├── Database
Limites CRDT / Yjs ├── PHP Runtime
Medição Presença ├── GitHub
│ │ └── IA
└────────┬───────┘
▼
THREEEBS EDITOR
│
MonacoO projeto continua sendo o centro da plataforma.
Recursos adicionais são ativados sobre ele, sem exigir que o usuário migre para outro sistema.
---
1. Quotas de armazenamento
Atualmente o Editor já possui algumas proteções globais para tamanho de arquivo, quantidade de entradas e profundidade de diretórios.
A próxima evolução será transformar esses limites técnicos em quotas reais por projeto.
Cliente
│
▼
Projeto
│
├── limite de armazenamento
├── limite de arquivos
├── limite de pastas
└── limite por arquivoA quota pertence ao projeto, e não individualmente a cada usuário.
Isso permite que vários colaboradores trabalhem sobre o mesmo espaço respeitando o mesmo contrato de recursos.
Limites planejados
Cada projeto poderá possuir configurações como:
armazenamento_bytes_max
arquivos_max
pastas_max
arquivo_bytes_maxSeparadamente, o Threeebs acompanhará o consumo:
Projeto
│
├── armazenamento usado
├── arquivos usados
├── pastas usadas
├── armazenamento reservado
├── arquivos reservados
└── pastas reservadasA separação entre limite e uso será importante para futuros planos e serviços.
---
Concorrência e operações simultâneas
A validação não poderá ser baseada apenas em:
verificar quota
↓
salvar arquivoporque duas requisições simultâneas poderiam enxergar o mesmo espaço livre e ultrapassar o limite juntas.
O fluxo deverá utilizar reserva atômica:
Request
│
▼
calcular impacto da operação
│
▼
BEGIN TRANSACTION
│
▼
bloquear contador do projeto
│
▼
verificar quota
│
▼
reservar recursos
│
▼
COMMIT
│
▼
alterar filesystem
│
▼
confirmar consumoExemplo:
Quota disponível: 10 MB
Request A → quer +8 MB
Request B → quer +8 MBSomente uma das reservas poderá ser confirmada.
A segunda deverá receber erro antes de ultrapassar o limite.
---
Regra importante: apagar continua permitido
Um projeto acima da quota nunca poderá ficar preso sem conseguir liberar espaço.
Se:
Quota: 100 MB
Uso: 101 MBo sistema deverá bloquear:
novo arquivo ✗
nova pasta ✗
upload ✗
arquivo crescendo ✗mas continuará permitindo:
apagar arquivo ✓
apagar pasta vazia ✓
salvar arquivo menor ✓
renomear ✓A quota existe para limitar crescimento, não para impedir recuperação.
---
Isolamento de quotas
Um projeto nunca poderá utilizar o limite ou modificar os contadores de outro.
Projeto A
├── storage A
├── quota A
└── uso A
Projeto B
├── storage B
├── quota B
└── uso BNão existe:
Projeto A
│
└── quota compartilhada acidentalmente com BOs testes dessa etapa deverão simular concorrência e isolamento entre projetos diferentes.
---
2. Threeebs Editor em tempo real
O Editor Threeebs passará de um fluxo tradicional de abrir → alterar → salvar para uma arquitetura colaborativa.
A base escolhida para planejamento é:
Monaco Editor
+
Yjs
+
y-monaco
+
WebSocketO Yjs utiliza CRDT para permitir que diferentes usuários alterem o mesmo documento simultaneamente sem depender do modelo clássico de "último save vence".
---
Arquitetura Realtime
Um novo serviço será separado do Sandbox atual:
Docker
│
├── portal
├── admin
├── sandbox
├── host
├── realtime ← novo
├── mysql
└── redisO serviço realtime será responsável somente por:
WebSocket
CRDT
presença
cursores
salas de edição
sincronizaçãoEle não deverá receber acesso direto a todos os projetos no filesystem.
---
Autenticação do WebSocket
A conexão seguirá o fluxo:
Threeebs Editor
│
▼
Sandbox API
│
├── autentica usuário
├── valida projeto
├── valida ambiente
└── cria ticket temporário
│
▼
Redis
│
▼
Browser ───── WebSocket ───── Realtime
│
▼
Y.DocO navegador recebe apenas um ticket temporário, com curta duração e uso único.
A autorização continuará acontecendo no Threeebs.
---
Salas de edição
Cada documento colaborativo será identificado pelo contexto completo:
projeto_uuid
+
ambiente_uuid
+
arquivoExemplo:
PROJETO-A
└── sandbox
└── index.phpé uma sala diferente de:
PROJETO-B
└── sandbox
└── index.phpmesmo que os dois arquivos tenham exatamente o mesmo nome.
---
Presença colaborativa
Além do conteúdo, o Editor poderá mostrar quem está conectado ao documento.
index.php
● Marcelo
● Vinicius
● TiãoO CRDT também poderá sincronizar:
cursor
seleção
arquivo atual
estado de presençaA primeira versão não precisa transformar o Editor em um produto complexo de colaboração.
O objetivo inicial é:
duas pessoas
↓
mesmo arquivo
↓
alterações simultâneas
↓
sem sobrescrever trabalho---
Persistência
O arquivo não deve ser gravado fisicamente a cada tecla.
O fluxo planejado será:
digitação
digitação
digitação
│
▼
Y.Doc
│
├── sincronização imediata entre usuários
│
└── checkpoint após pequeno intervalo
│
▼
quota
│
▼
storageCtrl + S poderá continuar existindo como checkpoint explícito.
---
Quota + CRDT
Realtime não poderá ignorar os limites do projeto.
Mesmo que o documento esteja sendo alterado por vários usuários simultaneamente:
CRDT
│
▼
checkpoint
│
▼
Storage API
│
├── autorização
├── quota
├── reserva
├── escrita atômica
└── auditoriaO serviço realtime não será uma rota alternativa para escapar das regras do storage.
---
3. PHP no Threeebs Editor
A primeira evolução PHP é simples:
Threeebs Editor
│
└── permitir editar .phpArquivos PHP passarão a utilizar suporte de linguagem do Monaco.
Exemplo:
index.php
config.php
api/
└── users.phpEssa alteração significa apenas:
> o Editor entende PHP como código editável.
Ela ainda não significa que o Host poderá executá-lo.
---
Editar PHP e executar PHP são etapas diferentes
Essa divisão é obrigatória.
Editor lê PHP
✓
Host disponibiliza código PHP como texto
✗
Runtime executa PHP
✓O código PHP nunca deverá ser servido diretamente como arquivo de texto para o navegador.
---
4. Runtime PHP
O Host atual continuará responsável por resolver o endereço do projeto.
Mas o destino poderá depender do runtime configurado para o ambiente.
hostname
│
▼
Threeebs Host / Gateway
│
▼
ambiente
│
▼
runtime
│
├── static
│ │
│ ▼
│ HTML / CSS / JS
│
└── php
│
▼
PHP Runtime isoladoIsso permite que o mesmo Threeebs suporte projetos estáticos e projetos dinâmicos.
---
Projetos híbridos
Um projeto PHP continuará podendo utilizar HTML, CSS e JavaScript normalmente.
Projeto
│
├── index.php
├── contato.php
├── sobre.html
│
└── assets/
├── style.css
├── app.js
└── logo.pngPortanto não existirão dois produtos separados.
Existirão capacidades diferentes do mesmo projeto.
Projeto Static
└── HTML / CSS / JS
Projeto PHP
└── PHP + HTML / CSS / JS---
Isolamento do Runtime
Antes de executar PHP enviado pelo usuário, será obrigatório eliminar a possibilidade de um projeto acessar o storage completo do servidor.
O runtime deverá enxergar somente seu ambiente.
PHP Runtime — Projeto A
│
└── /var/www/project
↓
storage/projects/UUID-A/sandboxEle não poderá enxergar:
storage/projects/UUID-B
storage/projects/UUID-CEssa etapa é uma fronteira de segurança obrigatória antes de liberar execução arbitrária de PHP.
---
5. Banco de dados do projeto
Os bancos utilizados pelos sites dos clientes não deverão compartilhar a mesma fronteira administrativa dos bancos internos do Threeebs.
Arquitetura pretendida:
MYSQL THREEEBS
│
├── threeebs_identity
├── threeebs_control
├── threeebs_work
├── threeebs_catalog
├── threeebs_finance
└── threeebs_audit
MYSQL PROJECTS
│
├── projeto_A_sandbox
├── projeto_A_production
├── projeto_B_sandbox
└── projeto_B_productionAssim, código PHP do cliente nunca precisa possuir credenciais para o banco de controle da plataforma.
---
Credenciais por ambiente
Cada ambiente terá seu próprio usuário de banco.
Projeto A
│
├── Sandbox
│ ├── database A_sandbox
│ └── user A_sandbox
│
└── Production
├── database A_production
└── user A_productionOs grants devem permitir acesso somente ao banco correspondente.
---
Variáveis de ambiente
O usuário não precisará editar um .env real pelo Monaco.
O Threeebs terá uma área própria:
Projeto
│
▼
Ambiente
│
▼
VariáveisExemplo:
APP_NAME
API_URL
DB_HOST
DB_PORT
DB_DATABASE
DB_USERNAME
DB_PASSWORDValores sensíveis serão tratados como segredos.
Depois de cadastrados, não devem ser devolvidos livremente em texto claro pela interface.
---
Código do usuário
O PHP acessará essas configurações através do ambiente do runtime.
Exemplo:
$pdo = new PDO(
'mysql:host=' . getenv('DB_HOST')
. ';dbname=' . getenv('DB_DATABASE')
. ';charset=utf8mb4',
getenv('DB_USERNAME'),
getenv('DB_PASSWORD')
);O usuário não precisa conhecer a infraestrutura interna do Threeebs.
---
Serviços por ambiente
A estrutura existente de serviços será utilizada como ponto de integração.
Projeto
│
▼
Ambiente
│
├── runtime.static
├── runtime.php
├── database.mysql.shared
├── github
└── futuramente codexUm banco dedicado poderá futuramente substituir o compartilhado sem exigir mudança no código da aplicação:
database.mysql.shared
↓
database.mysql.dedicatedAs mesmas variáveis de ambiente continuam disponíveis ao projeto.
---
Sequência de implementação
Essas funcionalidades não serão desenvolvidas em um único Pull Request.
A ordem planejada será:
FASE 1
Storage Quotas
│
▼
FASE 2
Realtime / WebSocket / CRDT
│
▼
FASE 3
Edição PHP no Monaco
│
▼
FASE 4
Isolamento de Runtime
│
▼
FASE 5
Database de Projetos
│
▼
FASE 6
Execução PHPCada fase deverá ser validada antes da seguinte.
---
Critérios mínimos da etapa de quota
Antes de considerar a primeira fase concluída, precisamos provar:
✓ duas gravações simultâneas não ultrapassam armazenamento
✓ dois arquivos criados simultaneamente
não ultrapassam arquivos_max
✓ duas pastas criadas simultaneamente
não ultrapassam pastas_max
✓ Projeto A não consome quota do Projeto B
✓ Projeto A não consegue alterar arquivos do Projeto B
✓ apagar continua funcionando quando a quota está esgotada
✓ salvar diminuindo o tamanho continua permitido
✓ salvar aumentando é bloqueado quando não há espaço
✓ reservas abandonadas podem ser reconciliadas---
Critérios mínimos do Realtime
✓ dois usuários podem abrir o mesmo arquivo
✓ mudanças aparecem em tempo real
✓ alterações simultâneas não sobrescrevem umas às outras
✓ usuário sem acesso ao projeto não entra na sala
✓ sala do Projeto A não recebe dados do Projeto B
✓ checkpoint continua respeitando quota
✓ desconexão e reconexão não corrompem o documento---
Critérios mínimos do PHP
✓ Editor consegue abrir e salvar .php
✓ Host nunca expõe código-fonte PHP
✓ Projeto Static continua funcionando normalmente
✓ Projeto PHP executa em runtime isolado
✓ runtime vê somente seu próprio ambiente
✓ credencial do banco acessa somente seu database
✓ Sandbox e Produção usam credenciais diferentes
✓ PHP do cliente não possui acesso aos bancos internos Threeebs---
Direção
Essa etapa não transforma o Threeebs apenas em uma hospedagem PHP.
Ela fortalece a ideia central do produto:
Usuário
↓
Projeto
↓
Ambiente
↓
Recursos
│
├── Editor
├── Storage
├── Realtime
├── Database
├── Runtime
├── GitHub
└── IAO projeto continua sendo a unidade central.
O usuário começa com uma experiência simples e, conforme sua necessidade cresce, novas capacidades podem ser habilitadas sobre o mesmo projeto.
HTML
↓
Editor
↓
Realtime
↓
PHP
↓
Banco
↓
GitHub
↓
IAEsse será o próximo passo da evolução do Threeebs :3.