Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Madrid GUG - 12/2019

77 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

Madrid GUG - 12/2019

  1. 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. 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. 3. TYMIT IS HIRING!TYMIT IS HIRING! Backend Android/Kotlin iOS/Swift https://tymit.workable.com
  4. 4. ¡ESTOY (CASI) DISPONIBLE PARA OTRO PROYECTO!¡ESTOY (CASI) DISPONIBLE PARA OTRO PROYECTO! jesus@kiakora.com
  5. 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. 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. 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. 8. PROBLEMASPROBLEMAS
  9. 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. 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. 11. EJEMPLO: DOMINIOS USUARIOEJEMPLO: DOMINIOS USUARIO Cada aplicación tiene su dominio Usuario para el login. Los servicios utilizarán ambos objetos.
  12. 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. 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. 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. 15. ACTUALIZACIONES DE VERSIONES DE GRAILSACTUALIZACIONES DE VERSIONES DE GRAILS A veces tienes que actualizar todos o ninguno por incompatibilidades entre versiones.
  16. 16. CACHÉSCACHÉS Se di culta mucho el trabajar con cachés. Hibernate (desactivar caché de segundo nivel) @Cacheable
  17. 17. DATABASE (MIGRATION PLUGIN)DATABASE (MIGRATION PLUGIN)
  18. 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. 19. VERSIONADO DE LAS TABLASVERSIONADO DE LAS TABLAS grails.gorm.default.mapping = {1 version false2 }3
  20. 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. 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. 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. 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. 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. 25. (POSIBLES) SOLUCIONES(POSIBLES) SOLUCIONES Algunas compatibles entre sí, otras soluciones alternativas.
  26. 26. DISCLAIMERDISCLAIMER No todas las soluciones las he probado.
  27. 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. 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. 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. 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. 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. 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. 33. CACHÉS DISTRIBUIDASCACHÉS DISTRIBUIDAS Una caché distribuída puede solucionar alguno de los problemas con las cachés.
  34. 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. 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. 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. 37. ¿PREGUNTAS O COMENTARIOS?¿PREGUNTAS O COMENTARIOS?

×