Pitch: Fiquei quase 3 anos fazendo um framework TypeScript · minenwerfer

Sim, é isso mesmo.

Sempre achei que faltava uma peça no ecossistema JavaScript quando se tratava de desenvolvimento fullstack, especialmente para projetos voltados para dados. Eu queria poder criar sistemas de alta qualidade realmente portáveis sem depender de third-parties exceto quando realmente fosse necessário. Queria poder rodar um comando e ter o scaffolding de um projeto com uma implementação de autenticação padronizada, gerenciamento de arquivos, controle de acesso, etc, e depois poder acrescentar features sem precisar lidar com um mapa mental complexo de arquiteturas "javescas", nem com um tooling para gerar código como é o caso do NestJS, Rails, Phoenix, etc. Algo que fosse o mais próximo do código possível, e seguro e fácil de usar somente por sua natureza DRY e declarativa.

Depois de vários meses, grande parte das metas de design inicialmente estabelecidas foram alcançadas, sendo elas:

Redução drástica da superfície do código em relação a outras frameworks -- quase tudo é feito de forma declarativa. Endpoints CRUD são reusáveis e incluídos na propriedade "functions" do schema, dessa maneira fica bem fácil fazer um TODO list sem precisar programar cada operação do CRUD manualmente. Tipos são inferidos dos objetos literais presentes nos schemas e incluidos usando uma certa mágica envolvendo a feature de declaration merging do TypeScript -- isso quer dizer que você tem um código totalmente tipado muitas vezes sem precisar escrever ou mesmo importar qualquer tipo.
Interoperabilidade do backend com o frontend -- os metadados, schemas das collections, e rotas, são enviados ao frontend pelo backend, portanto o frontend consegue construir formulários e tabelas com a representação visual ideal para cada tipo de campo: datas, booleanos, strings, imagens, listas de strings, listas de imagens, etc. Muita coisa pode ser gerada no runtime dessa forma e os bundles emitidos ficam ridiculamente pequenos.
Tipagem end-to-end: algo que CMSes headless como Strapi, Pocketbase, etc, não possuem, por limitações inerentes ao design e à tecnologia usada, mas que é possível se ter com algo como o tRPC, se não se considerar o custo de manter uma nova abstração no seu projeto. Você pode usar o Aeria como source-of-truth num workspace NextJS residindo no mesmo projeto (semelhante ao Prisma, mas não restrito ao acesso de dados), ou ter uma SDK totalmente tipada em qualquer outro projeto TypeScript.

Screenshot da tipagem no Editor

A parte frontend do projeto atualmente é fundada sobre o Vue. Esperamos que ele amadureça o suficiente e que a comunidade implemente clientes para outras frameworks, como o React, Svelte, Solid, etc. O Aeria no entanto pode ser usado como uma API standalone ou como fonte de verdade para frameworks web como o NextJS.

Aeria: https://github.com/aeria-org/aeria
Aeria UI: https://github.com/aeria-org/aeria-ui
Live Demo: https://github.com/aeria-org/demo

Agradeço enormemente a leitura. Ficarei atento aos comentários para responder qualquer dúvida ou crítica de alguém que possa se interessar.
Ah, e estrelas nos repositórios são bem-vindas :^).