mvc - JDBC vs servicio web para Android

spring boot rest api angular

Question

¿Alguien puede responder sobre mi dilema qué método usar para conectar un dispositivo Android a mySQL o Postgresql?

Puedo hacerlo de ambas maneras sin ningún error ni problema, sin una diferencia notable, pero todos recomiendan el servicio web en lugar de usar el controlador jdbc y la conexión directa.

¿Alguien puede explicar por qué con algunos hechos?

EDITAR: No mencioné que es más simple y necesita menos tiempo para hacerlo en jdbc. Entonces, ¿por qué el servicio web, o por qué no?

Answer 1

Además de todo lo que Craig Ringer dijo, y estoy completamente de acuerdo, JDBC tiene otro problema: forzará a exponer su base de datos al mundo. Si desea que los dispositivos Android accedan a él, deberá proporcionar a su aplicación las credenciales de la base de datos, y la base de datos deberá tener acceso público.

El uso de un WebService o RESTful API es claramente el camino a seguir para hacer que su aplicación sea segura.

Answer 2

Otra opción sería usar una herramienta de sincronización de base de datos como SymmetricDS.

Esto le permitiría tener una base de datos Postgres en su servidor y una base de datos SQLite en su tableta.

SymmetricDS sincronizaría las bases de datos a través de HTTP, cuando haya una conexión disponible. No tiene que sincronizar todo el DB por supuesto, solo las partes relevantes.

(No estoy afiliado a SymmetricDS)

Answer 3

Puedo pensar en algunas razones

1. Compatibilidad con el controlador JDBC de Android para su base de datos.
2. La agrupación de conexiones en varios dispositivos Android hace que sea difícil monitorearlos y limitarlos.
3. Los conjuntos de resultados enviados desde el DB a Android consumirán mucho ancho de banda y energía de la batería .
4. Los proxies generalmente permiten el acceso HTTP a su dispositivo.
5. Exponer su base de datos directamente al cliente tiene implicaciones de seguridad .

Los servicios web pueden proporcionar funciones adicionales sobre la conexión JDBC como autenticación / calidad de servicio / autorización / solicitudes GET condicionales / manejo de errores, etc. JDBC no puede hacer ninguna de estas funciones.

Answer 4

Cree que es más simple y más rápido hacerlo con JDBC porque no está considerando el entorno operativo del mundo real de teléfonos y dispositivos portátiles. A menudo tienen conectividad flakey a través de errores de reescritura de tráfico proxy y firewalls locos. Por lo general, utilizan una capa de transporte de red que tiene altas tasas de pérdida de paquetes variables y latencias que varían en muchos órdenes de magnitud en cortos períodos de tiempo. TCP realmente no es excelente en este entorno y particularmente lucha con conexiones de larga vida.

El beneficio clave de un servicio web es que:

• Tiene conexiones de corta vida con estado mínimo, por lo que es fácil volver a donde estabas cuando el dispositivo cambia de red WiFi, a / desde celular, pierde conectividad brevemente, etc .; y

• Puede pasar por todos, pero los servidores web más terribles y draconianos

Normalmente encontrará problemas con una conexión JDBC directa. Uno de los desafíos consiste en agotar las conexiones muertas, restablecer sesiones y liberar bloqueos en la sesión anterior (ya que el servidor puede no decidir que está muerto al mismo tiempo que el cliente). Otro es la pérdida de paquetes que causa operaciones muy lentas, transacciones de base de datos de larga duración y los consiguientes problemas con las duraciones de los bloqueos y las tareas de limpieza transaccional. También conocerá todas las variedades de servidores proxy y cortafuegos dementes y rotos bajo el sol: proxies que soportan CONNECT pero que luego dan por hecho que todo el tráfico es HTTP y lo destruye si no lo es; cortafuegos con seguimiento de conexión con errores y con estado que provocan que las conexiones fallen o pasen a un estado zombie semiabierto; cada problema NAT que puedas imaginar; los operadores "útilmente" generan TCP ACK para reducir la latencia, sin importar los problemas que ocasionan el descubrimiento de pérdida de paquetes y el tamaño de ventana; loco bloqueo del puerto; etc.

Como todos usan HTTP, puede esperar que funcione, al menos, muchísimo más que cualquier otra cosa. Esto es particularmente cierto ahora que los sitios web comunes usan el estilo de comunicación REST + JSON incluso en aplicaciones web móviles.

También puede escribir sus llamadas al servicio web para ser idempotentes utilizando tokens de solicitud únicos. Eso permite que su aplicación vuelva a enviar solicitudes de modificación sin temor a que realice una acción contra la base de datos dos veces. Ver idempotence y definir idempotencia .

En serio, JDBC desde un dispositivo móvil podría parecer una buena idea ahora, pero la única forma en que lo consideraría sería si los dispositivos móviles estuvieran todos en una única red WiFi de alta confiabilidad bajo mi control directo. Incluso así lo evitaría por razones de gestión del rendimiento de la base de datos si fuera posible. Puede usar algo como PgBouncer para poner en común conexiones entre muchos dispositivos en el servidor para que la agrupación de conexiones no sea un gran problema, pero la limpieza de conexiones perdidas y abandonadas es necesaria, como lo es el tráfico de TCP necesario para hacerlo funcionar y el largo tiempo transacciones de conexiones abandonadas.