Codemotion 2013 - Quiero tiempo real y lo quiero para ayer

5,122 views
5,166 views

Published on

Slides de mi charla de Codemotion "http://codemotion.es/talk/19-october/88". El código fuente de las demos está disponible es https://github.com/lmivan/codemotion-2013.

El vídeo de repetción de la charla en @madridgug está disponible en: http://www.youtube.com/watch?v=dkDub1QLqmM

En un mundo hiper-conectado el concepto Tiempo Real es cada vez más utilizado y las arquitecturas "message driven" son la manera de conseguirlo porque permiten crear aplicaciones modulares y escalables.

En esta charla veremos un tipo de arquitectura totalmente distinta a la estandar de Grails para aplicaciones web que nos permitirá servir contenido en tiempo real a muchos clientes de manera rápida y sencilla teniendo distintos módulos independientes que interactuarán entre sí.

Published in: Technology

Codemotion 2013 - Quiero tiempo real y lo quiero para ayer

  1. 1. Iván López Martín @ilopmar ¡Quiero Tiempo Real y lo quiero para ayer!
  2. 2. ¿Quién soy? Iván Lopez Martín @ilopmar Trabajo en Kaleidos Uso Groovy/Grails desde hace casi 4 años Creador de www.bokzuy.com Creador de varios plugins de Grails Sospechoso habitual de Madrid-GUG (Groovy User Group) Geek, padre, desarrollador, sysadmin, linuxero y pro-software libre
  3. 3. Arquitecturas tradicionales Request-response POST /register-user POST /register-user POST /register-user
  4. 4. Arquitecturas tradicionales
  5. 5. Arquitecturas tradicionales
  6. 6. A problem postponed is a problem solved really?
  7. 7. Arquitecturas orientadas a eventos - Event Driven Architecture (EAD) - Fire & Forget - Desacoplan al productor del consumidor - Acción inmediata en los consumidores - Tiempo real / Notificaciones push
  8. 8. Arquitectura tradicional Ejemplo arquitectura tradicional (request-response) POST /purchase - Recibir petición 5 ms - Validación de datos 20 ms - Guardar 40 ms - Generar PDF 200 ms - Enviar email 80 ms - Renderizar respuesta 50 ms POST /purchase Total 395 ms
  9. 9. Can we do it better?
  10. 10. Arquitecturas orientadas a eventos Ejemplo EDA POST /purchase - Recibir petición 5 ms - Validación de datos 20 ms - Guardar 40 ms - Generar PDF 200 ms - Enviar email 80 ms - Renderizar respuesta 50 ms No No No Sí Sí No ¿Puede hacerlo alguien más? POST /purchase Total 115 ms ~ 70% mejora
  11. 11. Arquitecturas orientadas a eventos POST /purchase - Recibir petición 5 ms - Recibir petición 5 ms - Validación de datos 20 ms - Validación de datos 20 ms - Guardar 40 ms - Guardar 40 ms - Renderizar respuesta 50 ms - Renderizar respuesta 50 ms Total: 115 ms POST /purchase Generar PDF Enviar email
  12. 12. Don't keep your clients waiting! Can I defer it?
  13. 13. Objetivos - Arquitectura menos acoplada, más fácil de extender, evolucionar y mantener - Construir sistemas de alto rendimiento y altamente escalables - Mantener la lógica dónde debe estar y no repartida por toda la aplicación - Idealmente los cambios los pueden realizar equipos distintos
  14. 14. ¿Y en Grails? Todo esto está muy bien pero yo he venido a hablar de “mi libro”: Grails - Platform Core - Events push - Plugin Executor - Grails 2.3 Async
  15. 15. Ejemplo síncrono // Envío de email de confirmación al registrar un usuario def user = new User(params).save() emailService.sendRegistationMail(user) render view:'registerOk' class EmailService { public void sendRegistrationMail(User user) { sendMail { to user.email subject “Confirm your account” html g.render(template: “userEmailConfirmation”) } } }
  16. 16. Ejemplo asíncrono // Platform core def user = new User(params).save() event('sendRegistrationMail', user) render view:'registerOk' class EmailService { @grails.events.Listener public void sendRegistrationMail(User user) { sendMail { to user.email subject “Confirm your account” html g.render(template: “userEmailConfirmation”) } } }
  17. 17. Ejemplo asíncrono // Executor def user = new User(params).save() runAsync { emailService.sendRegistationMail(user) } render view:'registerOk'
  18. 18. I love the smell of code in the morning
  19. 19. Problemas - Código muy acoplado a la solución utilizada - Difícil de testear
  20. 20. ¿Y si no queremos que sea así? - Podemos extraer esas dependencias a “configuración” - Es posible cambiar el comportamiento de la aplicación cambiando sólo la configuración
  21. 21. Spring Integration Permite utilizar dentro de Spring los conocidos Enterprise Integration Patterns http://www.enterpriseintegrationpatterns.com/
  22. 22. Spring Integration - Mecanisnos ligeros de mensajería en aplicaciones Spring - Integración de sistemas externos declarando adaptadores. - Abstracción de alto nivel de aplicaciones de mensajería. - El código de la aplicación no es consciente del API de la mensajería. - Proporciona un modelo simple para construir aplicaciones EIP manteniendo separación conceptos y permitiendo crear código mantenible y fácilmente testeable.
  23. 23. Principales Características “Pipe and filters”
  24. 24. Message - Datos (payload) pueden ser cualquier objeto - Cabecera (header) información adicional almacenada en un Map - Son inmutables
  25. 25. Channel - Point-to-Point - Publish-Subscribe
  26. 26. Endpoints - Transformer - Service activator - Filter - Channel adapter - Router - Enricher - Splitter - Bridge - Aggregator ...
  27. 27. Adapters - JMS - Mail (POP3/IMAP/SMTP) - AMQP - JDBC - TCP - XMPP - UDP - Twitter - File - RSS - FTP - MongoDB - SFTP - Redis - RMI - GemFire - HTTP (REST) - Stream - WS
  28. 28. Talk is cheap. Show me the code.
  29. 29. DEMO Por favor sacrificad una virgen cabra para que los dioses de las demos repartan suerte
  30. 30. FUTURO/ALTERNATIVAS - Reactor Framework: Proporciona abstracciones para Java, Groovy y el resto de lenguajes de la JVM para construir aplicaciones eventdriven. En hardware normal consiguen 15.000.000 de eventos por segundo. Soporte de Java 8. - Spring 4: Soporte de Groovy como “first class citizen”, Reactor Framework, no más XMLs, Websockets nativos, SockJS,... - Grails 2.4: Release previa a la 3.0 con soporte de Spring 4.
  31. 31. CONCLUSIONES - La arquitectura estandar de Grails sirve para muchos casos - No escala infinito - Hay que plantearse desde el principio qué tipo de aplicación estamos construyendo - Puede que no estemos construyendo el próximo Instagram ¿o tal vez sí? - Es necesario pensar en flujos de la información - Costes de infraestructura vs Costes de código (más hierro vs deuda técnica)
  32. 32. ¡ GRACIAS ! Iván López Martín @ilopmar http://lopezivan.blogspot.com lopez.ivan@gmail.com https://github.com/lmivan Feedback de la charla: http://goo.gl/e4AjKY

×