API REST vs diretamente chamadas de banco de dados no aplicativo Desktop

Atualmente, estou planejando um aplicativo que será usado em uma empresa. É necessário criar um aplicativo de desktop. No momento, eles não têm certeza se o aplicativo deve estar disponível no celular ou no navegador em um futuro próximo.

Eu tenho duas possibilidades:

Acesse o banco de dados diretamente do aplicativo Desktop
Crie uma API REST e conecte-se a esta

Posso usar uma API REST se o aplicativo permanecer apenas um aplicativo de desktop dentro da empresa? Eu sei que é possível, mas é o caminho "certo"? (Melhores Práticas)

Existem algumas (possíveis) vantagens e desvantagens para criar diretamente uma API REST:

Desvantagens:

Leva mais tempo para se desenvolver
Mais complexo
O servidor faz mais trabalho
problemas de segurança
Mais devagar? (O servidor e o aplicativo da área de trabalho estão na mesma rede)

Vantagens:

Migrar para outras plataformas é mais fácil
A lógica de negócios também é necessária ao chamar diretamente o banco de dados. Não vai demorar muito mais tempo para desenvolver
O mesmo vale para a complexidade
Segurança (como mencionado por tkausl nos comentários)
Manutenção (como mencionado pelo WindRaven nos comentários)

— devz
fonte

Você realmente conta Security issuescomo uma desvantagem para a API REST?

— tkausl

Posso proteger minha API com, por exemplo, OAuth2 e TLS, mas isso adicionará mais trabalho. Não sei o quão segura é uma chamada direta ao banco de dados. Por exemplo, com JPA. Foi por isso que adicionei um ponto de interrogação, pois não tenho muita certeza.

— Devz

Bem, você não pode obter menos segurança do que uma chamada direta ao banco de dados, a menos que você forneça o login root.

— tkausl

Outra vantagem: uma alteração na lógica de negócios só precisa ser feita na API REST e implantada no servidor, não feita e, em seguida, todos os clientes são atualizados. (desde que a interface da API não seja alterada como resultado)

— RubberChickenLeader

O banco de dados está sendo executado no mesmo computador que o aplicativo? Caso contrário, eu nem pensaria em acesso direto à gravação no banco de dados.

— CodesInChaos

Respostas:

Quando se trata de aplicativos grandes com um grande banco de dados contendo milhões de registros, você logo percebe que simples seleções, atualizações, inserções e exclusões simplesmente não são suficientes.

Então você começa a pensar de uma maneira diferente. Você cria procedimentos e gatilhos para cuidar de coisas mais complicadas diretamente no banco de dados e isso não é muito bom. Os bancos de dados oferecem excelente desempenho ao executar operações CRUD. Procedimentos longos? Não muito.

O problema com os procedimentos

Agora imagine que você alterna para um banco de dados que não suporta o conceito de procedimentos? O que você vai fazer? Você é forçado a mover os procedimentos para sua base de código, onde pode ter certeza de que, uma vez que o programa, digamos Java, ele sempre permanecerá lá, independentemente do mecanismo de banco de dados que você escolher.

Sem mencionar, seus procedimentos geralmente fazem parte da sua lógica de negócios e não é uma boa ideia ter sua lógica de negócios dividida em sua base de código e banco de dados.

Idealmente, você sempre deve ter um mediador entre o banco de dados e o cliente implementando suas próprias regras de negócios. Fornecer acesso direto ao banco de dados não é uma boa ideia, porque quando você faz isso, aquele com acesso tem acesso direto às tabelas e pode fazer praticamente qualquer coisa com os dados existentes.

Desvantagens

Demora mais para se desenvolver: é claro que você está criando um novo sistema, que consumirá mais tempo do que simplesmente fornecer ao cliente uma cadeia de conexão com o banco de dados e permitir que ele escreva as consultas.
Mais complexo: complexidade de um sistema> complexidade de uma consulta ao banco de dados.
O servidor trabalha mais: não necessariamente. Com um bom design, armazenamento em cache, ... você pode mover a carga do servidor de banco de dados para o do mediador.
Mais lento: Em termos de desenvolvimento? Sim. Em termos de velocidade ao recuperar dados? Não. Você pode otimizar seu mediador usando caches (como - popular em janeiro de 2016 - Redis, Elasticsearch) e realmente fazer com que ele entregue dados mais rapidamente do que uma consulta simples ao banco de dados.

Vantagens

Migrar para outras plataformas é mais fácil: Migrar para um novo mecanismo de banco de dados? Definitivamente. Migrando todo o mediador para um novo idioma? Na verdade não.
A lógica de negócios também é necessária ao chamar diretamente o banco de dados. Não demorará muito mais tempo para desenvolver: Como explicado anteriormente, o problema dos procedimentos.
Segurança: Com a devida autorização, ter o mediador é definitivamente muito mais seguro do que conceder ao usuário acesso direto ao banco de dados, porque você o restringe aos pontos finais que executam apenas as consultas que você deseja.
Manutenção: Um dos melhores benefícios de se ter um mediador. Se houver um bug em uma API que seus clientes chamam, você o corrige, envia a correção para o seu repositório VCS, constrói seu mediador a partir da versão atual do VCS que contém a correção e todos os seus clientes estão subitamente usando a correção, sem que eles precisem baixe uma atualização. Isso é simplesmente impossível, se as consultas forem armazenadas diretamente nos aplicativos clientes. Nesse caso, os clientes são forçados a atualizar seus aplicativos.

— Andy
fonte

Quantas vezes você enfrentou o desafio de mudar para um banco de dados que não suporta o conceito de procedimentos quando você realmente os estava usando?

— Harpun

@harpun Duas vezes nos últimos 2 anos. Quando eu e a equipe com quem estávamos trabalhando em um projeto decidimos ir do MySQL ou PostgreSQL para o MongoDB como parte da mudança para o Node.js e também para evitar bloqueios e armazenar objetos como agregados diretamente.

— Andy Andy

Há outra opção além do acesso direto ao db. A "API do mediador" não precisa usar HTTP; portanto, o servidor HTTP não precisa estar envolvido. Pode ser apenas API no nível do código. Outra questão é, desde que você não está satisfeito com a velocidade de sua linguagem de programação, é se a ter API (acesso REST) escrito com algum outro idioma / plataforma do que sua lógica de negócio ...

— forsberg

Aqui está minha opinião sobre o assunto: Você tem a idéia certa de querer usar um serviço da Web, mas pode estar pensando em usar a tecnologia errada.

Quando você diz REST, suponho que você esteja falando do Asp.Net WebApi. Essa é a tecnologia errada para aplicativos de intranet. REST e WebApi são impressionantes, não me interpretem mal, mas para qualquer tipo de aplicativo interno, os serviços Web WCF são o caminho a seguir na minha humilde opinião. Eles permitem que o cliente faça referência ao terminal em serviço como uma biblioteca de classes, o que significa que você não está lidando com XML ou JSON no seu cliente de desktop. Você está trabalhando com classes e objetos.

Enfim, sim. Você tem a ideia certa. Se eles não tiverem certeza de que precisarão de um cliente baseado na Web, será necessário arquitetar seu sistema para adicioná-lo facilmente, se eles decidirem que desejam mais tarde. É muito mais fácil adicionar diferentes tipos de clientes quando você tem uma arquitetura orientada a serviços.

— Pato de borracha
fonte

É estupidamente fácil usar um cliente para desserializar json para objetos. As classes podem até ser geradas automaticamente a partir do exemplo json usando json2csharp.com . Ele funciona bem com o cliente http do pacote de nuget microsoft.aspnet.webapi.client. Você voltou ao território dos objetos mais rapidamente do que lida com as referências de clientes do WCF que prometo, portanto esse não deve ser o principal driver para a escolha do WCF.

— Esben Skov Pedersen

@EsbenSkovPedersen há uma diferença entre estúpido, fácil e automático .

— precisa saber é o seguinte

Porque nunca há problemas com o WCF? Isso não pode estar certo.

— Esben Skov Pedersen

Quem disse que não houve problemas com o WCF @EsbenSkovPedersen? Eu com certeza não. Cada peça de tecnologia tem seus problemas. Qual é o seu problema?

— precisa saber é o seguinte

Quando você diz que é mais fácil do que estupidamente fácil, você implica isso. Eu não tenho um problema.

— Esben Skov Pedersen

Olhe dessa maneira, definitivamente é um padrão comum e pode razoavelmente ser descrito como uma prática recomendada.

Dependendo da sua plataforma, você pode encontrar ferramentas que quase fazem o problema desaparecer - a Microsoft tem suporte ODATA para aplicativos conectados que devem criar formulários sobre dados diretamente depois de subir a curva de aprendizado.

Mais pragmaticamente - defina a API necessária para sua camada de dados no aplicativo de desktop e codifique para essa API. Coloque todo o acesso ao banco de dados por trás dessa API - o que realmente melhora as coisas da perspectiva de desenvolvimento do aplicativo - e, em seguida, a localização do código de acesso real ao banco de dados se torna menos significativa (a mesma API pode ser implementada por código que fala diretamente com o banco de dados ou pelo código que fala indiretamente com o banco de dados por meio de um endpoint restante). Se você começar com uma implementação direta, a versão REST será substancialmente um invólucro para a mesma API, para que você não seja muito penalizado ...

Provavelmente não é tão simples como eu gostaria que fosse - mas é um bom padrão, oferece a flexibilidade que você pode precisar sem ir muito longe na rota YAGNI .

— Murph
fonte