Ejemplo de arquitectura ligera

Una entrada corta sobre una arquitectura que estoy usando ahora mismo para una aplicación web de tamaño pequeño/mediano. La historia es que un grupo de "modders" estamos haciendo unas modificaciones a un juego multi-jugador online y una de las partes modificadas incluye recoger estadísticas de las partidas que se juegan: información del servidor y mapa que se jugó, qué equipo ganó, cuantas veces mataron y mató cada jugador, cuantos puntos... Y esta información la queremos publicar por web, que es la parte que me toca a mí (mi vena artística no da más que hacer cuatro palotes y mi C está demasiado oxidado como para meter mano al juego).

Así que aquí está lo que uso, por si a alguien le da alguna idea:

• Como framework-pegamento, uso uno "custom" que es simple y ligero, no necesito más, y por ahí no pienso recomendar nada: es mal negocio :).
• La interfaz la estoy haciendo principalmente con tablas y elementos de YUI, usando AJAX y JSON para paginar las tablas sin recargar toda la página.
• Para formatear el JSON y las páginas que hacen de contenedores de los elementos YUI, JSP me basta. Suelo usar otras tecnologías para esto, pero como otros miembros del equipo puede que me ayuden y JSP es lo más común y sencillo...
• Para hacer más "agradables" las URL y más intuitivas, fácil de recordar y de escribir, pero sin que me condicionen la implementación por debajo: Url Rewrite Filter.
• Para "decorar" las páginas y hacer que los estilos y menús sean comunes: SiteMesh.
• Para evitar machacar la BDD con consultas cuando los datos no han cambiado, se usa una cache implementada con OSCache.
• Para las tareas que comprobarán periódicamente cuando hay que marcar como caducados algunos elementos de la caché (al acabar una partida, por ejemplo, hay que "caducar" todas las estadísticas globales de los jugadores que participaron y la lista general de partidas jugadas) uso Quartz.
• Para consultar la BDD, como los datos que se muestran son principalmente recopilatorios, las consultas suelen implicar media docena de "joins" y la navegación por entidades mataría el rendimiento, uso MyBatis en lugar de JPA, que es lo que seguramente use para atacar la parte de autenticación, definición de equipos etc. que sigue otra estructura más orientada a objetos.
• Para no tener que escribir tropecientos getter y setter y dejar el código limpio, uso Lombok para que lo haga por mí sin siquiera tener que verlos en el código. Muy útil en este caso.
• La BDD es MySQL. No la escogí yo ni hice el esquema así que poco puedo decir excepto que funciona.
• Para crear, probar y depurar las consultas contra la BDD: Aqua Data Studio.
• Para no tener que reiniciar el contexto cada vez que hago un cambio en las clases Java: JRebel, aunque tiene algunos conflictos con Lombok. Por otro lado, el framework detecta los cambios en la configuración de MyBatis en ejecución y recarga los "Mapper", así que tengo que re-iniciar el contexto muy muy poco. Y para rizar el rizo, el tiempo de reinicio con este framework ligero y MyBatis no llega a los 4 segundos así que el famoso tiempo perdido esperando a que se (re)inicien las aplicaciones Java en este caso es irrisorio.
• Como IDE: Eclipse, aunque el proyecto se puede montar solito en base a Ant + Ivy e incluso ejecutarlo, ya que incluye contenedor de servlets embebido para pruebas. No tengo manías y casi cualquier IDE debería valer en este caso, pero uso el que me es más cómodo.
• Para depurar YUI: El Firefox con Firebug, como no, aunque a veces interfiere con otros plugin y últimamente me tiene algo mosqueado.
• Para comprobar que el JSON que envío es correcto cuando me da un problema y no se si es por la estructura de JSON o un fallo en JavaScript: JSONLint
• Como contenedor de servlets para pruebas: Jetty 6, Tomcat 5.5 y Resin 4, en sus formatos "embedido" respectivos y lanzados desde el Ant o a mano. El de producción, que tampoco escojo yo, será Tomcat 5.5, así que estoy cubierto.

De momento las pruebas iniciales son bastante satisfactorias y gracias al uso de paginación a través de AJAX y de cachés en el servidor, parece que aguantaremos la carga. Para este sistema en particular es más importante que la aplicación sea ligera y ágil, que usar grandes frameworks que nos den muchas cosas hechas que no vamos a usar o que nos permitan hacer virguerías que no haremos.

Cada aplicación tiene sus propias cosas e intentar aplicar siempre la misma receta es como intentar cocinar el pollo, el cordero y el cerdo de la misma forma. Algunas veces puede funcionar pero otras es un desastre incomestible. Así que como en las recetas de cocina, si alguien puede aprovechar partes y le sirven para sus circunstancias particulares, me alegro. Si no, pues mala suerte y a buscar sus propias soluciones :).

Bon Appétit & Happy coding!
EJ