¿Cómo obtener un desarrollo web a bajo costo y con alto rendimiento?
En el día de hoy los desarrollos web se vuelven cada vez mas comunes, desde aplicaciones basadas en tecnologías web hasta sitios tipo tarjeta que sirven para presentar una marca o un individuo, en este articulo vamos a intentar demostrar que con lo existente, se puede lograr un mayor rendimiento y una importante optimización de recursos al momento de dirigir este tipo de desarrollos.
Lenguajes comunes de Back-End
En casi todos los casos anteriormente mencionados vemos un actor importante, el Back-End, PHP, RUBY, PERL, PYTHON muchas veces conectados con APACHE, NGINX o diferentes servidores HTTP/HTTPS y son los protagonistas de esta historia que tiene como fin llegar al usuario en la mejor y mas rápida forma.
La intervención con el Front-End
Frameworks son los encargados de ayudarnos a que no caigamos en reinventar la rueda, pero en este caso puntual, quizás lo que necesitamos no es una rueda, mas bien necesitamos un motor, alguien que procese y devuelva una respuesta, una centralización de información, alguien recuerda el viejo modelo cliente-servidor ?, los puntos fuertes y débiles del mismo ?.
Hoy los Framework, por tomar uno Zend (PHP), intervienen directamente con el HTML.
Un caso común seria un listado de artículos que tiene a estos vinculados, tenemos un PHP que se encarga de listar y uno que se encarga de mostrar el articulo seleccionado.
¿Qué pasa realmente?
A partir de ahora vamos a denominar cliente al navegador (Safari, Firefox, Chromium, Kopete, Opera...) y servidor al Back-End (APACHE y PHP, PYTHON, PERL, RUBY,etc.)
El usuario entra en el sitio (listado de artículos)
• El cliente pide el sitio al servidor (10k)
• El cliente procesa el HTML y encuentra 5 imágenes adentro
• El cliente pide las 5 imágenes (todas 500k)
• El cliente carga todo
• El cliente pide el sitio al servidor (10k)
• El cliente procesa el HTML y encuentra 5 imágenes adentro
• El cliente pide las 5 imágenes (todas 500k)
• El cliente carga todo
El usuario hace un click en un articulo
• El cliente pide el articulo al servidor (tamaño 30k)
• El cliente procesa el HTML y encuentra 2 imágenes adentro
• El cliente pide las 2 imágenes (todas 200k)
• El cliente carga todo
• El cliente pide el articulo al servidor (tamaño 30k)
• El cliente procesa el HTML y encuentra 2 imágenes adentro
• El cliente pide las 2 imágenes (todas 200k)
• El cliente carga todo
El usuario hace un click en "volver" (vamos a leer otro articulo!)
• El cliente pide el sitio al servidor (10k)
• El cliente procesa el HTML y encuentra 5 imágenes adentro
• El cliente pide las 5 imágenes (todas 500k)
• El cliente carga todo
• El cliente pide el sitio al servidor (10k)
• El cliente procesa el HTML y encuentra 5 imágenes adentro
• El cliente pide las 5 imágenes (todas 500k)
• El cliente carga todo
Ahora bien, si esto fuese un problema de automatización, entendemos que hay pasos que estamos repitiendo, esperando lo mismo, ¿quizás contenido estático?, si es así, ¿ porque tenemos que pedírselo al servidor?.
Actualmente este es un problema solucionado a medias con la respuesta 304 de servidor y el uso de la cache del cliente, pero aun así nos trae problemas al momento de actualizar el sistema, por lo que muchos desarrolladores optan por evitar el uso de cache..."no señor, para que se vea tiene que apretar F5" .
Todos bajo el mismo sol
Usando la explicación de wikipedia acerca del protocolo HTTP, podemos ver lo siguiente...
"Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web o un spider) se lo conoce como "user agent" (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento" wikipedia 02/06/2013
Costos
Tomando como base el ejemplo anterior podemos decir que
• La lógica del sistema la tiene el servidor
• El cliente llama al servidor por cada pantalla que necesita
• La respuesta visual del sistema se basa en la velocidad de conexión
• El trafico consumido es equivalente a las pantallas que ve el usuario (todo el HTML al menos)
• Se requiere un minucioso análisis de la sintaxis del formato HTML para evitar problemas de w3c
• La lógica del sistema la tiene el servidor
• El cliente llama al servidor por cada pantalla que necesita
• La respuesta visual del sistema se basa en la velocidad de conexión
• El trafico consumido es equivalente a las pantallas que ve el usuario (todo el HTML al menos)
• Se requiere un minucioso análisis de la sintaxis del formato HTML para evitar problemas de w3c
Este tipo de implementaciones ubican al hardware y la conectividad como la estrella que mas brilla en el firmamento, y aun así cuando se piensa en velocidad y alto rendimiento, se apunta a bajar la tasa de transferencia mediante el uso de cache, pero ¿y el desarrollo?
Desarrollo de Front y Back separados
Como objetivo de este articulo presentamos un modelo (dentro de lo existente) diferente, que demuestra por si mismo que puede ser mucho mas óptimo y rápido si hablamos de desarrollos basados en web. Nuestra idea de mejora parte desde el comienzo del desarrollo, veamos el mismo ejemplo anterior desarrollado.
Tendríamos 2 archivos PHP
• listar-articulos.PHP : Mostraría en pantalla un HTML con un listado de los artículos existentes y con un link en cada uno a ver-articulo.PHP enviándole un id de articulo
• ver-articulo.PHP: Mostraría en pantalla un HTML con el articulo con el que fue llamado (ver-articulo.PHP?id=2)
• ver-articulo.PHP: Mostraría en pantalla un HTML con el articulo con el que fue llamado (ver-articulo.PHP?id=2)
Si bien esta opción seria extremadamente rápida de llevar a cabo con diferentes Framework's (en zend usaríamos actions y controllers), sigue estando el problema de dibujar el HTML en el Back-End (PHP), por lo cual en mayor o menor cantidad de lineas, volveríamos a caer en el desarrollo anterior.
Nuestro planteo es radicalmente diferente, basar la lógica de pantallas en Javascript y darle vida al navegador usándolo para correr la aplicación "cliente"
• sistema.HTML : Se encargaría de mostrar un HTML básico con un body vacío y una llamada de head a sistema.js
• sistema.js : Se encargaría de dibujar la pantalla de listado de artículos, llamando una sola vez a traerArticulos y también de dibujar la pantalla de ver articulo, llamando cuando sea necesario a traerArticulo.
• traerArticulos.PHP : Se encargaría de devolver el listado de artículos en formato json
• traerArticulo.PHP : Se encargaría de devolver el articulo en formato json
• sistema.HTML : Se encargaría de mostrar un HTML básico con un body vacío y una llamada de head a sistema.js
• sistema.js : Se encargaría de dibujar la pantalla de listado de artículos, llamando una sola vez a traerArticulos y también de dibujar la pantalla de ver articulo, llamando cuando sea necesario a traerArticulo.
• traerArticulos.PHP : Se encargaría de devolver el listado de artículos en formato json
• traerArticulo.PHP : Se encargaría de devolver el articulo en formato json
De esta forma, el HTML nunca se escribiría desde PHP, sino desde Javascript mediante el uso de DOM con sistema.js, que trabaja localmente en el navegador y se encarga de dibujar la pantalla de articulo y artículos, vincularlos y guardar una versión local de la información recibida, esto, se puede optimizar mas todavía ya que el único momento donde molestamos al servidor es para traer listados de información con un formato muy básico pero toda la pantalla no es recargada salvo que sea estrictamente necesario.
El modelo anterior ahora quedaría reflejado de la siguiente forma:
El usuario entra en el sitio (listado de artículos) • El cliente pide el sitio al servidor (1k)
• El cliente procesa el HTML y encuentra 1 archivo js
• El cliente pide el archivo js (10k)
• El cliente ejecuta el archivo js
• El cliente pide al servidor las 5 imágenes (todas 500k)
• El cliente pide al servidor los artículos (2k)
• El cliente dibuja la pantalla de listado de artículos
• El cliente procesa el HTML y encuentra 1 archivo js
• El cliente pide el archivo js (10k)
• El cliente ejecuta el archivo js
• El cliente pide al servidor las 5 imágenes (todas 500k)
• El cliente pide al servidor los artículos (2k)
• El cliente dibuja la pantalla de listado de artículos
El usuario hace un click en un articulo • El cliente pide al servidor el articulo (-1k)
• El cliente muestra la pantalla de articulo
• El cliente pide las 2 imágenes (todas 200k)
• El cliente muestra la pantalla de articulo
• El cliente pide las 2 imágenes (todas 200k)
El usuario hace un click en "volver" (vamos a leer otro articulo!) • El cliente vuelve a cargar la pantalla de listado
• opcionalmente se podría pedir otra vez el listado de
• artículos (2k) y se actualizaría el listado
• opcionalmente se podría pedir otra vez el listado de
• artículos (2k) y se actualizaría el listado
Básicamente tendríamos un desarrollo de cliente-servidor pero implementado con Javascript y conectado con xmlHTTPrequest, esto a su vez nos asegura que la pantalla siempre va a ser la misma sin perder tiempo en recargarla o esperar a que responda el servidor, la aplicación se descarga cuando se descarga el Javascript y de esta forma nos evitamos el rezo cada vez que apretamos un botón, queda todo en el albedrío del programador, que ponga preloaders por cada acción que involucre al servidor, que en este caso seria para pedir el listado de artículos o al articulo en si mismo, pero al venir una respuesta sin formatos embebidos y con formatos sencillos, nos aseguramos que la transferencia esta completamente reducida a lo necesario, en este caso ahorrando de forma directamente proporcional al tiempo de uso que le de el usuario al sistema/sitio.
Framework para Front
En un escenario ideal, tendríamos recursos ilimitados y tiempos ilimitados para presentar un aplicativo funcionando, pero en la vida real, todos sabemos que no es así, un punto muy a favor de los Framework's de Back-End es que en unos clicks y/o pocas líneas se consiguen los mismos resultados, por eso de planificar un proyecto ambicioso como lo es una web de alto rendimiento, es recomendable el uso reciclable de cada línea, creando así un Framework en el primer desarrollo y organizarlo para que el próximo desarrollo sea a unos clicks, o unas pocas líneas.
La nueva/vieja filosofía (cliente-servidor)
Los desarrolladores de navegadores (Mozilla, Google, Microsoft, etc...) apuntan cada día a dar mas vida a los navegadores, agregando funcionalidades y apoyando en algunos casos en los estándares mundiales como w3c, muchas de estas funcionalidades están orientadas al uso de Javascript en el Front-End (nuestra aplicación cliente!). No es novedoso el uso de Javascript pero si, plantear una metodología nueva orientada a un campo que no esta muy explotado como lo es una web de alto rendimiento o el planteo de un sistema orientado a dataentry's.
Javascript vs Backend (cuadro comparativo)
| BACKEND | JS | |
| Volumen de Transferencia | Mediano/Alto | Bajo |
| Tiempo de Desarrollo | Bajo con uso de Frameworks | Depende de la capacitación |
| Velocidad de respuesta en pantalla | Bajo, depende de la conexión | Alto, se procesa en el cliente |
| Validación de formularios | Requiere sobre-desarrollo | Nativo |
| Animaciones | Requiere sobre-desarrollo | Nativo, Hay Frameworks |
| Preloaders | Requiere sobre-desarrollo y Análisis del caso | Nativo |
| HTML w3c compilant | Requiere la verificación en cada paso | El HTML lo escribe Javascript |
Organización del desarrollo
Uno de los principales desafíos de un proyecto informático, independientemente de su complejidad, es elaborar una estructura integrada y simbiótica de recursos profesionales, arquitectura y metodologías que permitan maximizar los niveles de productividad y calidad del producto. Cuando uno o todos los componente de la formula fallan, inexorablemente quedamos a merced de alguna de las tres restricciones que tiene todo proyecto (COSTOS, TIEMPO y ALCANCE), perdiendo la credibilidad del Sponsor y Stackeholders del proyecto.
Aplicación de Metodologías
Para generar un marco de trabajo adecuado, tanto para la gestión de proyecto como para garantizar la calidad del proceso, existen una serie de metodologías y modelos en el mercado que se pueden implementar, con probados resultados. En tal sentido, el éxito indiscutido de metodologías ágiles aplicadas en proyectos de desarrollo de software, vienen consolidándose como el camino más exitoso. La implementación de las metodologías ágiles más populares del mercado (SCRUM, Lean, XP), complementadas con CMMi, constituyen un marco de trabajo adecuado y se adaptan perfectamente en la construcción de modelos y aplicaciones WEB de alto rendimiento.
Con la llegada de estas metodologías sobrevinieron los métodos de estimación ágiles, el legendario y eficiente Juicio de Expertos y su versión modernizada, denominada Póker Planning. En un modelo basado en transacciones asincrónicas, la estimación de tiempo se puede obtener rápidamente del esfuerzo que requiere la construcción de cada una de ellas. Si a cada transacción analizada/modelada en épocas tempranas le aplicamos, de acuerdo al Juicio de Experto, un factor en horas estimado acorde a su complejidad, obtendremos el tiempo para construir cada una de las funcionalidades definidas. De esta manera el SCRUM Master o Tracker podrá armar los Sprints o iteraciones identificando cada User Story, el que podrá agrupar una o varias transacciones de acuerdo a su complejidad.
Respecto del modelado, la utilización de la metodología UML permite un fácil entendimiento entre los distintos actores del proyecto. El modelado de los diagramas Requerimientos, Reglas, Casos de Usos, utilizando normas de nomenclatura y templates permite acelerar los tiempos de modelado y el entendimiento entre los usuarios y el equipo de desarrollo. En un modelo WEB basado en transacciones, de acuerdo a la madurez del equipo y de nuestra arquitectura, podríamos llegar a reemplazar los Diagramas de Casos de Uso por Diagramas de Secuencia, de manera de acelerar los tiempos simplificando el modelado.
Esquema de Arquitectura
La metodología y la arquitectura marcan el paso en todo proyecto de desarrollo de software. La aplicación de ciertas normas de diseño y del concepto de ingeniería de software nos permitirá avanzar en varias líneas de acción paralelas. A continuación se desarrollan algunos de los tips que nos pueden ayudar a acelerar los tiempos de desarrollo y obtener un producto de calidad compatible con los estándares del W3C:
• Diseñar templates HTML despojados totalmente de código, compatibles totalmente con el modo estricto de la W3C y con formato de codificación UTF-8 o 16.
• Trabajar con Hojas de estilo (CSS) y aprovechar el enorme potencial que brinda la posibilidad de armar árboles jerárquicos.
• Todo objeto que se muestre por pantalla debe ser creado de acuerdo a las pautas del modelo DOM y siempre generado en el Fron-End.
• Diseñar objetos y componentes tipo “caja negras” que sean configurables y customizables de acuerdo a la necesidad de negocio.
• Construir aplicaciones y componentes que contemplen los criterios de internacionalización y localización.
• Delegar las reglas de negocio al Back-End y las políticas de comportamiento y usabilidad a la aplicación Fron-End.
• Diseñar las interfaces de usuario agrupando los objetos en secciones DIV utilizando posiciones relativas, de manera que la aplicación pueda renderizarse independientemente desde el dispositivo que se accede (PC, Smartphones o Tablets).
• Para intercambio de mensajes utilizar objetos JSON, ya que son un 75% más liviano que un archivo XML.
• Diagramar, en el Back-End, un modelo de componentes donde cada una responda a un concepto de negocio.
• Los SQL de persistencia y consulta deben ser simples, utilizando siempre las sentencias más performantes y el plan de ejecución más óptimo. Los diseños de la base de datos deben respetar los criterios relacionales y se deberá utilizar redundancia controlada únicamente en aquellos casos en que se requiera una alta perfomance de las consultas.
• Validar la integridad y composición de cada mensaje entre el Fron-End y Back-End.
• Trabajar con Hojas de estilo (CSS) y aprovechar el enorme potencial que brinda la posibilidad de armar árboles jerárquicos.
• Todo objeto que se muestre por pantalla debe ser creado de acuerdo a las pautas del modelo DOM y siempre generado en el Fron-End.
• Diseñar objetos y componentes tipo “caja negras” que sean configurables y customizables de acuerdo a la necesidad de negocio.
• Construir aplicaciones y componentes que contemplen los criterios de internacionalización y localización.
• Delegar las reglas de negocio al Back-End y las políticas de comportamiento y usabilidad a la aplicación Fron-End.
• Diseñar las interfaces de usuario agrupando los objetos en secciones DIV utilizando posiciones relativas, de manera que la aplicación pueda renderizarse independientemente desde el dispositivo que se accede (PC, Smartphones o Tablets).
• Para intercambio de mensajes utilizar objetos JSON, ya que son un 75% más liviano que un archivo XML.
• Diagramar, en el Back-End, un modelo de componentes donde cada una responda a un concepto de negocio.
• Los SQL de persistencia y consulta deben ser simples, utilizando siempre las sentencias más performantes y el plan de ejecución más óptimo. Los diseños de la base de datos deben respetar los criterios relacionales y se deberá utilizar redundancia controlada únicamente en aquellos casos en que se requiera una alta perfomance de las consultas.
• Validar la integridad y composición de cada mensaje entre el Fron-End y Back-End.
Coordinación de Recursos Humanos
De acuerdo a la complejidad del proyecto y al presupuesto del que se dispone, se deberá componer el equipo para el desarrollo del proyecto. En proyectos chicos o medianos (menores a 1 año de desarrollo) un SCRUM Master o Tracker con algo de experiencia puede administrar el proyecto sin inconvenientes. Pero en proyectos de magnitud donde hay especialistas por cada área y varios equipos de trabajos trabajando en forma paralela, se deben coordinar los recursos para evitar colisiones entre los equipos y minimizar los posibles efectos no deseados, refactoring, revisiones de modelos y modificaciones constantes de componentes ya diseñadas.
En proyectos donde interactúan perfiles específicos, como Especialistas en usabilidad, Diseñadores gráficos, Desarrolladores Fron-End, Desarrolladores Back-End, Especialistas de QA, contar con un esquema metodológico de trabajo y una arquitectura adecuada no sólo facilita la coordinación de las tareas sino que además reduce considerablemente los “tiempos muertos” por dependencias entre tareas. Algunas de las mejores prácticas de ingeniería de software nos pueden ayudar en minimizar las interacciones entre los distintos perfiles:
• Una estructura jerárquica de hojas de estilo, acompañado de templates de pantalla, permite desacoplar las tareas y tiempos entre los diseñadores gráficos y los desarrolladores.
• La construcción de objetos y componentes de interfaz de usuario con comportamientos específicos dentro del sistema, minimiza la tarea de los especialistas de usabilidad y QA, asegurando que todo tenga un comportamiento uniforme.
• Un diseño de Back-End basado en componentes permite desarrollar en forma paralela, atomizar el comportamiento, delimitar responsabilidades, y facilitar posterior mantenimiento.
• La construcción de objetos y componentes de interfaz de usuario con comportamientos específicos dentro del sistema, minimiza la tarea de los especialistas de usabilidad y QA, asegurando que todo tenga un comportamiento uniforme.
• Un diseño de Back-End basado en componentes permite desarrollar en forma paralela, atomizar el comportamiento, delimitar responsabilidades, y facilitar posterior mantenimiento.
Si a los conceptos expuestos le sumamos, los puntos de control y seguimiento que plantean las metodologías ágiles (Weekly meeting, Daily meeting, Restrospective) y una buena coordinación de proyecto, podemos construir modelos WEB de alta velocidad, con niveles de calidad de excelencia en tiempos relativamente cortos.
- Juan Sebastian Romero, Computer Security Researcher, http://www.linkedin.com/in/
No hay comentarios.