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:

1. Acesse o banco de dados diretamente do aplicativo Desktop

2. 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)

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.

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.

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 .