codemotion 2013 - quiero tiempo real y lo quiero para ayer

¡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

- Twitter

- 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

lopez.ivan@gmail.comlopez.ivan@gmail.com

Feedback de la charla:Feedback de la charla:http://goo.gl/e4AjKYhttp://goo.gl/e4AjKY

¡ GRACIAS !