[ CONSULTA ] Tecnologías para backend en android

[Dild0]

Hola, todas las apps que hice hasta ahora son locales y tenía pensado hacer un pequeño juego con un servidor de por medio que maneje una base de datos un registro de usuarios, etc.

Que tecnologías me recomendais para afrontar el backend? Que tipo de servicios para comunicar cliente servidor?

Ando un poco perdido en q usar.

[mocelet]

Albricias, un poco de movimiento en el foro de programación

La forma de abordar el online de un juego depende bastante de la mecánica del juego, no es lo mismo un apalabrados que un wordament que un ajedrez que un cuatro en raya o que un juego de carreras online.

Hace poco he reescrito el online de mi cuatro en raya con Kotlin + nginx (SSL) + vert.x + mongodb y tengo otra base de datos redis por ahí para estadísticas internas. Antes era java + netty + mongodb y en el principio de los tiempos usaba kryonet.

El protocolo de comunicaciones es propio, basado en mensajes JSON, aunque por motivos históricos uso TCP ahora soporta REST, websockets y https para el envío de datos confidenciales tipo email o password (antes no había registro propiamente) y consulta de datos que no precisa interacción (la gracia de un websocket o socket es poder interactuar en tiempo real) como puede ser ver el ranking.

Existen soluciones SAAS (software as a service) para crear el backend de un juego sin programar nada, el propio Google Play Games Services, si bien o no son suficientemente personalizables o te metes en un lock-in de cuidado (atarte a un proveedor y sus condiciones) y unas tarifas que igual al principio era gratis pero en cuanto empiezas a tener usuarios, sorpresa.

Si te gusta hacerlo tú mismo, empieza definiendo los flujos cliente-servidor y qué tienes que almacenar y cómo (p.ej. es pecado transmitir en claro la contraseña y guardarla sin hacerle perrerías para que si un hacker accede a la base de datos no pueda extraer fácilmente la misma).

Ver cómo transportarlo (ya en la época que estamos tiraría por REST + JSON o websockets + JSON según la interactividad que requieras) y, si necesitaras notificar usuarios que no estén usando el juego, tendrás que usar el Google Cloud Messaging.

Elegir base de datos, normalmente SQL como mysql o NoSQL como mongoDB ya sea instalándola tú o usando un servicio de terceros. Pero como digo, ahí depende mucho del juego, cada una tiene sus pros y sus contras.

Elegir un lenguaje de programación y un framework para servicios. Si te gusta javascript tienes el venerado node.js , si te gusta java o kotlin yo me inclinaría por vert.x, Play Framework o ya si quieres meterte en el mundo de JEE algún contenedor tipo Wildfly. Y bueno, en .NET y en PHP también se pueden hacer cosas, pero de .NET ni idea y PHP no se me ocurriría usarlo.

He puesto en negrita todos los palabros tecnológicos relacionados, como ves hay mucho donde elegir

Antes de lanzarse a la aventura de elegir tecnologías lo mejor es tirar de papel y boli para definir la arquitectura. Cambia mucho el que sea un juego por turnos cortos (cuatro en raya), largos (apalabrados) o en tiempo real (disparos, carreras), así como si es multijugador de verdad donde hay interacción entre jugadores o es "falso multijugador" como los llamo yo donde juegan varios pero al final que haya más jugadores da igual porque solo sirve para comparar puntuaciones al acabar la partida (caso del wordament).

[Dild0]

 Cita: Originalmente Escrito por mocelet

Albricias, un poco de movimiento en el foro de programación

La forma de abordar el online de un juego depende bastante de la mecánica del juego, no es lo mismo un apalabrados que un wordament que un ajedrez que un cuatro en raya o que un juego de carreras online.

Hace poco he reescrito el online de mi cuatro en raya con Kotlin + nginx (SSL) + vert.x + mongodb y tengo otra base de datos redis por ahí para estadísticas internas. Antes era java + netty + mongodb y en el principio de los tiempos usaba kryonet.

El protocolo de comunicaciones es propio, basado en mensajes JSON, aunque por motivos históricos uso TCP ahora soporta REST, websockets y https para el envío de datos confidenciales tipo email o password (antes no había registro propiamente) y consulta de datos que no precisa interacción (la gracia de un websocket o socket es poder interactuar en tiempo real) como puede ser ver el ranking.

Existen soluciones SAAS (software as a service) para crear el backend de un juego sin programar nada, el propio Google Play Games Services, si bien o no son suficientemente personalizables o te metes en un lock-in de cuidado (atarte a un proveedor y sus condiciones) y unas tarifas que igual al principio era gratis pero en cuanto empiezas a tener usuarios, sorpresa.

Si te gusta hacerlo tú mismo, empieza definiendo los flujos cliente-servidor y qué tienes que almacenar y cómo (p.ej. es pecado transmitir en claro la contraseña y guardarla sin hacerle perrerías para que si un hacker accede a la base de datos no pueda extraer fácilmente la misma).

Ver cómo transportarlo (ya en la época que estamos tiraría por REST + JSON o websockets + JSON según la interactividad que requieras) y, si necesitaras notificar usuarios que no estén usando el juego, tendrás que usar el Google Cloud Messaging.

Elegir base de datos, normalmente SQL como mysql o NoSQL como mongoDB ya sea instalándola tú o usando un servicio de terceros. Pero como digo, ahí depende mucho del juego, cada una tiene sus pros y sus contras.

Elegir un lenguaje de programación y un framework para servicios. Si te gusta javascript tienes el venerado node.js , si te gusta java o kotlin yo me inclinaría por vert.x, Play Framework o ya si quieres meterte en el mundo de JEE algún contenedor tipo Wildfly. Y bueno, en .NET y en PHP también se pueden hacer cosas, pero de .NET ni idea y PHP no se me ocurriría usarlo.

He puesto en negrita todos los palabros tecnológicos relacionados, como ves hay mucho donde elegir

Antes de lanzarse a la aventura de elegir tecnologías lo mejor es tirar de papel y boli para definir la arquitectura. Cambia mucho el que sea un juego por turnos cortos (cuatro en raya), largos (apalabrados) o en tiempo real (disparos, carreras), así como si es multijugador de verdad donde hay interacción entre jugadores o es "falso multijugador" como los llamo yo donde juegan varios pero al final que haya más jugadores da igual porque solo sirve para comparar puntuaciones al acabar la partida (caso del wordament).

Muchisimas gracias, realmente es lo que necesitaba, se trata de un juego por turnos tipo damas. Ahora tengo que estudiar bien que tocar,

Con NodeJs y mongo he trabajado pero el hosting por lo que he visto es carete y heroku + mongolab se quedaría algo corto pronto.En realidad me gustaría tirar más por Java

[mocelet]

El problema de los juegos con turnos donde el turno puede ser corto (en cuatro en raya normalmente la gente mueve en tres o cuatro segundos, en las damas hay más estrategia y puede llevar más tiempo pero también hay movimientos inmediatos como en las capturas obligadas) es que están a medio caballo entre un juego a tiempo real y uno por turnos tipo apalabrados.

Y no tiene que ver nada cómo se afronta uno u otro.

Si fueran turnos largos podrías notificar exclusivamente por GCM de nuevos movimientos, y te daría igual si el usuario está en la app o no. Es lo que hace apalabrados y es un modelo donde tienes tropecientas partidas a la vez, la mayoría detenidas a que el adversario mueva. Si no le llegan las notificaciones tampoco pasa nada, como el usuario entra a la app cuando le apetece jugar ya se refrescan las partidas de forma automática o manual al entrar.

Para turnos (muy) cortos GCM no vale porque la notificación igual tarda en llegar más de lo deseado.
- Ventaja: no hace falta que los dos usuarios estén conectados a la vez, pero el usuario tiene que saber que rara vez va a jugar una partida del tirón y no sé si en un juego de tanta concentración y estrategia tiene sentido continuarla más tarde porque toda la estrategia se te ha olvidado ya.
- Desventaja: más estrés en la base de datos que tiene que guardar el estado de todas las partidas el tiempo que duren. Y en ese caso más que una base de datos al uso convendría un sistema de colas de mensajes con persistencia (rabbitmq y similares), que de paso es más escalable.

Si lo planteas como juego en tiempo real es más fácil: un servidor que gestiona el estado de las partidas en curso y conexión permanente con socket o websocket mientras dure la partida y a correr.
- Problema, tienen que estar conectados a la vez los dos usuarios, eso solo puedes hacerlo si tienes muchos usuarios durante el día o nadie encontrará rival para jugar. Asegúrate de tener un servidor con eventos asíncronos como node.js, netty o vert.x para que los usuarios que están esperando al rival no consuman recursos en forma de hilos de ejecución.
- Ventaja, la base de datos está tranquila porque la partida normalmente dura unos minutos y guardas el estado en memoria. No te hace falta persistencia del estado de todas las partidas porque si el servidor se cae solo afecta a la partida en curso del usuario y una vez interrumpida tampoco tiene sentido recuperarla porque probablemente ni los dos usuarios vuelvan a coincidir conectados.

Luego está la solución híbrida, si los usuarios están conectados al mismo tiempo trata la partida como si fuera tiempo real y si no lo están como si fuera por turnos largos. Tiene las ventajas de ambos acercamientos y también las desventajas de ambos. No he visto ningún juego ni ningún backend SAAS que ofrezca este acercamiento, probablemente porque no tiene sentido o porque la complejidad no compensa Aun así... algún día me animaré a implementar una prueba de concepto, quizá no para el cuatro en raya pero sí para otros juegos que tengo en la nevera.

[Dild0]

Gracias por la master class

En principio son turnos largos, va a ser un juego de entrar realizar tu turno y pirarte hasta que te apetezca volver a entrar o te llegue la notificación avisando de que puedes volver a jugar un turno.

Repito

gracias por la clase

[mocelet]

A mandar Ya nos dirás cómo lo has organizado al final. Supongo que de conexiones persistentes puedes olvidarte y tirar de GCM para notificaciones y peticiones HTTP REST para recibir el estado actual y enviar el movimiento. La arquitectura de la base de datos sí es más divertida, me inclinaría por mongo por la flexibilidad aunque suponga duplicar información en algunos casos para que sea eficiente.

[Dild0]

Buenas!

Perdona mi desconocimiento en servidores.... igualmente quiero pelearme con ellos

He estado leyendo un poco sobre nginx y me quiero decantar por el pero me surgen dudas.

nginx ¿sustituye a tomcat?

Mi idea es la que comentas montar un API REST en una ruta ip/API por ejemplo con todo los métodos que necesite mi app guardando y recogiendo de base de datos

Como se programa está Api sobre nginx, ¿java? todo lo que leo es que nginx haría de proxy inverso sobre tomcat pero mi idea es tener lo mínimo.

[mocelet]

Como bien dices, nginx es un proxy, un intermediario de las conexiones entrantes que las procesa y redirige donde haga falta. No sustituye al servidor de aplicaciones (tomcat, wildfly, vert.x, node.js, etc.)

¿Que para qué quieres un proxy en vez de conectar directamente con el puerto del servidor de aplicaciones? Porque es ligero y facilita enormemente las conexiones seguras SSL. Instalas los certificados en nginx que es editar un fichero de texto y poco más, y los usuarios se conectan a través de nginx de forma segura. Sin embargo, los servicios por dentro los implementas sin preocuparte de cómo se configura el SSL en cada servidor o en cada servicio.

Tiene más ventajas, es muy bueno para servir contenido web estático, permite balanceo de carga, reescritura de URLs y redirección de tráfico. A mí por ejemplo esto último me vino muy bien cuando cambié de servidor, tuve el viejo con nginx redirigiendo tráfico al nuevo mientras se actualizaban las DNS y así el 100% de los usuarios estaban accediendo al servidor nuevo incluso si la IP a la que estaban conectados era la vieja.

Si no quieres usar nginx tendrás que lidiar con Tomcat y la keystore de java para instalar los certificados. Y si mañana quieres instalar un servicio basado en node.js tendrás que lidiar con la configuración de SSL en node.js. O si decides usar vert.x, más de lo mismo, a buscar cómo se implementa SSL. Y el día que tengas que renovar el certificado, fiesta, porque tendrás que cambiarlo en varios sitios en vez de en uno solo. Ya solo por eso merece la pena, lo configuras una vez y te olvidas de que existe si quieres.

[Dild0]

 Cita: Originalmente Escrito por mocelet

Como bien dices, nginx es un proxy, un intermediario de las conexiones entrantes que las procesa y redirige donde haga falta. No sustituye al servidor de aplicaciones (tomcat, wildfly, vert.x, node.js, etc.)

¿Que para qué quieres un proxy en vez de conectar directamente con el puerto del servidor de aplicaciones? Porque es ligero y facilita enormemente las conexiones seguras SSL. Instalas los certificados en nginx que es editar un fichero de texto y poco más, y los usuarios se conectan a través de nginx de forma segura. Sin embargo, los servicios por dentro los implementas sin preocuparte de cómo se configura el SSL en cada servidor o en cada servicio.

Tiene más ventajas, es muy bueno para servir contenido web estático, permite balanceo de carga, reescritura de URLs y redirección de tráfico. A mí por ejemplo esto último me vino muy bien cuando cambié de servidor, tuve el viejo con nginx redirigiendo tráfico al nuevo mientras se actualizaban las DNS y así el 100% de los usuarios estaban accediendo al servidor nuevo incluso si la IP a la que estaban conectados era la vieja.

Si no quieres usar nginx tendrás que lidiar con Tomcat y la keystore de java para instalar los certificados. Y si mañana quieres instalar un servicio basado en node.js tendrás que lidiar con la configuración de SSL en node.js. O si decides usar vert.x, más de lo mismo, a buscar cómo se implementa SSL. Y el día que tengas que renovar el certificado, fiesta, porque tendrás que cambiarlo en varios sitios en vez de en uno solo. Ya solo por eso merece la pena, lo configuras una vez y te olvidas de que existe si quieres.

Ahora entiendo todo,,, por eso cuando buscaba solo veía redireccionamientos

Me voy a decantar por está opción, me parece muy buena así sobre el papel como lo comentas

[Dild0]

Buenas, necesito un poco de ayuda con el certificado SSL

Os pongo al día, al final estoy haciendo el webservice con Spring Boot , mysql y tomcat, desplegado en mi VPS con servidor nginx, hice una prueba de redirigir las peticiones de una url del puerto 80 al 8080 y genial, así pues voy a dar el siguiente paso y crear un certificado SSL para que todo el tráfico sea seguro pero aquí ya estoy teniendo problemas.

Al servidor le he instalado el panel webmin para ayudarme un poco al instalar modulos necesarios.

Bien con todo lo anterior montado entro en la página de https://certbot.eff.org para crearme un certificado y que se autorenueva solo.

Sigo todos los pasos que me indica para un servidor nginx instalado sobre un SO centos 7 y llega un punto que ejecuto el comando sudo certbot --nginx el cual en teoría me crea el certificado y me configura, me pide introducir mi dominio, se lo meto midominioejemplo.com y me da un petardazo que dice...

Cannot find a VirtualHost matching domain midominioejemplo.com


Hasta aquí he llegado, me está costando esto del SSL

[mocelet]

Anda, justo hoy me acordé de este post porque voy a ver si le añado juego asíncrono a mi servidor de juegos.

El certificado SSL al final compré uno barato de Comodo que es compatible con todo bicho androide por viejo que sea y lo instalé a mano editando los ficheros de configuración de nginx. La herramienta mágica del let's encrypt no la he llegado a usar.

Los tutoriales de Digital Ocean son bastante buenos, igual es el que has seguido, pero por si acaso aquí te dejo el de centos 7 y nginx: https://www.digitalocean.com/communi...pt-on-centos-7

@Dexafree pilota del tema, le invocamos aunque hace tiempo que no le veo por aquí.

EDIT: Sobre lo de que no encuentra el Virtual Host, ¿tienes puesto el server_name midominioejemplo.com; dentro del bloque server de la config de nginx?

[Dild0]

Gracias mocelet, la verdad que he seguido otro manual diferente al que indicas, mañana con más calma empiezo de 0, respecto a la config del server name efectivamente lo tengo puesto, lo mejor es empezar de nuevo q con tanto quita pon algo abre liado.

Gracias

[Dild0]

Buenas noticias,

Ya tengo funcionando el certificado con el manual que me has pasado, fácil, sencillo y muy bien explicado

Muchas gracias por todo, no te imaginas la cantidad de cosas que llevo aprendidas en estas semanas de trasteo.

Continuamos.....

[Dild0]

Buenas...

pregunta... ¿Cual es la mejor manera de consumir el api rest en android? He estado leyendo y me he encontrado con Retrofit + Rxjava, también he oído RoboSpice

¿Alguna sugerencia o consejo?

[mocelet]

Retrofit es bastante habitual y tiene detrás a la gente de Square que es una garantía de estar bien probada. RoboSpice parece que por debajo usa otra biblioteca, así que para eso usa Retrofit directamente sin intermediarios.

Lo de RxJava ya casi es más cuestión de gustos, está de moda y es otra mentalidad a la hora de plantear el tratamiento de eventos. Siempre puedes añadirlo más tarde...