REST API vs directamente llamadas de base de datos en la aplicación de escritorio

Actualmente estoy planeando una aplicación que se utilizará en una empresa. Se requiere para construir una aplicación de escritorio. Por el momento, no están seguros de si la aplicación debería estar disponible en dispositivos móviles o navegadores en un futuro próximo.

Tengo dos posibilidades:

1. Acceda a la base de datos directamente desde la aplicación de escritorio

2. Cree una API REST y conéctese a esta

¿Puedo usar una API REST si la aplicación sigue siendo solo una aplicación de escritorio dentro de la empresa? Sé que es posible, pero ¿es "la forma correcta"? (Mejores prácticas)

Hay algunas (posibles) ventajas y desventajas para crear directamente una API REST:

Desventajas

• Tarda más en desarrollarse
• Mas complejo
• El servidor hace más trabajo.
• temas de seguridad
• ¿Más lento? (El servidor y la aplicación de escritorio están en la misma red)

Ventajas:

• Migrar a otras plataformas es más fácil
• La lógica de negocios también es necesaria cuando se llama directamente a la base de datos. No tardará mucho más en desarrollarse
• Lo mismo ocurre con la complejidad.
• Seguridad (como lo menciona tkausl en los comentarios)
• Mantenibilidad (como lo menciona WindRaven en los comentarios)

Cuando se trata de aplicaciones grandes con una gran base de datos que contiene millones de registros, pronto se da cuenta de que las selecciones simples, las actualizaciones, las inserciones y las eliminaciones simplemente no son suficientes.

Entonces comienzas a pensar de una manera diferente. Creas procedimientos y disparadores para ocuparte de cosas más complicadas directamente en la base de datos y esto no es muy bueno. Las bases de datos ofrecen un gran rendimiento al realizar operaciones CRUD. Procedimientos largos? No tanto.

El problema con los procedimientos.

Ahora imagine que cambia a una base de datos que no admite el concepto de procedimientos. ¿Qué vas a hacer? En su lugar, se ve obligado a mover los procedimientos a su base de código, donde puede estar bastante seguro de que una vez que lo programe, digamos Java, siempre permanecerá allí, sin importar el motor de base de datos que elija.

Sin mencionar que sus procedimientos generalmente son parte de su lógica comercial y no es una buena idea tener su lógica comercial salpicada en su base de código y base de datos.

Idealmente, siempre debe tener un mediador entre la base de datos y el cliente que implemente sus propias reglas comerciales. Proporcionar acceso directo a la base de datos no es una buena idea, porque cuando lo hace, el que tiene acceso tiene acceso directo a las tablas y puede hacer casi cualquier cosa con los datos que hay.

Desventajas

• Tarda más en desarrollarse: por supuesto, está creando un nuevo sistema, que requerirá más tiempo que simplemente darle al cliente una cadena de conexión de base de datos y dejarle escribir las consultas.
• Más complejo: Complejidad de un sistema> complejidad de una consulta de base de datos.
• El servidor hace más trabajo: no necesariamente. Con un buen diseño, almacenamiento en caché, ... puede mover la carga del servidor de la base de datos a la del mediador.
• Más lento: ¿ En términos de desarrollo? Si. ¿En términos de velocidad al recuperar datos? No. Puede optimizar su mediador utilizando cachés (como - popular a partir de enero de 2016 - Redis, Elasticsearch) y realmente hacer que entregue datos más rápido que una simple consulta de base de datos.

Ventajas

• Migrar a otras plataformas es más fácil: ¿ Migrar a un nuevo motor de base de datos? Seguro. ¿Migrar todo el mediador a un nuevo idioma? Realmente no.
• La lógica de negocios también es necesaria cuando se llama directamente a la base de datos. No tardará mucho más en desarrollarse: como se explicó anteriormente, el problema de los procedimientos.
• Seguridad: con la autorización adecuada, tener un mediador es definitivamente mucho más seguro que darle a un usuario acceso directo a la base de datos, ya que lo restringe a los puntos finales que ejecutan solo las consultas que desea.
• Mantenibilidad: uno de los mejores beneficios de tener un mediador. Si hay un error en una API a la que llaman sus clientes, lo arregla, inserta la solución en su repositorio de VCS, construye su mediador a partir de la versión correcta de VCS que contiene la solución y todos sus clientes la utilizan repentinamente, sin que necesiten descargar una actualización Esto es simplemente imposible de hacer si las consultas se almacenan directamente en las aplicaciones del cliente. En ese caso, los clientes se ven obligados a actualizar su aplicación.

Aquí está mi opinión sobre el asunto: tiene la idea correcta de querer usar un servicio web, pero puede estar planeando usar la tecnología incorrecta.

Cuando dices REST, supongo que estás hablando de Asp.Net WebApi. Esa es la tecnología incorrecta para aplicaciones de intranet. REST y WebApi son increíbles, no me malinterpreten, pero para cualquier tipo de aplicación interna, los servicios web de WCF son el camino a seguir en mi humilde opinión. Permiten al cliente hacer referencia al punto final del servicio al igual que una biblioteca de clases, lo que significa que no está tratando con XML o JSON en su cliente de escritorio. Estás trabajando con clases y objetos.

En fin, si. Tienes la idea correcta. Si no están seguros de si necesitarán un cliente basado en la web, entonces debe diseñar su sistema para agregarlo fácilmente si deciden que lo quieren más tarde. Es mucho más fácil agregar diferentes tipos de clientes cuando tiene una arquitectura orientada a servicios.

Míralo de esta manera, definitivamente es un patrón común y podría describirse razonablemente como la mejor práctica.

Dependiendo de su plataforma, puede encontrar herramientas que casi hacen que el problema desaparezca: Microsoft tiene soporte ODATA para aplicaciones conectadas que deberían facilitar los formularios sobre los datos una vez que haya escalado la curva de aprendizaje.

Más pragmáticamente: defina la API que necesita para su capa de datos en la aplicación de escritorio y codifique para esa API. Ponga todo el acceso a la base de datos detrás de esa API, que realmente mejora las cosas desde la perspectiva del desarrollo de la aplicación, y luego la ubicación del código de acceso a la base de datos real se vuelve menos significativa (la misma API podría implementarse mediante un código que se comunica directamente con la base de datos o por código que habla indirectamente con la base de datos a través de un punto final de reposo). Si comienzas con una implementación directa, entonces la versión REST será sustancialmente una envoltura de la misma API para que no te penalicen demasiado ...

Probablemente no sea tan simple como me gustaría que fuera, pero es un buen patrón, le brinda la flexibilidad que puede necesitar sin tener que ir muy lejos en la ruta de YAGNI .