KOF
Baixar Kof
01Web

Construa uma aplicação web sem construir antes um ecossistema de frameworks.

A visão: HTTP, banco, mensageria, assincronismo e segurança como capacidades da plataforma — não como pilhas de dependências montadas manualmente em todo projeto.

visão da plataforma
Kof Application
       │
       ├── HTTP
       ├── JSON
       ├── Database
       ├── Authentication
       ├── Messaging
       ├── Async
       └── Concurrency

Nada disso é apresentado aqui como API final. As assinaturas concretas serão definidas conforme a standard library e o runtime evoluírem.

02Web server

kof serve

O servidor web faz parte da CLI oficial. É o começo real da plataforma web — não um framework de controllers.

terminal
$ kof serve app.kf
$ kof serve app.kf --port 8080

kof serve

Disponível
Serve uma aplicação Kof diretamente a partir do arquivo fonte. Na JVM, cada conexão roda em virtual thread — sem servlet container, sem Spring.

HTTP e JSON na stdlib

Disponível
web.app(), rotas com path params, query, headers, middleware app.use, app.security() (rate-limit/CORS/CSRF/auth/RBAC) e OAuth2 resource server na JVM; servidor embutido também no KofJS (GraalJS HttpServer + KofJsWebQueue, 03/09) e HTTP/1.1 asm no Native (WEB002). Residual nos dois últimos: TLS, ws/sse, path params. JSON tipado (json.decode<User>) nos três targets.
03Objetivo

Frontend, backend, database, auth, messaging e async com pouquíssimos arquivos de código de negócio.

Esse é o objetivo de longo prazo da plataforma, e ele ainda não está entregue. O que existe hoje: backends JVM e Native estáveis, servidor web real na JVM (com OAuth2 + app.security), servidor base no KofJS e HTTP/1.1 asm no Native, com gaps residual nomeados (WEB002/WEB001).

HTTP deve ser simples

Disponível

Banco deve ser simples

Disponível

Mensageria deve ser simples

Disponível

Assincronismo deve ser simples

Em desenvolvimento

Concorrência deve ser simples

Disponível

Segurança deve ser simples

Disponível

Supervisão deve ser simples

Disponível
04Provocação

Não queremos substituir o Spring por outro Spring.

Kof não quer criar um “Kof Spring”. Nem um “Kof Hibernate”. Nem uma camada de abstração em cima de outra camada de abstração. A pergunta é: por que essa complexidade precisa existir em primeiro lugar?

hoje
Spring
Hibernate
ORM
DI
AOP
Controllers
Repositories
DTOs
Configuration
...
kof
Kof
Compiler
Runtime
Standard Library

O objetivo não é remover capacidade. É remover cerimônia.