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:

Acceda a la base de datos directamente desde la aplicación de escritorio
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)

— devz
fuente

¿Realmente cuentas Security issuescomo una desventaja para la API REST?

— tkausl

Puedo proteger mi API con, por ejemplo, OAuth2 y TLS, pero esto agregará más trabajo. No sé qué tan segura es una llamada directa a la base de datos. Por ejemplo, con JPA. Es por eso que agregué un signo de interrogación ya que no estoy realmente seguro.

— devz

Bueno, no puede obtener menos seguridad que una llamada db directa, a menos que regale el inicio de sesión raíz.

— tkausl

Otra ventaja, un cambio en la lógica de negocios solo necesita hacerse en la API REST y desplegarse en el servidor, no se realiza y luego cada cliente se actualiza. (siempre que la interfaz API no cambie como resultado)

— RubberChickenLeader

¿La base de datos se ejecuta en la misma computadora que la aplicación? Si no, ni siquiera pensaría en el acceso directo de escritura a la base de datos.

— CodesInChaos

Respuestas:

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.

— Andy
fuente

¿Con qué frecuencia enfrentó el desafío de cambiar a una base de datos que no admite el concepto de procedimientos cuando realmente los estaba usando?

— Harpun

@harpun Dos veces en los últimos 2 años. Cuando yo y el equipo con el que trabajaba en un proyecto decidimos pasar de MySQL o PostgreSQL a MongoDB como parte del cambio a Node.js y también evadir bloqueos muertos y almacenar objetos como agregados directamente.

— Andy

Hay otra opción que solo el acceso directo a db. La "API mediadora" no tiene que usar HTTP, por lo tanto, el servidor HTTP no tiene que estar involucrado en absoluto. Puede ser solo API de nivel de código. Otra pregunta es, siempre que no esté satisfecho con la velocidad de su lenguaje de programación, es si debe tener API (acceso REST) escrito con algún otro idioma / plataforma que no sea su lógica comercial ...

— forsberg

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.

— RubberDuck
fuente

Es estúpidamente fácil usar un cliente para deserializar json a objetos. Las clases incluso se pueden generar automáticamente a partir del ejemplo json utilizando json2csharp.com . Funciona muy bien con el cliente http del paquete nuget microsoft.aspnet.webapi.client. Está de vuelta en tierra de objetos más rápido que tratar con referencias de clientes WCF, lo prometo, por lo que este no debería ser el controlador principal para elegir WCF.

— Esben Skov Pedersen el

@EsbenSkovPedersen hay una diferencia entre estúpido fácil y automático .

— RubberDuck el

¿Porque nunca hay problemas con WCF? Eso no puede estar bien.

— Esben Skov Pedersen

¿Quién dijo que no había problemas con WCF @EsbenSkovPedersen? Claro que no. Cada pieza de tecnología tiene sus problemas. ¿Cuál es tu problema?

— RubberDuck el

Cuando dices que es más fácil que estúpidamente fácil, implicas eso. No tengo un problema

— Esben Skov Pedersen el

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 .

— Murph
fuente