¿Quieres hacer pan? utiliza AJAX

Esta parece ser la premisa en todo lugar donde hablan de desarrollo Web. Al igual que ha pasado muchas otras veces con otras tantas propuestas y tecnologías AJAX se ha vuelto la palabra de moda y su uso un símbolo de status. SIn embargo no siempre AJAX es la mejor opción en muchas ocasiones en realidad estas generando tráfico y carga adicional todo por usar lo que esta de moda.

Como toda tecnología y herramienta en general AJAX tiene un lugar y uso adecuado por ello cito algunos escenarios donde AJAX no creo que se conveniente:

• AJAX NO debe ser usado en sitios donde se redibuja toda la página. Piensen que si fuera un link seria solo una llamada en cambio con ajax tendrán la llamada, cambio de estilos y despliegue y el usuario no habrá ganado nada.
• AJAX NO debe usarse para traer imagenes, un uso común es cambiar las imagenes pero si traen la imagen con AJAX y luego le piden al navegador desplegarla están agregando pasos innecesarios.
• AJAX NO debe usarse para no tener que cambiar nunca de página. En este caso tus archivos JS se volveran enormes y todo el tiempo que podrías ahorrar entre llamadas lo utilizaras en descargar tus archivos. Los enlaces no son tus enemigos.
• AJAX NO debe complicar la navegación. Tipicamente cuando alguien encuentra algo interesante lo que hace es mandar el link a otros por lo tanto un link javascript:Ejecutar('2sdfasdfasdf') no servira de nada. Este enfatiza el anterior los enlaces no son tus enemigos
• AJAX NO debe asumir que todos los navegadores soportan Javascript habemos muchos que tenemos deshabilitadas varias opciones o incluso todo javascript así que siempre piensa en un método alterno.
• AJAX NO debe ser usados para correr procesos Batch. Por muy tentador que parezca esto no es una buena idea. ¿Porque? porque simplemente pierdes totalmente el control del proceso al enviarlo al servidor. Es posible mantener un control pero para eso necesitarías crear al menos 4 servicios ajax Inicio, Estado, Cancelacion, Resultado. Mientras que una página de servidor puede refrescarse y mantener al tanto al usuario con un mayor control de proceso en el servidor.

En fin todo esto solo es para decir un viejo y conocido dicho la mejor solución es la más simple y recuerda AJAX no siempre lo es.

PS quiero hacer un reconocimiento al equipo de MS Visual Interdev e Internet Explorer que hace 7 años plantearon el uso de RemoteScripting y DHTML, ideas que evolucionaron en XmlHttpRequest y que hoy son base de AJAX, si tan solo todos los hubieran escuchado entonces...

Semanas ocupadas...

Para los equipos de producto, los mismos nos han dado muchas novedades y esperé a que estuvieran todas acumuladas para comentarlas.

• .Net Fx3 RTM. Así es el lunes pasado se hizo oficial la comunicación y hoy WPF,WCF,WF y CardSpace estan disponibles para todos. Junto con el runtime también esta disponible el SDK de Windows Vista. Más info en http://www.netfx3.com
• PowerShell RTM, En el blog del equipo de producto hoy anunciaron que finalmente el nuevo shell de Windows esta listo. Para los administradores de redes y servidores y para los amantes de la linea de comando es obligatorio descargarlo. Más info http://support.microsoft.com/kb/926139 (por si acaso los enlaces de descarga son nuevos así que puede que tarden un poco en estar disponibles)
• Office 2007 RTM. También el lunes pasado el equipo de producto entrego el build que fue llevado a las fabricas. Lamentablemente este producto no se puede descargar, pero si esperan hasta el primero de diciembre ya se podrá descargar un trial. Por ahora habrá que conformarse con probarlo en línea. Más info http://office.microsoft.com
• Vista RTM. El WIndows con el nombre más raro también llegó al final de su etapa de pruebas y fue entregado a linea de ensamblaje. Al igual que con Office habrá que esperar antes de tener un instalador de Vista y la fecha estimada de disponibilidad "en tiendas" es fines de Enero del 2007, pero para las empresas con acuerdos con MS deberían tenerlo en Diciembre. Más info http://www.microsoft.com/windowsvista/ 

Bueno todo esto se traduce en... MUUUUUUUUUUUCHO por aprender y estudiar. Si bien he seguido a WCF y algo de WF tengo mucho que aprender en WPF; CardSpace. Vista API, Office Server, etc., etc. etc.

Pendientes

Al publicar el post incompleto de hoy (incompleto por que se suponía debía incluir un ejemplo) me dí cuenta que hace más de un més que estoy con la máquina de reemplazo. Definitivamente es un perjuicio pues en este mes han salido muchas ideas sobre las cuales escribir y que no he podido hacerlo por no tener donde probarlas. A continuación algunas de las ideas:

1. Completar el ejemplo del post de Http Handlers. Mi idea es construir un handler de WebDAV muy basico (no PROP solo listado, GET y PUT)
2. Análisis de estático de código en base de datos. Sip hay mil y un razones para hacerlo y estoy pensando en como automatizarlo (parece simple pero lo veremos)
3. Diseño físico de bases de datos en SQL 2005. El artículo que referencié hace unas dos semanas es muy bueno pero quiero incluir un par de comentarios que son importantes y que no se mencionan a detalle

Bueno, esas son las idea por ahora, además de las revisiones de los nuevos drops del service factory y del Web Client Factory.

Hay mucho que hacer espero que mi portátil vuelva pronto.

Http Handlers

Ha pasado mucho tiempo desde que escribí un post. Esto se debe principalmente a que como comente anteriormente mi portátil estuvo en reparaciones y la máquina de reemplazo no tenía los recursos para poder hacer las pruebas que debían acompañar al post. Sin embargo, este post estuvo en trabajo por mucho tiempo.

¿Qué es un HTTP handler?

Veamos para entenderlo creo que es mejor mostrar un diagrama del flujo que sigue un requerimiento que llega a un servidor IIS ejecutando ASP.Net

Antes de seguir debo aclarar que este diagrama es reducido al proceso en ASP.Net y no considera el proceso propio de IIS.

Ahora si, en materia, como se ve en el diagrama ASP.Net procesa todos los requerimientos a través de un Http Handler que es configurado por path y requerimiento Http (GET; POST; PUT; etc).

El Http Handler recibe el requerimiento en bruto y es el encargo de procesarlo para enviar una respuesta. Por ejemplo .Net utiliza el "forbidden Http Handler" para proteger archivos de configuración, código fuente, base de datos, etc., este Http Handler lo único que hace es responder que el acceso a los recursos solicitados esta denegado.

Las páginas web, los eventos y todo el manejo que tantos usuarios queremos es provisto por por el PageHandlerFactory, así como el manejo de los serviciso Web es provisto por el WebServiceHandlerFactory.

¿Porque necesito saber de los handlers?

Esta es una tipica pregunta, bueno las respuesta son variadas pero yo enumero algunos ejemplos:

• Seguridad. Es de conocimiento de todos que un sitio web que maneja información crítica debe ser protegido adecuadamente y una de las principales prácticas en temas de seguridad es la reducción de la superficie de ataque. Es decir deshabilitar todos aquellos componentes que no utilicemos. Por ejemplo en un sitio de servicios Web es recomendable deshabiltiar el PageHandlerFactory y de ser posible incluir la extensión aspx en la sección de forbiden. También deberían incluirse en forbidden extensiones como ser cgi, asp, etc.
• Reutilización. Un handler es una herramienta muy poderosa para lograr grandes niveles de reutilización. Por ejemplo se podría crear un handler que lea un xml y con eso genere un feed en un formato especifico (RSS, ATOM u algún otro). Esto hace que todas mis aplicaciones solo tengan que generar un XML interno y cualquier cambio en la salida lo define en el Handler.
• Performance. Hoy casi todas las aplicaciones necesitan almacenar algún tipo de archivo en la base de datos y para recuperarlo se crea una página que en base a los parámetros limpia el response y manda el resultado. SI bien esto no es malo (y muchos proyectos públicos muy grandes lo usan) es muy ineficiente y resta gran escalabilidad a la solución. ¿Por qué? pues porque para atender el requerimiento se creo una instancia del PageHandlerFactory una instancia de una página, se hizo manejo de eventos y muchas otras cosas innecesarias, en este escenario un handler evita toda esta maquinaría y es más directo en el envío de la respuesta resultando en ganancia de performance y escalabilidad. Para que quede claro esta recomendación no solo es valida para la carga y descarga de imágenes, sino para: Feeds, documentos, páginas Html estáticas ensambladas, Filtro de contenido, etc.

Creo que estas son muy buenas razones para que los desarrolladores presten atención a los Http Handlers y piensen mejor cuando podrían utilizarlas.

En un próximo post haré un ejemplo más concreto en el cual trataré de mostrar la ganancia en seguridad y performance. Eso si tendrán que esperar a que retorne mi portátil.