Intro a la programación web para programadores de escritorio

Hola, este artículo va dirigido a una persona en concreto a la que no tengo tiempo de explicarle ciertas cosas como querría, así que lo voy poniendo por aquí a ratos y, de paso, lo dejo por si le es interesante a alguien.

Cosas a tener en cuenta:

• Tal y como he dicho, esto es una introducción a conceptos básicos, que programadores habituales de entorno no web no tienen claros  y que suponen un cambio de paradigma para ellos. 
• No es un documento hipertécnico, pero a lo mejor tampoco para principiantes, está expresado con palabras que creo que cualquier programador puede entender pero, en algunos casos, puedo haberme permitido alguna licencia técnica y haber omitido algo o haber dicho algo que no  es exactamente así (si eres consciente de eso, posiblemente este documento no sea para ti).

Primera cosa, la programación web, no es como la programación de escritorio, parece una perogrullada pero no lo es, veamos, bajo mi punto de vista la mayor diferencia para que se tenga en cuenta:

• En la programación de escritorio uno escribe una aplicación y se ejecuta en una máquina, bajo unas determinadas condiciones y un determinada forma de programar, por ejemplo, hacemos una aplicación  en C# tipo cliente - servidor que se conecta con una base de datos PostgreSQL. Por lo tanto esta aplicación se compila a un código que interprete una máquina virtual o a nativo y se ejecuta en un equipo. Un concepto interesante, depende como programemos, que nos simplificará bastante las explicaciones en el futuro es el de tener parte de la lógica en el lado de la base de datos (no voy a entrar en discusiones de si es bueno o malo), eso implicaría que entendemos el concepto de que algo se ejecute en un servidor fuera de nuestra aplicación y nos devuelva unos resultados (por ejemplo un procedimiento almacenado).
• En una aplicación Web, uno escribe una aplicación pero su mentalidad tiene que cambiar con respecto a donde se ejecuta, porque esta aplicación posiblemente tenga una parte que se ejecuta en un servidor (como el procedimiento almacenado) y otra parte que se ejecuta en un navegador del equipo del usuario (del cliente), y he aquí una gran diferencia. Obviando complementos (tipo flash, silverlight, etc,), el navegador web sólo entiende dos cosas HTML y Javascript.

Otra gran diferencia a tener en cuenta es que todas las comunicaciones entre la parte que se ejecuta en el servidor y la parte cliente se realizan sobre protocolo HTTP y por tanto de forma stateless, nos quedamos con la palabra pero no voy a profundizar. Lo que quiere decir esto básicamente es que cada vez que cargamos una página web el servidor nos devuelve de nuevo la información sin tener en cuenta "variables de estado", esto se subsana utilizando técnicas para conservar el estado de los datos que nos interesa en el servidor, por ejemplo mediante un identificador de sesión. ¿Qué demonios quiere decir esto?, que la información tiene que almacenarse en algún sitio, por lo tanto o la vamos guardando toda del lado del cliente y la pasamos al servidor de cada vez para que haga lo que tenga que hacer, o la guardamos del lado del servidor y le pasamos, por ejemplo, alguna información con un identificador de sesión para que el la realice y nos devuelva los datos que necesitemos, siempre manteniendo el identificador de sesión. Hay más formas de hacer esto, pero como se puede ver la cosa se complica un poco con respecto a la programación de escritorio.

Cuando hablamos de que pasamos algo al servidor o él nos lo pasa esto se realiza sobre protocolo HTTP y se puede realizar (hay más pero aquí solo nos interesan estas inicialmente) mediante lo que se llama un POST o mediante un GET. Hay algunas diferencias importantes entre estos métodos, que aquí se explican perfectamente, pero básicamente el GET va en la URL visible de longitud máxima 2048 caracteres ASCII y el POST se envía sin reflejarse en la URL y no tiene restricciones, cae de cajón que el POST es más seguro que el GET. Aunque en la página de w3schools pone que el POST es de tamaño ilimitado, normalmente este tamaño es limitado por el servidor para evitar "problemas", con lo cual hay que tener en cuenta el tamaño del POST configurado en el servidor si queremos "subir" cosas grandes desde el cliente.

Bien explicado todo esto ya tenemos lo básico para saber como funciona la programación web. Resumiendo:

• Hay dos sitios donde se pueden ejecutar las cosas (cliente) Navegador web y servidor (equipo que nos da los resultados)
• Además del lenguaje en el que realizamos la parte gorda de operaciones vamos a necesitar como mínimo conocimientos de HTML, Javascritpt y hoy en día también CSS
• Dependiendo que tecnología usemos deberemos conocer más o menos de esto, por ejemplo si usamos ASP.NET WebForms, se  supone que no tenemos que conocer mucho porque hará todo por nosotros, sin embargo si usamos ASP.NET MVC u otras cosas vamos a tener que meternos en otras capas.

De todas formas la plataforma de desarrollo o las herramientas son importantes pero lo más importante es el programador. Como dijo un día  Scott Guthrie: “Great developers using bad tools/frameworks can make great apps. Bad developers using great tools/frameworks can make bad apps.”

Por lo tanto para empezar se puede empezar con algo que nos permita una transición ligera tipo WebForms para luego si tal lanzarnos a MVC o a Linx con PHP o a lo que queramos.

Vamos a aclarar algunos conceptos a mayores:

• HTTP: Protocolo que sirve para comunicarnos con el servidor, le mandamos cosas en texto y nos devuelve cosas en texto que interpreta el navegador (más info poner HTTP en buscador)
• HTML: lenguaje de marcado, esto es un texto con etiquetas que le dicen al navegador lo que tiene que hacer.
• JavaScript: Lenguaje de script que ejecutamos en el navegador 
• CSS: Hojas de estilo en cascada (decir esto y nada es lo mismo). Es texto que le dice al navegador como tiene que decorar los distintos elementos que vemos.

(Ojo! el HTML y el Javascript son texto que interpreta el navegador aquí no se compila nada)

• Servidor web: este término se utiliza muchas veces para designar la máquina donde se ejecuta la aplicación a la que se denota por el mismo nombre "servidor web". Por lo tanto por el contexto sabemos a qué nos referimos. El servidor web es la aplicación sobre la cual se ejecuta nuestro código del lado del servidor, por ejemplo un servidor Apache, o un servidor IIS. 
• Navegador Web: es la aplicación que ejecuta nuestro código del lado del cliente.

Por lo tanto la programación web para un programador tradicional es un galimatías de cuidado, ya que le obliga a preocuparse de cosas que antes eran obvias y tenía un RAD maravilloso para colocar elementos que ahora (para hacerlo rápido) va a tener que picar en HTML, a esos elementos va a tener que asignarle colorines y cosas por el estilo mediante CSS y aún para mayor complicación va a tener que hacer cosas, como comprobaciones de datos o cargar algo dinámicamente en Javascript para que todo funcione de forma correcta del lado del cliente. Y después de todo esto tendrá que hacer lo que siempre le ha gustado que es programar.

Realmente no parece tan complicado... jajajaja. Pongamos un ejemplo comparativo: queremos que al seleccionar algo en un combo nos cargue otro combo con otra cosa.

Procedimiento en programación de escritorio con herramienta  RAD:

1. Diseñar formulario donde incluye combos (arrastrar colocar y poner colorines)
2. Asignar al evento que corresponda la función (cuando el combo cambié o al perder el foco o lo que sea ejecutar TaloCualFunción)
3. TaoCualFunción, se encarga de cargar el combo 2 a partid del cambio del 1.

Procedimiento en programación web (dos variantes la bonita y la fea).

Parte común:

1. Diseño el formulario HTML y le digo que el FORM me mande los datos por POST.

Opción fea:

2. Diseño función TaloCualFunción que cuando me llega un POST recojo el valor seleccionado del combo 1 llamo a la función TaloCualFunción que rellena el combo 2 y reescribo el HTML con el combo 2 cargado con los datos que correspondan y lo devuelvo

Esta opción es fea, porque implica que la página se va a recargar, en un caso real tendríamos que asignar un código de operación en una variable oculta o comparar el valor del combo o algo así para saber que lo que queremos hacer es rellenar el combo 2, además si el usuario ya ha introducido datos en el formulario a parte de los datos del combo habría que pasar todos los datos (cosa que ya hace la etiqueta FORM) pero habría que recogerlos del otro lado y volver a regenerar el HTML con ellos cargados

Opción bonita (agárrate que vienen curvas):

2. En el evento onchange del elemento combobox del HTML asignamos la función TaloCualFuncion de javascript para que cuando cambie el combo 1 cargue los datos en el combo2
3. Hacemos la función javascript que haga el proceso

Y ahora veamos como se pude hacer esto del punto 3 en javascript, bien la función está en el cliente y los datos del combo 2 (en una base de datos posiblemente) en el servidor. Pues bien, podemos usar a nuestro amigo AJAX, que queda muy bonito el nombre, pero que tiene tela (para más info ver el link). Que vamos a hacer con el AJAX, bien lo que hacemos es desde javascript hacer una petición HTTP al servidor (con lo cual el servidor tiene que tener algún método programado (webapi, para que vayan sonando las cosas) que responda a él) y decirle que nos de los datos. El servidor nos los da, y luego en tiempo real modificamos el HTML de la página (añadimos elementos al combo) para modificar el combo 2.

En resumen, un follón.

Para todo esto, hoy en día hay cosas que se pueden usar que te simplifican la vida como JQuery, aunque no tengo claro a veces si compensa el meter tremenda librería para rellenar un combo, pero lo dicho antes, lo importante es el resultado no las herramientas. Por suerte, los entornos de desarrollo se van adaptando al medio y cosas como el VisualStudio o el Eclipse nos facilitan mucho la vida.

Bajo mi punto de vista lo más importante es ser ordenado, evidentemente no me refiero a tener la mesa ordenada, sino a que dado que tenemos tantas "capas de cebolla" para hacer una aplicación web es importante tenerlas bien separadas, escojamos el lenguaje que escojamos o las herramientas que queramos, observemos que básicamente hay dos capas importantes:

• Lado del servidor (C#, Java, PHP, Python, Perl, puff lo que queráis casi)
• Lado del cliente (HTML, Javascript y si queremos por ponerlo aparte CSS)

Teniendo en cuenta estas cosas es importante, ojo, siempre bajo mi punto de vista,  tanto la organización estructural del código fuente (muchas de las herramientas ya nos lo estructuran en directorios apropiados), como el evitar la mezcla de capas entre sí. Que quiero decir con esto, bien, se puede hacer una página en PHP o ASP.NET mezclando el HTML y la programación en la misma página incluso con el Javascript y las CSS y tener unos resultados perfectos, pero la mantenibilidad de esto es de carácter dudoso, por lo tanto yo separaría perfectamente estas capas. Y... ¿cómo lo hacemos? De la siguiente forma:

• El HTML se utiliza como plantilla con Etiquetas que se reemplazan desde la parte de programación, esto es lo que se lleva haciendo toda la vida y lo que siguen haciendo los lenguajes actuales, pero poniéndonoslo más fácil. Este HTML incluirá las referencias a las CSS y código Javascript que utilice, que, deberán estar en ficheros separados
• La programación que controla todo, incluso la generación del HTML debe tener sólo eso código de control, que lea una plantilla y la rellene de datos o que haga lo que quiera con ella, en la medida de lo posible (no siempre es posible) debe evitar el uso de HTML, y en caso de usarlo, por ejemplo para generar elementos de una lista, se debe hacer con etiquetas HTML simples, a ser posible sin utilizar clases ni estilos ni javascript, intentando escribir esto en el fichero que corresponda de alguna forma. Por ejemplo en el caso de los elementos de la lista puede definirse su formato desde un CSS externo que incluya la plantilla HTML  donde insertamos los elementos de la lista.

Trabajar de esta forma, evidentemente, nos va a suponer un poco más de tiempo (no tanto hoy en día porque la mayoría de los entornos de desarrollo nos permiten hacerlo fácilmente), pero merece la pena, porque, aunque empecemos un proyecto de forma individual, puede que el día de mañana seamos un equipo trabajando en la misma aplicación y esto nos permitirá, por ejemplo, que un diseñador muy bueno que sepa mucho de HTML no tenga que preocuparse de andar esquivando el código mezclado con el mismo, o de encontrar el HTML dentro de un código que no entiende.

Profundizaré un poco más ahora en la parte de eso que comenté antes de los estados, relacionándolo con cómo se ejecuta la aplicación. Cuando una aplicación de escritorio se ejecuta, se encuentra en un determinado estado a partir del cual se sigue ejecutando, dependiendo de factores condicionales como  por ejemplo los eventos del sistema. En una aplicación web la ejecución en local con Javascript y HTML funciona más o menos parecido, pero cuando pasamos todas esa información para que el servidor haga algo, ahí la cosa cambia, desde el punto de vista, que la aplicación siempre se ejecuta desde el inicio, esto es, en cada petición pasa por el punto de partida, y es ahí donde tenemos que determinar (en base a los datos que recibimos) cual es el estado en el que estamos y por donde seguimos. Realmente, teniendo claro este concepto no hay ningún problema y la adaptación es sencilla.

Con esta idiosincrasia de ejecución, la cosa no cambia tanto como creemos, por ejemplo, en el caso del rendimiento de una aplicación, en modo escritorio esta dependía (vamos a obviar la programación que será igual de buena o mala en ambos casos dependiendo del programador) de la máquina donde se ejecutase y el rendimiento del servidor de la base de datos. Ahora es lo mismo, pero un poco más complicado, por los siguientes factores:

• La parte cliente no la hacemos nosotros, la interpreta un navegador, con lo cual va a depender del rendimiento de esté además de nuestra programación.
• La parte del servidor suele tener dependencias de otros servicios o servidores, es decir tenemos trozos de programa que se ejecutan en un servidor (máquina), pero las peticiones suelen ser cursadas por un servidor web (programa) que muchas veces determina como se ejecuta nuestro código. Normalmente de que este servidor funcione bien se encarga la gente de sistemas, pero es un punto más a tener en cuenta. 
• Por supuesto nuestro amigo el servidor de la base de datos va a seguir estando, que en casos de aplicaciones pequeñas a lo mejor hasta se ejecuta la base de datos y la aplicación web en el mismo host físico
• Otra consideración es la escalabilidad, que realmente tampoco cambia tanto. Normalmente en las aplicaciones de escritorio (cliente-servidor) tenemos una escalabilidad vertical en el lado del cliente (si no llega se aumenta el hardware) y una escalabilidad vertical y horizontal en el lado de la base de datos (se puede crecer en hardware o añadir nodos si la base de datos soporta el hardware). En el caso web, es lo mismo, pero hay que tener en cuenta cómo y donde guardamos las cosas ¿por qué?, muy simple, por la escalabilidad horizontal de los servidores web (obviamos la base de datos, porque es lo mismo que en el otro caso), por lo tanto si guardamos algo en un disco duro local de un servidor, debemos tener en cuenta que puede que en la próxima petición que se lanzará automáticamente (sin depender de la aplicación) a otro servidor no lo tendremos, es por ello que debemos tener un poco más en cuenta como hacer ciertas cosas (para muchas nos darán solución nuestros amigos de sistemas, otras tendremos que ingeniárnoslas nosotros)