Qual é o desempenho mais rápido? Criando uma API REST e fazendo com que seu aplicativo Web use a API REST para fazer todas as interações com o banco de dados OU consultando diretamente o banco de dados (por exemplo, usando qualquer objeto típico que sua linguagem utilize para consultar um banco de dados como o JDBC for Java)?
Do jeito que eu vejo isso com o REST:
- Você cria um objeto no seu código para chamar o método REST
- Chamar método http
- O código dentro da API REST consulta o banco de dados
- Banco de dados retorna alguns dados
- O código da API REST compacta os dados no Json e os envia ao seu cliente
- Cliente recebe resposta Json / XML
- Mapeie a resposta a um objeto no seu código
Por outro lado, consultando um banco de dados diretamente:
- Você cria um objeto com uma string de consulta para consultar o banco de dados
- Banco de dados retorna alguns dados
- Mapeie a resposta a um objeto no seu código
Portanto, isso não significa que o uso de uma API REST seria mais lento? Talvez isso dependa do tipo de banco de dados (SQL vs NoSQL)?
Respostas:
Quando você adiciona complexidade, o código fica mais lento. A introdução de um serviço REST, se não for necessário, atrasará a execução, pois o sistema está fazendo mais.
Abstrair o banco de dados é uma boa prática. Se você está preocupado com a velocidade, pode tentar armazenar em cache os dados na memória para que o banco de dados não precise ser tocado para lidar com a solicitação.
Antes de otimizar o desempenho, analisando o problema que você está tentando resolver e a arquitetura que está usando, estou lutando para pensar em uma situação em que as opções do banco de dados sejam de acesso direto versus REST.
fonte
extra work. Mas, na verdade, poderia ser mais rápido armazenando em cache consultas repetidas.Se sua preocupação for velocidade, sim, um serviço de Descanso será mais lento pelos motivos mencionados acima. No entanto, a velocidade do tipo que você descreve raramente é a principal preocupação e, se for, pode ser tratada de outras maneiras. A otimização prematura é a raiz de todo mal .
Considere se sua principal preocupação é a interoperabilidade (móvel, web, B2B), agora o REST é muito atraente porque é independente da tecnologia.
Suponha que você codifique para um banco de dados. O que você faria se optar por alterar seu armazenamento de dados subjacente. Quão difícil seria se você estivesse fortemente acoplado à loja subjacente?
A resposta real é que depende , mas espero ter lhe dado algumas coisas para pensar!
fonte
Se achar difícil responder a essa pergunta.
A resposta geral correta deve ser: depende.
Há um erro no seu pensamento.
E esse erro decorre do fato de você não entender completamente o REST e seus princípios. O REST não foi inventado, porque alguns nerds acharam legal (é claro) enviar objetos Javascript via HTTP através da conexão. A principal vantagem do uso do HTTP é a possibilidade de usar o cache . Se você tornar seus resultados armazenáveis em cache , haverá menos solicitações a serem feitas no banco de dados. E nenhum empacotamento está envolvido. A resposta pode ser entregue diretamente.
Na medida em que a resposta do @Klees não está certa :
Ao lidar com resultados de cache, não há impacto no seu aplicativo: o fornecimento de respostas conhecidas para perguntas conhecidas pode ser feito por meio de proxies reversos.
fonte
A introdução de uma camada de serviço extra sempre tem um custo em complexidade e sobrecarga de desempenho. Existem alguns tipos específicos de arquitetura em que a introdução de uma camada de serviço compartilhada (como uma API REST) pode melhorar forçosamente devido ao cache compartilhado - mas parece que não é o tipo de arquitetura que você possui.
Considere uma arquitetura em que você tenha vários aplicativos da web ou vários aplicativos de desktop conectados diretamente ao mesmo banco de dados. Se eles executam as mesmas consultas frequentemente, pode melhorar o desempenho para armazenar em cache os resultados da consulta em um serviço compartilhado. Especialmente se você disser que centenas de aplicativos de desktop acessam o mesmo banco de dados diretamente (não através de um aplicativo Web!) E realizam as mesmas consultas, pode haver uma grande melhoria. No entanto, mesmo nessa arquitetura, o principal motivo para a introdução de um serviço compartilhado provavelmente seria a segurança e a abstração de dados, e não o desempenho.
Mas parece que você tem um único aplicativo da web que se conecta diretamente ao banco de dados. Nesse caso, não há benefício em introduzir uma camada de serviço adicional. O armazenamento em cache, a abstração do banco de dados etc. podem ser manipulados na camada de acesso a dados no mesmo aplicativo.
fonte
Depende.
Obviamente, quanto mais camadas no seu código, mais lento ele fica. Mas ... chega um momento em que o desempenho direto de ponta a ponta não importa tanto quanto a escalabilidade. Se você tiver um usuário acessando seu banco de dados em um PC local, ele poderá ser mais rápido. Se você tem mil usuários acessando o mesmo banco de dados no mesmo PC, é provável que veja todos eles frustrados. A solução é mover o banco de dados para outra caixa, adicionar uma camada no meio e, embora para 1 usuário, ele tenha um desempenho mais lento, quando os milhares acessarem, ele será mais rápido. (essa é uma resposta simplista, mas verdadeira em princípio).
Há outros motivos para ocultar seu banco de dados atrás de uma camada de camada intermediária, como segurança.
fonte
Não sei onde você se perde, mas é bem claro que, quando você está usando a API REST, está fazendo uma etapa extra, e a etapa extra "sempre" significa mais devagar quando a programação está envolvida.
Há prós e contras, mas se você pode acessar o banco de dados diretamente do seu aplicativo, é sempre melhor chamá-lo diretamente, em vez de usar a API da Web, é claro que se você usa a API da Web, pode facilmente portar seu aplicativo para uma plataforma diferente.
fonte
DESCANSAR :
DB local:
Esta é uma enorme diferença, muitas vezes as pessoas esquecem esses pontos
fonte