Este documento describe la experiencia de crear la plataforma de comercio electrónico más grande de Latinoamérica utilizando Grails. Explica por qué se eligió Grails, incluyendo su productividad, comunidad y similitud con Ruby on Rails. Detalla el negocio, diseño inicial, infraestructura, problemas encontrados y futuro de la plataforma. La plataforma ha crecido a más de 2 millones de usuarios utilizando Grails, Terracotta, RabbitMQ y MySQL para lograr escalabilidad y disponibilidad.
1. De cero a 2M de usuarios
Grails, opción real para sitios web de alta carga y escalabilidad.
Una experiencia al crear la más grande
plataforma de eCommerce con Grails en Latinoamérica.
5. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
6. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
7. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
• Rails en 2004
8. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
• Rails en 2004
• Groovy. Gran lenguaje.
9. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
• Rails en 2004
• Groovy. Gran lenguaje.
• Productividad
10. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
• Rails en 2004
• Groovy. Gran lenguaje.
• Productividad
• Comunidad y ecosistema
11. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
• Rails en 2004
• Groovy. Gran lenguaje.
• Productividad
• Comunidad y ecosistema
• Grails 0.5-0.6 en 2007
12. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
• Rails en 2004
• Groovy. Gran lenguaje.
• Productividad
• Comunidad y ecosistema
• Grails 0.5-0.6 en 2007
• Primer aplicación productiva en 2008, Grails 0.6
13. ¿Porque Groovy/Grails?
• Aburrido de Java
• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
• JSF, Struts, Flex... <-- NO por favor
• Rails en 2004
• Groovy. Gran lenguaje.
• Productividad
• Comunidad y ecosistema
• Grails 0.5-0.6 en 2007
• Primer aplicación productiva en 2008, Grails 0.6
• Me gusto tanto que hice screencast en Groovy.org.es
14. Negocio
Una tienda en linea, con una amplia
y creciente gama de servicios y productos
15. Negocio
• Ventas en grupo
• Cupones.
• Viajes, electrodomésticos, etc
• Campañas de email masivas.
• Campañas de publicidad masivas.
17. Primera implementación
• En 8 semanas se construye en Berlin las bases de la
plataforma, con 4 desarrolladores
• Salimos a producción en Septiembre 2010 en México y
Argentina
• En Octubre 2010 salimos en producción en Emiratos Arabes
(Dubai)
• En noviembre el equipo de desarrollo crece en México
• El desarrollo continua para México con un equipo de 5
desarrolladores
19. GORM, lo bueno
• Facilidad de crear modelos
• Modelos ricos
• Consultas
• Criteria
• DynamicFinders
• Actualización del esquema de base de datos
20. GORM, lo malo
• No es posible probar DynamicFinder y Criteria de forma
unitaria
• Pruebas integrales, a veces toma mucho tiempo
• Es sencillo cometer errores debido a la facilidad
• Olvidar crear indices
• Iterar grandes colecciones
• Dejar que Grails nombre relaciones (tablas o campos)
21. Servicios, lo bueno
• Lógica de negocio
• Servicios que “escuchan” eventos-RabbitMQ
• Extensivo uso de Dependency Inyection
• Composición, agregación
• Reglas de negocio flexibles
22. Servicios, lo malo
• Abusar de Dependency Inyection
• Referencias circulares
• No es tema de Grails exclusivamente, con Spring se
presenta también.
• Duplicar nombres de Servicios, en diferentes paquetes
• Olvidar quitar la administración transaccional cuando
no es necesaria.
23. Controllers, lo bueno
• Ridículamente simple
• Generar JSON/XML es trivial
• Reglas de mapeo, muy sencillo y flexible
(URLMappings)
• Totalmente desacoplado de la vista
25. TagLibs, lo bueno
• Súper simple crearlas :)
• Apoyo de Dependency Injection para
acceder a servicios, o a cualquier
componente.
• Condicionar la generación de contenido
• Llenar plantillas (fragmentos de una página)
27. Grails, en general
• Permite que un desarrollador Java, explote su
conocimiento.
• Aumenta la productividad debido a el uso de
“Convención sobre Configuración”
• Incrementa brutalmente la facilidad de
convertir requerimientos de negocio en
código ejecutable
28. Grails
• En mi humilde opinión, la mejor opción para
desarrollo web en Java, de cualquier tamaño
o requerimiento
• Disclaimer: Es solo mi experiencia personal,
no puedo garantizar el mal uso de Grails.
También puedo equivocarme. Es mi punto de
vista como desarrollador.
29. Escalabilidad y
Disponibilidad
Vitales para estar en un negocio muy competitivo
32. Terracotta
• Cache distribuido
• Evitamos accesos a la BD
• Guardamos Objetos Java, HTML, JSON, XML
• Entidades de Hibernate
• Páginas completas
• Fragmentos de páginas
33. Terracotta
• Usamos EhCache como “fachada”
• En desarrollo no usamos Terracotta
• En producción y QA configurado
• El código aplicativo no se ve modificado
34. Terracotta
• IMHO, es una de las mejores piezas de software jamas
escritas en Java
• Robusto, Estable
• Confiable, Ligero
• Casi cero administración
• Configuración muy sencilla
• Uptime de meses en producción
35. Terracotta
• Lo usamos para clusterizar sesiones HTTP,
pero no quedo productivo
• No quería cargar con mas trabajo a Terracotta
• Evitar tener un solo punto de falla
• También lo usamos muy poco tiempo para
clusterizar Jobs con Quartz
36. RabbitMQ
• Servicio de mensajería
• Diferente a JMS, AMQP es un protocolo programable
• Escrito en Erlang
• Muy robusto, estable
• Casi cero administración
• Desarrollado por vmWare
37. RabbitMQ
• Procesamiento asíncrono
• Procesos muy tardados
• Envío de email
• Consultas pesadas (reportes financieros)
• Integración con otras aplicaciones
38. RabbitMQ, lo malo
• No hay muchas herramientas de
administración/monitoreo
• Las que hay son poco “amistosas”
• Cuando falla, falla muy duro
• Los logs de error son como Hebreo antiguo o
mas bien como lenguaje Orco.
39. RabbitMQ, lo malo
• No hay muchas herramientas de
administración/monitoreo
• Las que hay son poco “amistosas”
• Cuando falla, falla muy duro
• Los logs de error son como Hebreo antiguo o
mas bien como lenguaje Orco.
40. RabbitMQ, nada malo
• Antes he usado varios servicios de mensajería
• Todos ellos basados en Java
• RabbitMQ ha sido al que he visto que se le ha
puesto una carga muy grande, sin necesidad
de afinar la configuración.
• IMHO. La mejor opción.
41. RabbitMQ, nada malo
• Antes he usado varios servicios de mensajería
• Todos ellos basados en Java
• RabbitMQ ha sido al que he visto que se le ha
puesto una carga muy grande, sin necesidad
de afinar la configuración.
• IMHO. La mejor opción.
43. mySQL
• Tenemos instalada una versión “afinada” por
RackSpace
• Una palabra para describirla: Impresionante
• He vivido engañado por muchos años.
• Un pequeño comportandose como nunca he visto un
grande.
• Nuestro mySQL ha soportado +15 millones de queries
en un día
44. MongoDB
• Principalmente almacenamos documentos con la bitácora de
cambios en algunos objetos del modelo.
• Grails Audit Logging Plugin
• Guarda un registro por cada cambio. No nos convencía este
enfoque. La tabla de auditoria crecía demasiado (millones de
registros en unas semanas)
• Activando los handlers, los atributos alterados se serializan a
JSON y se almacenan de manera asíncrona en MongoDB
• Tenemos una aplicación con Grails 2.0 con el plugin de MongoDB
• MongoDB instalado en otra maquina diferente
45. Redis
• Excelente opción para usarlo como Cache
• Redis puede almacenar ‘Estructuras de datos’
• Provee soporte para operar sobre esas estructuras.
• incr, incrBy, set
• Lo usamos para guardar estadísticas.
• Compras por producto, etc.
• Redis se encarga de la concurrencia
49. Características
• Dual Quad Core Xeon 2.26 HGZ
• 24 GB de RAM
• 300 GB SAS X 3
• RedHat Enterprise Linux 5.6
• En Hospedaje dedicado en Rackspace
Chicago
50. Problemas
• Quartz Jobs clusterizados
• Ahora corren en una instancia propia
• Indices faltantes en la base de datos
• Consultas muy mal escritas
• Mala configuración del log
53. JavaMelody
• Analiza todas las peticiones a tu aplicación
• Nos ayudo a detectar
• Cuellos de botella
• Queries ineficientes
• Servicios mas usados
• OpenSource, Apache 2.0
• Activado en producción, penalización mínima, imperceptible.
• Plugin para Grails
62. Comunidad
• La comunidad Groovy/Grails es fantastica.
• Muchos plugins para Grails
• Grails es un campo fértil para crear nuevos plugins
• Es sencillo participar.
• Hemos contribuido a varios plugins
• Export
• SpringSecurity
• ReCaptcha
• SpringSocial
• Scala