codemotion 2013 - quiero tiempo real y lo quiero para ayer
DESCRIPTION
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í.TRANSCRIPT
¡Quiero Tiempo Real y lo quiero para ayer!
Iván López Martín @ilopmar
¿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
Arquitecturas tradicionales
Request-response
POST /register-user
POST /register-user
POST /register-user
Arquitecturas tradicionales
Arquitecturas tradicionales
A problem postponed is a problem solved
really?
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
Arquitectura tradicional
Ejemplo arquitectura tradicional (request-response)
Total 395 ms
POST /purchase
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
Can we do it better?
POST /purchase - Recibir petición 5 ms No - Validación de datos 20 ms No - Guardar 40 ms No - Generar PDF 200 ms Sí - Enviar email 80 ms Sí - Renderizar respuesta 50 ms No
Arquitecturas orientadas a eventos
Ejemplo EDA
Total 115 ms ~ 70% mejora
POST /purchase
¿Puede hacerlo alguien más?
Arquitecturas orientadas a eventos
POST /purchase
POST /purchase - Recibir petición 5 ms - Validación de datos 20 ms - Guardar 40 ms - Renderizar respuesta 50 ms
Total: 115 ms Generar PDF
POST /purchase - Recibir petición 5 ms - Validación de datos 20 ms - Guardar 40 ms - Renderizar respuesta 50 ms
Total: 115 ms Enviar email
Don't keep your clients waiting!
Can I defer it?
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
¿Y en Grails?
Todo esto está muy bien pero yohe venido a hablar de “mi libro”: Grails
- Platform Core- Events push- Plugin Executor- Grails 2.3 Async
Ejemplo síncrono
// Envío de email de confirmación al registrar un usuariodef 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”) } }}
Ejemplo asíncrono
// Platform coredef 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”) } }}
Ejemplo asíncrono
// Executordef user = new User(params).save()runAsync { emailService.sendRegistationMail(user)}render view:'registerOk'
I love the smell of code in the morning
Problemas
- Código muy acoplado a la solución utilizada
- Difícil de testear
¿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
Spring Integration
Permite utilizar dentro deSpring los conocidos Enterprise Integration Patterns
http://www.enterpriseintegrationpatterns.com/
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.
Principales Características
“Pipe and filters”
Message
- Datos (payload) pueden ser cualquier objeto
- Cabecera (header) información adicional almacenada en un Map
- Son inmutables
Channel
- Point-to-Point
- Publish-Subscribe
Endpoints
- Transformer
- Filter
- Router
- Splitter
- Aggregator
- Service activator
- Channel adapter
- Enricher
- Bridge
...
Adapters
- JMS
- AMQP
- TCP
- UDP
- File
- FTP
- SFTP
- RMI
- HTTP (REST)
- WS
- Mail (POP3/IMAP/SMTP)
- JDBC
- XMPP
- RSS
- MongoDB
- Redis
- GemFire
- Stream
Talk is cheap. Show me the code.
DEMO
Por favor sacrificad una virgen cabra para que los dioses de las demos repartan suerte
FUTURO/ALTERNATIVAS
- Reactor Framework: Proporciona abstracciones para Java, Groovy y el resto de lenguajes de la JVM para construir aplicaciones event-driven. 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.
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)
http://lopezivan.blogspot.comhttp://lopezivan.blogspot.com
@ilopmar@ilopmar
https://github.com/lmivanhttps://github.com/lmivan
Iván López MartínIván López Martín
[email protected]@gmail.com
Feedback de la charla:Feedback de la charla:http://goo.gl/e4AjKYhttp://goo.gl/e4AjKY
¡ GRACIAS !