Presentación hecha para el MadridGUG sobre los problemas de compartir dominios y servicios entre proyectos Grails.

1. COMPARTIR DOMINIOS Y SERVICIOS ENTRE PROYECTOSCOMPARTIR DOMINIOS Y SERVICIOS ENTRE PROYECTOS
GRAILS PARECÍA UNA BUENA IDEAGRAILS PARECÍA UNA BUENA IDEA
03/12/2019

2. JESÚS JIMÉNEZ BALLANOJESÚS JIMÉNEZ BALLANO
Desarrollador desde mucho.
Fundé Kiakora Software después de varios
años de autónomo.
Mi primera vez con Groovy y Grails fue allá
por 2010.
Ahora ayudando a a reinventar las
tarjetas de crédito.
Tymit
@jjballano jesus@kiakora.com

3. TYMIT IS HIRING!TYMIT IS HIRING!
Backend
Android/Kotlin
iOS/Swift
https://tymit.workable.com

4. ¡ESTOY (CASI) DISPONIBLE PARA OTRO PROYECTO!¡ESTOY (CASI) DISPONIBLE PARA OTRO PROYECTO!
jesus@kiakora.com

5. HACE DOS AÑOS...HACE DOS AÑOS...
Nuevo proyecto que consistía en:
API usada por las aplicaciones móviles.
Panel de administración web para la gestión interna.
“Juntemos todos los servicios y dominios
en un plugin y así reutilizamos el código
en ambas aplicaciones.”

6. DOS AÑOS MÁS TARDE...DOS AÑOS MÁS TARDE...
“Voy a presentar una charla en el Madrid
GUG sobre esa (¿mala?) decisión tomada
hace 2 años.”

7. ESTRUCTURA INICIAL DEL PROYECTOESTRUCTURA INICIAL DEL PROYECTO
Un plugin Grails para alojar servicios y dominios.
Proyecto REST para hacer la función de API.
Proyecto web para el panel de administración.
Otros proyectos pequeños.

8. PROBLEMASPROBLEMAS

9. DISCLAIMERDISCLAIMER
Algunos de los problemas vienen por compartir base de
datos y no simplemente por compartir dominios y
servicios.
Otros problemas vienen por tener más de un nodo
levantado de los proyectos.

10. ¿DÓNDE LO COLOCO?¿DÓNDE LO COLOCO?
Hay clases que van a ser usadas solo por uno de los
proyectos.
Plugin: Añadimos un montón de código que no se va
a usar en los proyectos principales.
Proyecto: Tenemos servicios y dominios
desperdigados.

11. EJEMPLO: DOMINIOS USUARIOEJEMPLO: DOMINIOS USUARIO
Cada aplicación tiene su dominio Usuario para el login.
Los servicios utilizarán ambos objetos.

12. DEPENDENCIAS NO USADASDEPENDENCIAS NO USADAS
Cualquier dependencia del plugin irá en todos los
proyectos, la usen o no.
WAR/JAR más grandes.
Mayor uso de memoria.
Mayor tiempo de arranque.

13. GORM MULTI-TENANTGORM MULTI-TENANT
Se di culta bastante el trabajo con multi-tenant si a
uno de los proyectos le viene bien implementarlo y al
otro no.

14. VARIABLES DE ENTORNOVARIABLES DE ENTORNO
Tener dependencias y servicios comunes nos obliga a
añadirle a un proyecto variables de entorno que igual
no necesita.

15. ACTUALIZACIONES DE VERSIONES DE GRAILSACTUALIZACIONES DE VERSIONES DE GRAILS
A veces tienes que actualizar todos o ninguno por
incompatibilidades entre versiones.

16. CACHÉSCACHÉS
Se di culta mucho el trabajar con cachés.
Hibernate (desactivar caché de segundo nivel)
@Cacheable

17. DATABASE (MIGRATION PLUGIN)DATABASE (MIGRATION PLUGIN)

18. Mismos dominios lleva normalmente a atacar a la
misma base de datos.
Si tienes más de 1 nodo por proyecto, mismo problema.

19. VERSIONADO DE LAS TABLASVERSIONADO DE LAS TABLAS
grails.gorm.default.mapping = {1
version false2
}3

20. BLOQUEOS EN TIEMPO DE ARRANQUEBLOQUEOS EN TIEMPO DE ARRANQUE
Mayor tiempo de arranque por el bloqueo que se hace
de la base de datos.

21. CAMBIOS EN EL ESQUEMACAMBIOS EN EL ESQUEMA
Se pueden producir errores si algún proyecto:
Elimina un campo de la base de datos.
Añade un campo no nullable.
Renombra una tabla o un campo.
Hasta que el otro proyecto despliegue con la nueva
versión del plugin.

22. DESPLIEGUE DE LOS PROYECTOSDESPLIEGUE DE LOS PROYECTOS
Si hay un cambio importante en el esquema, hay que
desplegar todos los proyectos que lo usen.
El más importante tendrá que desplegar primero.

23. ¿DÓNDE PONGO LOS SCRIPTS DE ACTUALIZACIÓN?¿DÓNDE PONGO LOS SCRIPTS DE ACTUALIZACIÓN?
Plugin
Cualquier proyecto que levante cambia el esquema y puede
romper a los otros.
Proyectos
El otro proyecto puede fallar.
Los tests funcionales/integración en el proyecto que no tiene
los scripts se complican.
Difícil hacer tests de integración ables dentro del plugin.
Los cambios que el otro proyecto necesita, se tienen que poner
en el que tiene los scripts.

24. BLOQUEOS DE TABLASBLOQUEOS DE TABLAS
Cuidado con vistas materializadas actualizándose.
Los bloqueos de tablas o las pueden afectar a otras
partes críticas.

25. (POSIBLES) SOLUCIONES(POSIBLES) SOLUCIONES
Algunas compatibles entre sí, otras soluciones
alternativas.

26. DISCLAIMERDISCLAIMER
No todas las soluciones las he probado.

27. PARTIR EL PLUGIN EN VARIOS PLUGINSPARTIR EL PLUGIN EN VARIOS PLUGINS
Con trozos más pequeños cada proyecto puede
incorporar solo lo que necesite.

28. EL PLUGIN SOLO CON LO QUE REALMENTE ES COMÚNEL PLUGIN SOLO CON LO QUE REALMENTE ES COMÚN
Cada aplicación consume los datos a su manera.
Poco código es realmente compartido.
Se tienen servicios y dominios en el plugin y en cada
uno de los proyectos.

29. NO COMPARTIR BASE DE DATOSNO COMPARTIR BASE DE DATOS
Si no se comparten bases de datos, evitaremos muchos
de los problemas.
A cambio añadimos el problema de la sincronización y
duplicidad de los datos.

30. NO USAR LAS MISMAS TABLASNO USAR LAS MISMAS TABLAS
Crea vistas [materializadas] para generar los dominios
especí cos para cada proyecto.
Solo un proyecto escribe en una tabla determinada, el
otro la consulta a partir de vistas.

31. COMPARTIR LO MÍNIMO POSIBLE DE CADA TABLACOMPARTIR LO MÍNIMO POSIBLE DE CADA TABLA
Dominios con solo lo imprescindible.
Mínima cantidad de campos no nullables (en base de
datos).
No renombrar tablas o campos de la base de datos, solo
el dominio.

32. EXTERNALIZA LA GESTIÓN DE LA BASE DE DATOS A OTROEXTERNALIZA LA GESTIÓN DE LA BASE DE DATOS A OTRO
PROCESOPROCESO
Ningún proyecto gestiona la base de datos, sino
que es un agente externo.
Se puede plani car mejor el cambio en los
esquemas para no romper.

33. CACHÉS DISTRIBUIDASCACHÉS DISTRIBUIDAS
Una caché distribuída puede solucionar alguno de los
problemas con las cachés.

34. MICROSERVICIOSMICROSERVICIOS
Cada microservicio gestiona sus cachés, bases de
datos, etc.
Úsese con moderación y siempre bajo la supervisión de
un adulto.

35. EVENT SOURCING / CQRSEVENT SOURCING / CQRS
¡Y se acabó el compartir nada!
A cambio de mayor complejidad en el código.
Úsese con moderación y siempre bajo la supervisión de
al menos 2 adultos.

36. CONCLUSIONESCONCLUSIONES
Si de un proyecto hay más de una instancia
levantada, hay los mismos problemas.
Los mayores problemas son debidos a compartir
base de datos entre diferentes proyectos o nodos.
Compartir solo lo realmente común.
Trade-offs everywhere.

37. ¿PREGUNTAS O COMENTARIOS?¿PREGUNTAS O COMENTARIOS?