• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Quiero tiempo real y lo quiero para ayer
 

Quiero tiempo real y lo quiero para ayer

on

  • 2,833 views

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. ...

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í.

Statistics

Views

Total Views
2,833
Views on SlideShare
1,230
Embed Views
1,603

Actions

Likes
8
Downloads
25
Comments
0

35 Embeds 1,603

http://lopezivan.blogspot.com.es 856
http://lopezivan.blogspot.com 204
http://librosweb.es 181
http://lopezivan.blogspot.com.ar 67
http://lopezivan.blogspot.mx 57
https://twitter.com 50
http://lopezivan.blogspot.ru 47
http://cloud.feedly.com 29
http://lopezivan.blogspot.de 21
http://lopezivan.blogspot.fr 19
http://lopezivan.blogspot.com.br 16
http://lopezivan.blogspot.in 9
http://lopezivan.blogspot.be 7
http://lopezivan.blogspot.ch 5
http://lopezivan.blogspot.it 4
http://lopezivan.blogspot.co.uk 3
http://lopezivan.blogspot.pt 3
http://lopezivan.blogspot.ca 2
http://lopezivan.blogspot.co.at 2
http://lopezivan.blogspot.se 2
http://lopezivan.blogspot.dk 2
http://translate.googleusercontent.com 2
http://www.rss.rodavi.org 2
https://www.google.es 2
http://lopezivan.blogspot.com.au 1
http://www.lopezivan.blogspot.com 1
http://lopezivan.blogspot.jp 1
http://feeds.feedburner.com 1
https://www.google.com.mx 1
http://lopezivan.blogspot.nl 1
http://lopezivan.blogspot.cz 1
http://lopezivan.blogspot.gr 1
http://digg.com 1
http://feedly.com 1
http://lopezivan.blogspot.co.il 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Quiero tiempo real y lo quiero para ayer Quiero tiempo real y lo quiero para ayer Presentation Transcript

    • Iván López Martín @ilopmar ¡Quiero Tiempo Real y lo quiero para ayer!
    • ¿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) 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
    • Can we do it better?
    • 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
    • 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
    • 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 yo he 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 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”) } } }
    • 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”) } } }
    • Ejemplo asíncrono // Executor def 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 de Spring 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 - Service activator - Filter - Channel adapter - Router - Enricher - Splitter - Bridge - Aggregator ...
    • Adapters - JMS - Mail (POP3/IMAP/SMTP) - AMQP - JDBC - TCP - XMPP - UDP - Twitter - File - RSS - FTP - MongoDB - SFTP - Redis - RMI - GemFire - HTTP (REST) - Stream - WS
    • 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 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.
    • 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)
    • ¡ 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