4dim / Notas
Un módulo con la base dentro se va entero al navegador
Tu pantalla usa una lista de un archivo, ese archivo usa el conector de la base, y el conector acaba en el paquete que descarga cada visitante. La regla de dos líneas que lo evita, y el beneficio que no se buscaba.
Un archivo tira de otro, y ese de otro
Si tu web tarda en cargar y no entiendes por qué, esta nota describe la causa más común en aplicaciones modernas, y la regla de dos líneas que la evita. Es un problema de organización de archivos, no de programación.
Cuando una pantalla necesita saber algo —qué canales hay, qué tramos de fecha se ofrecen— lo natural es ponerlo junto a las consultas que manejan esos datos. Todo lo de canales, en el archivo de canales.
El problema es que las herramientas de construcción modernas siguen las referencias en cadena. Si tu pantalla usa una lista de ese archivo, y ese archivo usa el conector de la base de datos, entonces el conector de la base entra en el paquete que descarga el navegador.
Un archivo con el conector de la base dentro se va entero al navegador, con todo lo que él a su vez arrastra.
Y no es un poco de peso. El conector de una base de datos trae criptografía, manejo de conexiones, análisis de protocolo. Son cientos de kilobytes que nunca se van a ejecutar, descargados por cada visitante.
La regla, y dónde se corta
La regla que seguimos cabe en una frase: lo que también mira una pantalla vive en un archivo que no toca la base de datos.
Eso parte en dos lo que intuitivamente era un solo tema. Y sí, hay dos archivos donde antes había uno.
| Tema | Lo puro | Lo que toca la base |
|---|---|---|
| Canales | Las reglas de cada canal | Las filas de la tabla |
| Audiencias | La forma de un filtro | Traducirlo a consulta |
| Prospección | Los nombres de las cosas | Las fichas |
| Tareas | Cuándo vence, cómo se dice | Guardarlas y leerlas |
La partición no es arbitraria y es fácil de decidir: a un lado, lo que se puede calcular con lo que ya tienes en la mano; al otro, lo que hay que ir a buscar.
El beneficio que no se buscaba: se puede probar
La separación se hizo por el peso del paquete, y trajo algo más valioso.
Lo que queda en el lado puro se puede probar sin levantar nada. Sin base de datos, sin servidor, sin datos de prueba. Son funciones que reciben algo y devuelven algo.
Y resulta que ahí está casi toda la lógica que de verdad se puede equivocar: cómo se agrupa un número de teléfono, si una fecha existe, a quién le toca el turno, qué significa «frío». Las consultas suelen ser simples; lo retorcido son las reglas.
La pieza que decide a quién le toca una conversación en un reparto por turnos es aritmética pura precisamente por esto: es la única parte que puede equivocarse en silencio, y separada tiene prueba propia.
Recibir la lista, y no ir a buscarla
Hay un caso que enseña la otra cara de la regla, y es el más instructivo.
Las etapas del embudo las nombra cada negocio, así que están en la base. Y varias piezas necesitan leerlas: el compositor de campañas, la cabecera del chat, las acciones del asistente.
Lo natural sería que cada una las pidiera. Eso significaría varias consultas por cada carga de pantalla, todas pidiendo lo mismo. Y además contagiaría: las funciones pasarían a tener que esperar, y todo lo que las usa también, y así hasta arriba.
La solución: quien atiende la petición carga la lista una vez y la reparte. Las funciones que la leen reciben la lista como argumento. Se quedan puras, rápidas y probables.
Es una regla que vale mucho más allá de esto: pasar el dato es casi siempre mejor que dejar que cada quien vaya a buscarlo. Lo contrario produce una pantalla que hace treinta consultas y nadie sabe de dónde salen.
Cómo se detecta esto en tu propio proyecto
No hace falta una auditoría. Hay dos comprobaciones de cinco minutos.
Mira el peso de lo que descarga tu página. Las herramientas de desarrollo del navegador lo dicen. Si una página que solo enseña texto descarga cientos de kilobytes de código, algo se está colando.
Busca qué archivos importa cada pantalla, y qué importan esos.Dos saltos suelen bastar para encontrar al culpable. Casi siempre es un archivo «de utilidades» que alguien creó con buena intención y que acabó importando de todo.
La señal de alarma es un archivo que se llama «utilidades», «común» o «ayudantes». Esos nombres no dicen qué hay dentro, así que todo el mundo mete ahí lo suyo, y acaban importando el mundo entero.
Qué hacer entonces
- Separa lo puro de lo que va a la base. Dos archivos donde te pedía el instinto poner uno.
- Usa el criterio de «¿hay que ir a buscarlo?». Si se puede calcular con lo que ya tienes, va al lado puro.
- Pasa los datos, no los busques desde dentro. Una carga arriba y a repartir.
- Mira el peso de tus páginas una vez al mes. Estas cosas entran de una en una y no se notan hasta que suman.
- Desconfía de los archivos llamados «utilidades». Un nombre que no dice qué hay dentro acaba conteniendo todo.
Esta nota sale de nuestro trabajo en Desarrollo de Software a medida.