El "experimento" que se me ha ocurrido es simplemente un tipo de tracking de actividad. El dominio para mí es bien conocido: se trata de simular usuarios jugando a un juego de mach-3 (cake swap de zynga en este caso) y hacer un seguimiento de los combos que en cada movimiento se generan en el tablero (un combo en estos juegos se logra al unir más de 3 fichas de cada color).
Un poco off-topic porque no es node, he hecho un programa en Groovy para simular los jugadores/partidas/movimientos. El tema de elegir una plataforma Java es por el multithreading para simular usuarios jugando simultáneamente. Se le puede echar un vistazo al código en https://bitbucket.org/telekosmos/cakebot.
Las partes de backend están menos desarrolladas, es todavía un WIP con muchas cosas que hacer. Hasta ahora estuve más enfocado en los temas de arquitectura (DDD, CQRS) porque pienso que meterse a hacer microservicios puede ser muy bonito pero si se tiene algo a la vista o en mente, un big picture, que las cosas no entren en el caos es bueno.
He estado usando seneca como una librería que permite construir microservicios extensible para usar distintos tipos de canales de comunicación (transporte) por medio de adaptadores (o plugins). También dispone de un api gateway con plugins para integración con node (express, hapi, ...). Hay un artículo formal de uno de su lead maintainer en http://www.richardrodger.com/seneca-microservices-nodejs. Sobre esto no hay código sólido todavía aunque se puede ver un poco de hands-on en https://bitbucket.org/telekosmos/mservs/overview.
Este paradigma se basa en la separación de escrituras y lecturas. Las escrituras se hacen usando comandos (la C), separadamente (la S) de las lecturas o queries (la Q). Esto encaja bien con una arquitectura de microservicios, de forma que cada uno puede asumir una responsabilidad (la R). Tiene a su vez consideraciones, como de disponibilidad de los datos (el llamado CAP theorem).
Hay una librería llamado reSolve, constituida por una serie de paquetes node, que facilita la implementación y es extensible, al igual que seneca, por medio de adaptadores. Para ver como se ataca el desarrollo de adaptadores en reSolve, en https://bitbucket.org/telekosmos/resolve-dev hay una simple implementación de adaptadores para bus y storage, simplemente basados en rx y un simple storage (https://bitbucket.org/telekosmos/resolve-dev/src, resolve-bus-rx, resolve-storage-lowdb). Más en los Readme del repo.
Con un par de artículos/tutoriales (https://community.devexpress.com/blogs/oliver/archive/2017/03/28/devextreme-real-world-patterns-orchestrating-microservices.aspx y https://community.devexpress.com/blogs/oliver/archive/2017/06/02/devextreme-real-world-patterns-event-sourcing-architecture.aspx), intento obtener inspiración para seguir un patrón y combinar una arquitectura de microservicios implementando CQRS y event sourcing a través de seneca y resolve.
Con todo esto, el objetivo es intentar hacer un(os) pequeño(s) servicio(s) de forma que el cliente en java genere partidas simultáneas y envíe peticiones a un api conectada a un pequeño enjambre de microservicios (seneca en principio) que envíen comandos (utilizando el scaffold que pueda proporcionar reSolve) que envíen eventos con un payload relacionado con los combos generados en cada movimiento a un topic de kafka.
Como se ve, queda por hacer bastante:
- adaptadores a kafka para seneca y resolve. Kafka es, entre otras cosas, un event store (capacidades para publicación de eventos y almacenamiento) Para resolve tendrá que implementarse como un bus y a la vez como un storage; para seneca solo para que se comuniquen los microservicios (usarán kafka como bus o message queue)
- definir agregados del dominio donde tendrá que ir buena parte de la lógica que se usará en comandos y queries (por separado!)
- el api gateway, endpoints y demás
- dataware house, "entity views", transformar los datos para un determinado consumo/cliente
- un cliente que consuma los eventos. No está claro esto, porque kafka-streaming puede ser un uso interesante, pero solo hay sdk para java.
En realidad está previsto tener algo entero ("as a whole") y estable mínimo para primavera si no hay otros asuntos que requirieran atención en el tiempo libre.