Cliente, servidor, backend, frontend, ¿qué es todo esto?

Si estás acostumbrado a trabajar o desarrollar aplicaciones de escritorio, tienes que saber que hay unas diferencias importantes en la filosofía de funcionamiento con las aplicaciones web, así que te tienes que olvidar un poco de como funcionan las aplicaciones de escritorio, del int main(…) o del flujo lineal del programa.

Pongamos una aplicación web que se ejecute desde el navegador, es decir, sin que instales nada en tu ordenador. En un caso así, tu pondrías una dirección en el navegador (gmail, por poner una) y te aparecería una página web. En esa página metes un usuario y le das al botón de acceder, y entonces te aparece otra página. Y de esta forma vas interactuando. Eso es una aplicación web; todo se basa en que cada vez que pones una dirección, o tocas un botón, o rellenas un formulario….esa información se envía a un servidor, se procesa allí, y te manda a la «siguiente» pantalla.

Con esto en mente, vamos a explicar más despacio las partes de una aplicación web.

Frontend y backend

En una aplicación web hay dos partes diferenciadas, que se llaman el frontend (front) y el backend (back).

El backend es el que realiza todo el procesamiento pesado relacionado con la aplicación. Por ejemplo, cuando ponemos datos en un formulario y le damos a enviar, esos datos llegan a un servidor donde hay una aplicación que hace algo con ellos.

Esa parte de la aplicación que procesa esos datos, es el backend. Es la parte que recibe las peticiones, datos, órdenes, etc, de las páginas del navegador y las procesa (estas peticiones, unas veces serán una url para mostrar una web, otras recibirá datos de un formulario para almacenarlos en una base de datos o hacer algo con ellos….). Y, una vez procesadas, hace que se envíe algún tipo de respuesta al navegador.

¿Y qué es el frontend? Pues son las distintas webs que el servidor manda al navegador; lo que se muestra en la pantalla. Es decir, en algún momento, el backend procesa una información y da la orden de que se envíe al navegador del cliente la página «todoBien.html». Esa web forma parte del frontend.

En pocas palabras: * el backend es la parte de la aplicación que realiza el trabajo pero no se ve * el frontend son las webs (los ficheros html, jsp, php….) que se ven en el navegador

Poco a poco iremos viendo todas estas cosas con calma: como se pasan los mensajes entre el cliente y el servidor, como se monta todo para que funcione en un servidor de verdad, etc

¿Es lo mismo backend y servidor? ¿Es lo mismo frontend y cliente? No. En el servidor está tanto el backend(la aplicación que hace el procesamiento) como el frontend(las webs que se ven en el navegador), lo único es que las páginas del frontend se envían al cliente para que se muestren. El cliente sería, por tanto, el navegador web.

Lenguajes de programación

Ahora que ya sabes como es el ciclo de funcionamiento de una aplicación web, es fácil entender que, cuando tienes que desarrollar una, en realidad hay que programar dos cosas, el back y el front.

Hay empresas que tienen grupos separados para cada cosa, de manera que hay gente especializada en el back y otra en el front. Luego solo tienen que ponerse de acuerdo en las variables que se tienen que mandar entre ellos y listo.

Y, por supuesto, hay lenguajes de programación especializados para el front y para el back.

Para el back: java, phyton, php… Para el front: html, css, javascript….pero aquí hay que hacer una matización. Hay «lenguajes», como jsp, thymeleaf, etc, (que son los que de verdad se utiliza) que en el fondo no son más que una ayuda para que el front sea más fácil de programar, y que internamente lo que hacen es convertir todo a html para que se muestre en el navegador.

¿Como funciona todo a nivel de programación?

Para empezar, en este tipo de aplicaciones no hay una clase con un main() que lo inicie todo y en la que luego hayamos ido programando las clases que se crean a continuación.

En lugar de eso, hay una serie de clases que tendrán unas «anotaciones especiales» que le indican al servidor que esas clases tiene que crearlas al desplegar la aplicación. Es decir, en cuanto la aplicación se instala en el servidor, se crean automáticamente esas clases y se quedan ahí esperando. Por ejemplo, habrá una clase ahí creada que simplemente estará esperando a que le llegue una petición, y cuando llegue, ejecuta la función que sea( función que podrá crear otras clases, llamar a otras funciones….como cualquier aplicación).

Estas clases reciben un nombre u otro según el lenguaje (servlets, beans….) pero el funcionamiento es el mismo para todas.

Pues bien, en una aplicación web, hay clases que se encargan de acceder a la BD y recuperar, guardar o modificar datos (que luego se guardarán en algún objeto, claro). También hay clases que se encargan de hacer cálculos con esos datos o con los que llegan de los formularios de la web. Y hay otras clases que se encargan de responder a cada una de las posibles url’s (miweb/loquesea).

Para hacer todo esto un poco más llevadero y fácil de manejar, al programar, todas estas clases se suelen dividir en «capas» en función de lo que hacen. Y, por capas, hay que entender directorio, carpetas…..llámalo como quieras. Al final son paquetes (packages) en java. Lo que va en el mismo paquete está relacionado porque tienen la misma función.

Con todo esto en la cabeza, cuando hay que programar una aplicación web, básicamente lo que hay que ir haciendo es:

• ver que url’s puede solicitar el usuario desde su navegador web
• crear una clase que responda a esas peticiones
• esa clase, antes de responder, podrá llamar a otras para que le pasen los datos que hay que mostrar
• esas otras, podrán recuperar esos datos de la BD, podrán hacer cálculos con ellos, etc…
• la clase que tenía que responder a la petición, coge todos esos datos y ordena que se monte una web html y que se le mande al usuario (en realidad esa web html ya estará montada; solo hay que «incrustarle» los datos recuperados para que se puedan mostrar)

Y este es más o menos el ciclo que hay que ir haciendo todo el tiempo. A veces, el usuario no solicitará una url, sino que habrá metido datos en un formulario y los enviará para hacer algo, pero el ciclo es igual; se recogen, se procesan y se devuelve una web como resultado.

Y, después de estas explicaciones, ya sería el momento de empezar a programar. Para ver todo esto, he creado una web muy simple que me ha servido a mi para aprender. La parte de programación cae fuera de lo que quiero poner aquí, así que, en el siguiente post, solo pondré una descripción de qué hace la aplicación y como está hecha, pero nada de programación. Esa parte estará en GitHub.