Mirando la web de una forma distinta con Google Visualization API

Mirar hacia Google puede llegar a ser para algunos como mirar a las estrellas. Para algunos partiendo de una perspectiva peculiar de admiración, para otros simplemente para estar seguros de que algún día esa estrella no se les venga encima. Lo que si es innegable es que hay que prestarle atención al desarrollo del gigante de Mountain View. Es por esto que hoy comenzamos introduciendo una de las tecnologías de Google que más me ha impresionado: Google Visualization API. Quizás se asombre de saber de mi relación con ella, incluso antes de conocerla.

Mirando hacia Google

Google es una de las grandes empresas que más sigo porque realmente cada día me asombra más. Primeramente es una de las principales defensoras de la adopción del código abierto, y ha encontrado en este ecosistema una vía de sostener un modelo de negocios muy sólido. Por tal razón también se inclina por la adopción de otras tecnologías y estándares abiertos, y es el ente aglutinador que ha logrado movilizar a otras grandes empresas en disímiles proyectos. Por otra parte es admirable su inclinación pronunciada por traer el órden a este océano turbulento que es Internet y especialmente con respecto al caos de las tecnologías web. Estas dos características convergen en este artículo. Quizás la mejor manera de comenzarlo sería así ...

Había una vez un mundo lleno de bases de datos incompatibles cuyo formato permanecía escondido y guardado celosamente por sus creadores. En este tiempo surgió SQL. A la par se hizo general el malestar de los usuarios al dificultarse la migración sus datos de un gestor de base de datos hacia otro y el de los programadores al ver limitada la distribución de sus aplicaciones y emplear gran esfuerzo en hacerlas compatibles con cada gestor. Por tanto surgieron varios estándares (sí ... unos más abiertos que otros ;) para lograr que todas las aplicaciones pudieran consultar cualquier base de datos utilizando solamente el muy estable SQL.

Pero a medida que Internet ganaba en popularidad e importancia fueron surgiendo herramientas que facilitaban la construcción de herramientas web. Y surgió AJAX y los sitios lograron ser más dinámicos. Y muchos brindaron soporte para AJAX porque era bueno. Luego proliferaron las tecnologías como Yahoo! User Interfaces concentradas en enriquecer las páginas web de los sitios. Además surgieron los ORM, y muchos frameworks incorporaban uno porque así se podía acceder más facilmente a los datos. Y los frameworks web hacían cada vez más alusión a su diseño MVC. Y muchos buscábamos esta característica porque así era posible ser más eficientes al crear componentes que eran reutilizables. Pero ... ¿qué era lo que había en el fondo realmente?

Mi experiencia personal

Ya por esos tiempos, mientras cursaba una certificación de programación web en Java ofrecido por el NIIT, me vi con posibilidades de matricular otros dos: uno de Django (Python) y otro de ASP.NET AJAX (C#). Y fue en ese momento cuando me cuestioné ... ¿Qué podría hacer para lograr aprobarlos los tres considerando mi extremadamente poco tiempo libre?.

Fue en ese momento cuando logré darme cuenta de que, una vez que eligiera cualquiera de ellos, caería en una tiranía de ese framework particular. Si seguía sus reglas, tales ataduras serían tan fuertes que me costaría mucho trabajo después reutilizar lo ya hecho para migrar el sitio hacia otra plataforma de desarrollo. Y entonces me asaltó una duda ... como es que todos podían ser MVC. Un entorno de desarrollo web basado en este paradigma, debería permitir la sustitución de una tecnología por otra sin que hubiera necesidad de rehacer (siquiera tocar ...) la implementación de la interfaz de usuarios. Sin embargo, cada una de las herramientas mencionadas se limitaba a adoptar el patrón MVC para estructurar las clases del propio framework ... pero quizás no notaron que la separación entre modelo, vista y controlador venía asociada al hecho de que existían datos administrados por un gestor, usuarios que acceden al sitio desde su PC a través de su navegador web, y un servidor web cuyo papel era preparar esos datos y hacerlos llegar a quién los solicitó.

Y fue entonces cuando me decidí a hacer junto con Orapma, Evelin y Carlitos un proyecto de curso basado en AJAX + JSON ... La ventaja de este enfoque reside en que el mismo sitio se puede implementar variando las tecnologías de programación en el servidor (en mi caso particular Django, ASP.NET AJAX y JSP ) con un mínimo de esfuerzo, y no se apreciarían cambios de ningún tipo en la interfaz de usuarios y en la navegación. Todo esto es ideal, por ejemplo, para migrar el sistema hacia un servidor, o plataforma.

El punto de vista de Google

Al parecer los ingenieros de Google (y otros como los desarrolladores de DoJo ;) tenían inquietudes similares. Lo único que ellos pensaron en grande ... El primer paso era darse cuenta de que muchas veces las trabas venían dadas por la carencia de una tecnología abierta basada en los estándares de la web que acercara los datos a los programadores , por las limitaciones de acceso desde la web a los datos gestionados por las diferentes organizaciones, y por la sumisión de los desarrolladores a la tiranía de los frameworks. El próximo paso ya ha sido dado.

Google ha lanzado su plataforma Google Visualization API. Su misión es erguirse como el nuevo ODBC para vencer las barreras de acceso a los datos según la estructura actual de Internet. Esta tecnología se vale de JSON para independizar la implementación de la vista (en la PC del cliente) del servidor web y de la forma en que se almacenan los datos; y todo esto a través de un protocolo abierto, relativamente sencillo y muy bien documentado. Por lo tanto se logra separar el desarrollo de un sitio en dos roles: los programadores de componentes web, y desarrolladores de los servicios que ofrecerá el servidor. Todo esto me recuerda la explosión que implicó la aplicación del enfoque de Delphi para aplicaciones de escritorio. En ambos casos se puede escoger las tecnologías para implementar las visualizaciones y los servicios debido a que Google Visualization API no presenta obstáculos para enlazar tecnologías de cualquier tipo. Ya para terminar, al mismo tiempo Google ha concebido un repositorio de manera que sea muy fácil buscar el componente que se ajuste más a nuestras necesidades; y ha conectado esta plataforma con la tecnologíua de gadgets para facilitar su uso.

Nada ... que simelo preguntan, solo se me ocurriría responderles que este año 2009 parece ser que se estrecharán las distancias entre los modelos de desarrollo de aplicaciones para la web y las de escritorio. Y acerca de Google ... cualquier comentario se queda chiquito.