Aplicación de escritorio en dos escenarios

  1. 7 months ago
    Edited 7 months ago

    Quiero desarrollar una aplicación con base de datos, me gustaría conocer sus recomendaciones. Se trata de una aplicación de escritorio en dos escenarios:

    A) La aplicación ejecutada desde varios equipos interactuando con un servidor de base de datos (PostgreSQL) alojado en la nube.
    B) La aplicación ejecutada desde varios equipos interactuando con SQLite local y replicando al resto de los equipos.

    ¿Cuál de los escenarios sería la mejor opción? Por el momento el desarrollo de una aplicación web queda descartada, aproximadamente serian 30 equipos clientes trabajando simultáneamente.

    Gracias anticipadas por su retroalimentación.

  2. Tengo experiencia con la opción A) con cierta diferencia, funciona bien, cuando la base de datos está cerca de los clientes, en mi caso, <100ms ping, recuerde usar conexiones seguras, y aunque no lo recomiendan (conectarse directamente a la DB desde internet) monitoreando la red y con contrafuegos, tiene buen rendimiento.

    Problemas: cuando c cae la conexion con un proveedor, normalmente el cliente tiene un proveedor de respaldo (con menos capacidad, digamos por móbil) y la aplicacion está monitoreando constantemente la conexion (un "SELECT 1;") y en casos críticos graba localmente y cuando vuelve a conectarse, c actualiza.

  3. Eduardo G

    5 Sep 2018 Pre-Release Testers Europe (Madrid, Spain)

    @BernardoMonsalve Tengo experiencia con la opción A) con cierta diferencia, funciona bien, cuando la base de datos está cerca de los clientes, en mi caso, <100ms ping, recuerde usar conexiones seguras, y aunque no lo recomiendan (conectarse directamente a la DB desde internet) monitoreando la red y con contrafuegos, tiene buen rendimiento.

    Problemas: cuando c cae la conexion con un proveedor, normalmente el cliente tiene un proveedor de respaldo (con menos capacidad, digamos por móbil) y la aplicacion está monitoreando constantemente la conexion (un "SELECT 1;") y en casos críticos graba localmente y cuando vuelve a conectarse, c actualiza.

    Yo he implementado algo similar y mi solución fue trabajar siempre sobre un estado local que se sincroniza cada vez que puede.

    El concepto "sincronización" es un nido de serpientes, así que hay que irse con mucho cuidado. Todos los problemas que no existen en local (concurrencia) y en remoto (gestión automática de peticiones) adquieren un cariz muy raro en la sincronización.

    La ventaja es que permite mucha flexibilidad. Especialmente en clientes móviles. El truco, obviamente es minimizar las escrituras (y eliminar la capacidad de escribir a registros maestros) y poner timestamps a casi todo.

    La aplicación local ni siquiera sabe, en su mayor parte, que existe la base de datos remota. Todo lo trabaja en local. Un proceso separado es el que se encarga de ir consultando el estado remoto y de hacer el intercambio cuando puede.

    La velocidad al ser 100% local es ideal. Haciendo bien el "protocolo" de timestamping puedes minimizar enormemente el flujo de datos.

    Esencialmente lo único que trabaja sobre la base de datos principal es cualquier dashboard que pongas para monitorizar globalmente.

    Es exactamente como funcionan todos los clientes de correo de las últimas tres décadas, incidentalmente. La clave es el concepto de "paquete de información único" con fechas (un mail, un contacto, un evento).

  4. José M

    5 Sep 2018 Pre-Release Testers, Xojo Pro Spain

    Para conexiones remotas con base de datos, siempre, siempre usa tunel ssl o VPN. Es súper arriesgado publicar un servidor de bases de datos a internet.

  5. Eduardo G

    5 Sep 2018 Pre-Release Testers Europe (Madrid, Spain)

    @José M&iacute;a Terry Jiménez Para conexiones remotas con base de datos, siempre, siempre usa tunel ssl o VPN. Es súper arriesgado publicar un servidor de bases de datos a internet.

    Mejor todavía: Ni siquiera pienses que existen conexiones a bases de datos remotas. Siempre monta un API intermedio que se comunique. Nada del cliente debería llegar al servidor de base de datos sin haber sido procesado.

    Ni siquiera con tunel, porque eso sigue necesitando un servidor "conectable" por red. La única conexión del servidor tiene que ser a la misma máquina a un proceso que la gestione, y este se habla con el que gestiona peticiones remotas.

  6. Javier M

    5 Sep 2018 Pre-Release Testers, Xojo Pro AprendeXojo - Europe, Spain

    A no ser que sea en LAN, ningún cliente debería conectar directamente contra una BBDD remota… sino hacerlo a través de una API. Aparte de mayor seguridad, también aporta mayor flexibilidad; si cambias de motor/esquema de BBDD, sólo tendrás que modificar la capa de la API, no los clientes…

    Javier

  7. @Javier Meacute;ndez A no ser que sea en LAN, ningún cliente debería conectar directamente contra una BBDD remota… sino hacerlo a través de una API. Aparte de mayor seguridad, también aporta mayor flexibilidad; si cambias de motor/esquema de BBDD, sólo tendrás que modificar la capa de la API, no los clientes…

    Javier

    Si, eso recomiendan, pero mi experiencia muestra otros escenarios, durante años, 5 mínimo, conozco no una, sino decenas de basedatos postgres, asegurado con SSL Monitoreando constantemente TODAS las conexiones entrantes, y aparte de mucho HTTP y wordpress tratando de buscar "huecos", no he tenido un sólo ataque contra postgres, ni siquiera el puerto 5432 (ahunque NO se usa ese puerto), tal vez he tenido buena suerte, pero, cómo c explica entonces los ataques HTTP??, (yo creo que la IP q asigna el proveedor ya está en una "lista negra" y la conocen los atacantes, porque son nuevos dominios en nuevos proveedores con nuevas IPs... ??)

  8. Andres M

    5 Sep 2018 Pre-Release Testers

    Una alternativa: construir un servicio en el servidor y que los llamados a base de datos sean en realidad consultas al servicio. Si se cae internet, inmediatamente se sabe. no tienes problema de ir a dejar una transacci´øn en la mitad de algo y tiene la ventaja de que puedes consumir incluso si es local.

  9. @Andres M Una alternativa: construir un servicio en el servidor y que los llamados a base de datos sean en realidad consultas al servicio. Si se cae internet, inmediatamente se sabe. no tienes problema de ir a dejar una transacci´øn en la mitad de algo y tiene la ventaja de que puedes consumir incluso si es local.

    Bueno hay muchas formas de hacer las cosas, la que ud. propone está bien, sin embargo hay operaciones (sobre todo OLTP) donde cambian mucho las tablas, y c necesita esta actualizada en todo momento, para que colocar otro servicio, que c tiene que configurar y mantener además de programar cuando c puede hacer de una forma segura con SSL? y lo d transacciones, pues bien sea que c inicie una transaccion local o en un procedimiento en la BD, la transacción c ejecuta TODA o no c ejecuta independientemente de donde c inicie (cleinte o servicio).

    yo he tenido que hacer APIs (http/json) que consumen clientes externos, pero son bastante puntuales y especializadas y son muy pocas realmente. Esa es mi experiencia ;)

or Sign Up to reply!