Capítulo 6: El codigo por dentro

En el capítulo anterior aprendimos cómo el software guarda y organiza la información en bases de datos. Sabemos dónde viven los datos. Ahora toca responder a la pregunta que conecta todo lo demás: ¿qué ocurre exactamente entre que pulsas un botón en una pantalla y aparece el resultado que esperabas?

Ese instante que parece inmediato esconde un viaje completo de ida y vuelta. Entenderlo no te convierte en programador, pero sí en algo más valioso para tu negocio: en alguien que sabe distinguir un software bien construido de uno que se cae a la primera de cambio.

1. La cara y el cerebro: frontend y backend.

Todo programa que uses, desde tu correo hasta tu plataforma de facturación, tiene dos mitades que trabajan juntas pero hacen cosas radicalmente distintas.

El frontend es la cara. Es todo lo que ves y tocas: los botones, los colores, los menús, el formulario donde escribes. Vive en tu pantalla, ya sea en el navegador o en una aplicación. Su único trabajo es presentarte la información de forma comprensible y recoger lo que tú decides hacer.

El backend es el cerebro. Es la parte que no ves nunca: vive en un servidor, en algún lugar lejano, y es donde ocurre el trabajo de verdad. Cuando guardas una factura, el backend es quien la valida, la calcula, la registra en la base de datos y decide qué responder. El frontend solo enseña el resultado.

Para entenderlo sin tecnicismos, imagina un restaurante. El frontend es la sala: el camarero, la carta, la mesa, todo lo que el cliente ve y con lo que interactúa. El backend es la cocina: donde se preparan los platos, donde están los ingredientes y donde se hace el trabajo real. El cliente nunca pisa la cocina, pero de ella depende todo lo que acaba en su mesa.

Un software puede tener una sala preciosa y una cocina desastrosa. Por eso una interfaz bonita nunca es garantía de nada: lo que sostiene tu negocio es la cocina.

2. La comanda: cómo se hablan las dos mitades.

Si el frontend es la sala y el backend es la cocina, falta lo más importante: cómo se comunican. Porque el camarero no cocina, solo lleva y trae. Necesita un sistema para pasar tu pedido a la cocina y devolverte el plato.

Ese sistema es la petición (en inglés, request). Cada vez que haces algo en una aplicación (pulsar un botón, cargar una página, enviar un formulario) tu frontend lanza una petición al servidor donde vive el backend. El servidor recibe la comanda, el backend la procesa y devuelve una respuesta (response) que el frontend te muestra.

Este ir y venir es constante e invisible. Abrir tu bandeja de correo son decenas de peticiones. Buscar un cliente en tu CRM es una petición. Guardar un cambio es otra. Todo el software moderno funciona así: una conversación incesante de preguntas y respuestas entre la pantalla que tienes delante y un servidor que puede estar a miles de kilómetros.

Aquí aparece un concepto que ya vimos en el capítulo de las APIs y que ahora encaja del todo: la API es precisamente el menú que la cocina pone a disposición de la sala. Define qué peticiones se pueden hacer y en qué formato. Sin ese menú acordado, el camarero y el cocinero no se entenderían.

3. Por qué unas herramientas vuelan y otras se arrastran.

Ahora que entiendes el viaje, puedes entender también por qué hay tanta diferencia de velocidad entre dos programas que aparentemente hacen lo mismo. Y casi nunca es por tu ordenador.

La velocidad real de un software depende de tres factores que ocurren lejos de tu pantalla. El primero es la distancia y la calidad del servidor: si el backend vive en un servidor potente y bien ubicado, las respuestas llegan rápido; si comparte un servidor saturado y barato con otros mil clientes, se arrastra. El segundo es cuántas peticiones innecesarias hace: un software mal construido pregunta a la cocina cosas que ya sabía, una y otra vez, generando esperas evitables. El tercero es cómo busca en la base de datos, justo lo que vimos en el capítulo anterior: una consulta bien hecha responde en milisegundos, una mal hecha tarda segundos eternos.

La lectura práctica es importante. Cuando un proveedor te enseña una demo rápida y fluida con cuatro datos de prueba, no te está demostrando nada. El verdadero examen es cómo se comporta su backend con miles de registros reales y varios usuarios trabajando a la vez. Esa es la pregunta que deberías hacer: no "¿es rápido?", sino "¿sigue siendo rápido cuando la base de datos está llena y hay diez personas dentro?".

4. La nube no cambia las reglas, solo cambia la cocina de sitio.

Llegados a este punto conviene cerrar un círculo que abrimos en el capítulo sobre el servidor local y la nube. Toda esta arquitectura de frontend, backend y peticiones funciona exactamente igual tanto si el servidor está en tu oficina como si está en la nube. Lo único que cambia es dónde está físicamente la cocina.

Cuando usas software en la nube, tu frontend (el navegador) lanza peticiones a un backend que vive en los servidores del proveedor. Cuando usas software local, el frontend habla con un backend que está en tu propia red. La conversación es la misma; cambia la dirección del destinatario.

Entender esto te da una ventaja concreta a la hora de decidir. Un software que hace muchísimas peticiones al servidor será muy sensible a la calidad de tu conexión a internet si está en la nube, y casi inmune a ella si está en local. Por eso ciertas herramientas pesadas se sienten lentas en la nube y volando en un servidor propio: no es el programa, es la cantidad de viajes que tiene que hacer la información y la distancia que recorre en cada uno.

Lección Final: lo que importa está donde no miras.

Pasar de noob a experto en este punto significa interiorizar una idea sencilla pero poderosa: lo que sostiene un software no es lo que ves, sino lo que no ves. La interfaz es la sala del restaurante, y una sala bonita es agradable, pero nadie vuelve a un restaurante por las sillas. Se vuelve por la cocina.

La próxima vez que evalúes una herramienta para tu negocio, resiste el hechizo de la interfaz pulida y haz las preguntas que de verdad importan: ¿dónde está el servidor que la mueve? ¿Cómo se comporta con datos reales y muchos usuarios? ¿Cuánto depende de mi conexión? Un proveedor serio sabrá responderte. Uno que solo sabe enseñarte botones bonitos te está vendiendo una sala sin cocina detrás.

Y una sala sin cocina, tarde o temprano, deja a todo el mundo con hambre.