A maioria dos aplicativos modernos (aplicativos da web de página única, aplicativos móveis, etc.) consiste em duas partes:
Para conectar o frontend e o backend, geralmente é usada uma API web (REST, GraphQL, etc.), que requer o desenvolvimento de um cliente API no lado frontend e um servidor API no lado backend.
Temos a seguinte arquitetura:
Com uma arquitetura sem API, o frontend pode se comunicar com o backend sem a necessidade de construir uma API web. O backend expõe funções (ou métodos) que o frontend pode chamar diretamente, e o desenvolvedor não precisa mais se preocupar com caminhos de URL, métodos HTTP ou códigos de status.
É claro que, como o frontend e o backend são executados em ambientes separados, há necessariamente um cliente API e um servidor API entre eles, mas eles não são mais de responsabilidade do desenvolvedor. As camadas da API são gerenciadas por uma biblioteca ou framework.
Portanto, uma arquitetura sem API se parece com isto:
A remoção das camadas da API não apenas reduz a quantidade de código que o desenvolvedor precisa escrever, mas também melhora a qualidade, reduzindo a dispersão do código e a duplicação de conhecimento.
Um número crescente de bibliotecas e frameworks permite implementar a arquitetura sem API.
Produto | Tipo de produto | Tipo de API | Tempo real | Suporte móvel | Desde |
---|---|---|---|---|---|
Meteoro | Estrutura | Processual | Sim | Sim | 2012 |
Camada | Biblioteca | Orientado a objetos | No roteiro | Sim | 2019 |
Blitz.js | Estrutura | Processual | Não | No roteiro | 2020 |
tRPC | Biblioteca | Processual | Em beta | Sim | 2021 |
Telefunção | Biblioteca | Processual | No roteiro | Sim | 2021 |
Contribuições são bem-vindas.
Antes de contribuir, leia o código de conduta e pesquise no rastreador de problemas para descobrir se o seu problema já foi discutido antes.
Para contribuir, bifurque este repositório, confirme suas alterações e envie uma solicitação pull.
MIT