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.

Codemotion 2013 - Quiero tiempo real y lo quiero para ayer

6,420 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

×