Filtrado del lado del servidor vs del cliente: una lista de verificación para decidir

El problema real: fugas, retrasos y resultados inconsistentes

Filtrar en una UI es más que una sola caja de búsqueda. Normalmente incluye varias acciones relacionadas que cambian lo que ve el usuario: búsqueda de texto (nombre, correo, ID de pedido), facetas (estado, propietario, rango de fechas, etiquetas) y orden (más nuevos, mayor valor, última actividad).

La pregunta clave no es qué técnica es “mejor”. Es dónde vive el conjunto de datos completo y quién puede acceder a él. Si el navegador recibe registros que el usuario no debería ver, una UI puede exponer datos sensibles aunque los ocultes visualmente.

La mayoría de los debates sobre filtrado en servidor vs cliente son en realidad reacciones a dos fallos que los usuarios notan de inmediato:

• Fugas: datos que aparecen en payloads de red, respuestas cacheadas o a través de filtros inesperados que revelan filas ocultas.
• Retrasos: la pantalla se siente lenta porque envías demasiados datos y el dispositivo hace trabajo pesado en cada pulsación.

Hay un tercer problema que genera informes de bugs sin parar: resultados inconsistentes. Si algunos filtros se ejecutan en el cliente y otros en el servidor, los usuarios ven conteos, páginas y totales que no coinciden. Eso rompe la confianza rápido, especialmente en listas paginadas.

Una regla práctica y simple: si el usuario no puede acceder al conjunto de datos completo, filtra en el servidor. Si puede acceder y el conjunto es lo bastante pequeño para cargarse rápido, el filtrado en el cliente puede estar bien.

Definiciones rápidas en lenguaje claro

Filtrar es simplemente “muéstrame los ítems que coinciden”. La pregunta clave es dónde ocurre la comparación: en el navegador del usuario (cliente) o en tu backend (servidor).

Filtrado en el cliente se ejecuta en el navegador. La app descarga un conjunto de registros (a menudo JSON) y luego aplica filtros localmente. Puede sentirse instantáneo después de cargar los datos, pero solo funciona cuando el conjunto es lo bastante pequeño para enviarse y lo bastante seguro para exponerse.

Filtrado en el servidor se ejecuta en tu backend. El navegador envía los inputs de filtrado (como status=open, owner=me, createdAfter=Jan 1) y el servidor devuelve solo los resultados que coinciden. En la práctica, suele ser un endpoint de API que acepta filtros, construye una consulta a la base de datos y devuelve una lista paginada más totales.

Un modelo mental simple:

• Cliente: descarga mucho, filtra aquí.
• Servidor: pide exactamente lo que necesitas.

Los setups híbridos son comunes. Un buen patrón es aplicar los filtros “grandes” en el servidor (permisos, propiedad, rango de fechas, búsqueda) y luego usar toggles pequeños solo de UI localmente (ocultar archivados, chips rápidos de etiqueta, visibilidad de columnas) sin otra petición.

Ordenar, paginar y buscar suelen pertenecer a la misma decisión. Afectan el tamaño del payload, la sensación del usuario y qué datos estás exponiendo.

Factor de decisión 1: tamaño de datos y costo del payload

Empieza con la pregunta más práctica: ¿cuánta información enviarías al navegador si filtras en el cliente? Si la respuesta honesta es “más de unas pocas pantallas”, lo pagarás en tiempo de descarga, uso de memoria y en interacciones más lentas.

No necesitas estimaciones perfectas. Solo obtén el orden de magnitud: cuántas filas podría ver el usuario y cuál es el tamaño medio de una fila. Una lista de 500 ítems con pocos campos cortos es muy distinta de 50.000 ítems donde cada fila incluye notas largas, texto enriquecido u objetos anidados.

Los registros anchos son el asesino silencioso del payload. Una tabla puede parecer pequeña por número de filas pero ser pesada si cada fila contiene muchos campos, cadenas largas o datos joinados (contacto + empresa + última actividad + dirección completa + etiquetas). Aunque muestres solo tres columnas, los equipos a menudo envían “todo, por si acaso” y el payload se infla.

Piensa también en el crecimiento. Un conjunto que hoy está bien puede volverse pesado en pocos meses. Si los datos crecen rápido, trata el filtrado en cliente como un atajo a corto plazo, no como opción por defecto.

Reglas prácticas:

• Si no puedes enviar cómodamente el conjunto completo por una conexión móvil típica, filtra en el servidor.
• Si los usuarios solo tocan una pequeña porción a la vez, pide esa porción y filtra en el servidor.
• Si el conjunto es pequeño, estable y realmente seguro de exponer, el filtrado en cliente puede ser excelente.

Este último punto importa por algo más que rendimiento. “¿Podemos enviar el conjunto completo al navegador?” también es una pregunta de seguridad. Si la respuesta no es un sí seguro, no lo envíes.

Factor de decisión 2: latencia y experiencia de usuario

Las elecciones de filtrado suelen fallar por la sensación, no por la corrección. Los usuarios no miden milisegundos; notan pausas, parpadeos y resultados que saltan mientras escriben.

El tiempo se puede perder en distintos lugares:

• Red: tiempo de petición/respuesta y tamaño del payload
• Servidor: consultas a la base de datos, joins, orden, comprobaciones de permisos
• Navegador: parseo de JSON, renderizado de filas, filtrado de arrays grandes

Define qué significa “lo bastante rápido” para esta pantalla. Una vista de lista puede requerir escritura receptiva y scroll suave, mientras que una página de reportes puede tolerar una breve espera siempre que aparezca el primer resultado rápido.

No juzgues solo por la Wi‑Fi de la oficina. En conexiones lentas, el filtrado en cliente puede sentirse bien después de la primera carga, pero esa primera carga puede ser la parte lenta. El filtrado en servidor mantiene los payloads pequeños, pero puede sentirse lento si disparas una petición en cada pulsación.

Diseña en torno a la entrada humana. Usa debounce en las peticiones mientras se escribe. Para conjuntos grandes, usa carga progresiva para que la página muestre algo rápido y siga siendo suave conforme el usuario hace scroll.

Factor de decisión 3: permisos y exposición de datos

Los permisos deberían decidir tu enfoque más que la velocidad. Si el navegador alguna vez recibe datos que un usuario no puede ver, ya tienes un problema, aunque lo ocultes tras un botón deshabilitado o una columna colapsada.

Empieza por nombrar qué es sensible en esta pantalla. Algunos campos son obvios (emails, teléfonos, direcciones). Otros son fáciles de pasar por alto: notas internas, coste o margen, reglas de precio especiales, puntuaciones de riesgo, flags de moderación.

La gran trampa es “filtramos en el cliente, pero solo mostramos las filas permitidas”. Eso aún significa que el dataset completo fue descargado. Cualquiera puede inspeccionar la respuesta de red, abrir las dev tools o guardar el payload. Ocultar columnas en la UI no es control de acceso.

Cuando el filtrado en servidor es el valor por defecto seguro

El filtrado en servidor es el valor por defecto más seguro cuando la autorización varía por usuario, especialmente si distintos usuarios pueden ver diferentes filas o campos.

Chequeo rápido:

• ¿Roles distintos ven filas distintas (solo equipo, solo región, asignado a mí)?
• ¿Roles distintos ven campos distintos (notas, precios, PII)?
• ¿Hay reglas a nivel de fila (propietario de cuenta, etapa del trato, flag “privado”)?
• ¿Podrían exportaciones, ordenaciones o totales revelar información restringida?
• ¿Un payload filtrado podría crear un problema de cumplimiento?

Si alguna respuesta es sí, mantén el filtrado y la selección de campos en el servidor. Envía solo lo que el usuario puede ver y aplica las mismas reglas a búsqueda, orden, paginación y exportación.

Ejemplo: en una lista de contactos CRM, los representantes pueden ver solo sus cuentas mientras que los managers ven todo. Si el navegador descarga todos los contactos y filtra localmente, un representante aún podría recuperar cuentas ocultas desde la respuesta. El filtrado en servidor evita eso al no enviar esas filas.

Factor de decisión 4: caché y frescura

El caché puede hacer que una pantalla parezca instantánea. También puede mostrar la verdad equivocada. La clave es decidir qué puedes reutilizar, durante cuánto y qué eventos deben invalidarlo.

Empieza por elegir la unidad de caché. Cachear una lista completa es simple pero normalmente desperdicia ancho de banda y caduca rápido. Cachear páginas funciona bien para scroll infinito. Cachear resultados por consulta (filtro + orden + búsqueda) es preciso, pero puede crecer rápido si los usuarios prueban muchas combinaciones.

La frescura importa más en algunos dominios que en otros. Si los datos cambian rápido (niveles de stock, saldos, estado de entrega), incluso 30 segundos de caché puede confundir. Si los datos cambian despacio (registros archivados, datos de referencia), cachés más largos suelen estar bien.

Planifica la invalidación antes de programar. Además del paso del tiempo, decide qué debe forzar una actualización: creaciones/ediciones/eliminaciones, cambios de permisos, importaciones o merges masivos, transiciones de estado, acciones de deshacer/rollback y jobs en background que actualicen campos que los usuarios filtran.

Decide también dónde vive el caché. La memoria del navegador hace que la navegación atrás/adelante sea rápida, pero puede filtrar datos entre cuentas si no lo claveas por usuario y org. El caché del backend es más seguro para permisos y consistencia, pero debe incluir la firma completa del filtro y la identidad del llamador para que los resultados no se mezclen.

Paso a paso: cómo elegir para una nueva pantalla

Trata el objetivo como no negociable: la pantalla debe sentirse rápida sin filtrar datos.

Un flujo práctico de decisión

1. Empieza con la restricción más fuerte. Si el acceso varía por rol, equipo, región, org o suscripción, los permisos ganan. Si el conjunto de datos es grande o puede crecer rápido, el tamaño gana.
2. Por defecto, servidor cuando los datos son grandes o sensibles. Si no te sentirías cómodo registrando el dataset completo en la consola del navegador, no lo envíes.
3. Usa filtrado en cliente solo para listas pequeñas, seguras y reutilizadas. Dropdowns de estado, pequeñas listas de etiquetas, una sola página de resultados ya aprobados.
4. Define la forma de la API antes de la UI. Escribe los filtros, orden, paginación y valores por defecto para que servidor y UI no discrepen.
5. Añade protecciones. Impone un tamaño máximo de página, establece timeouts y decide cómo se comporta la UI cuando el filtrado es lento (mostrar spinner, mantener resultados antiguos, ofrecer reintento).

Errores comunes que causan fugas o lentitud

La mayoría de los equipos tropieza con los mismos patrones: una UI que luce bien en demo, pero con datos reales, permisos reales y redes reales salen las grietas.

Errores que filtran datos

El fallo más grave es tratar el filtrado como presentación. Si el navegador recibe registros que no debería, ya perdiste.

Dos causas frecuentes:

• Enviar el dataset completo al navegador y filtrar localmente “por velocidad”. Cualquiera puede inspeccionar la respuesta o consultarla en memoria.
• Cachear respuestas filtradas sin ligar la clave de caché a identidad de usuario, org, rol o versión de política. Un cambio de permisos puede exponer datos antiguos de forma silenciosa.

Ejemplo: los internos solo deben ver leads de su región. Si la API devuelve todas las regiones y el dropdown filtra en React, los internos aún pueden extraer la lista completa.

Errores que vuelven la pantalla lenta

La lentitud suele venir de suposiciones:

• Asumir que filtrar en cliente siempre es más rápido. Con 50.000 filas, descargar y parsear puede tardar más que una consulta enfocada.
• Olvidar paginación y estados de carga. Una pantalla que se bloquea mientras renderiza una lista enorme se siente rota aunque la consulta sea correcta.

Un problema sutil y doloroso son reglas desajustadas. Si el servidor trata “empieza con” distinto que la UI, los usuarios verán conteos que no coinciden o ítems que desaparecen tras un refresco.

Lista rápida antes de lanzar

Haz un repaso final con dos mentalidades: un usuario curioso y un día de red mala.

• Sanidad del payload: confirma que las respuestas nunca incluyan filas o campos que el usuario no deba ver, incluso si la UI los oculta. Ojo con totales, conteos de grupos o IDs que permitan inferir datos restringidos.
• Logs seguros: los filtros suelen incluir emails, nombres o IDs. No registres valores sensibles de filtros, SQL completo o bodies completos en lugares con acceso amplio.
• Consistencia entre dispositivos: aplica los mismos filtros en desktop y móvil. Las diferencias suelen venir de ordenado en cliente, reglas de locale (mayúsculas, acentos) o valores por defecto distintos.
• Estados claros: loading, vacío y error deben ser obvios. Prueba cambios rápidos (escribir, borrar, toggles) para que la UI no parpadee ni muestre resultados obsoletos.
• Protecciones ante lo peor: tamaño máximo de página, rango máximo de fechas y timeouts. Protege contra consultas caras (wildcards, demasiadas condiciones OR, campos sin índices).

Una prueba simple: crea un registro restringido y confirma que nunca aparece en el payload, conteos ni caché, incluso cuando filtras ampliamente o limpias filtros.

Escenario de ejemplo: una lista de contactos CRM

Imagínate un CRM con 200.000 contactos. Los reps solo ven sus cuentas, los managers ven su equipo y los admins lo ven todo. La pantalla tiene búsqueda, filtros (estado, propietario, última actividad) y orden.

El filtrado en cliente falla rápido aquí. El payload es pesado, la primera carga se vuelve lenta y el riesgo de fuga de datos es alto. Aunque la UI oculte filas, el navegador recibió los datos. También presionas el dispositivo: arrays grandes, orden pesado, ejecuciones de filtro repetidas, alto uso de memoria y crashes en móviles antiguos.

Un enfoque más seguro es el filtrado en servidor con paginación. El cliente envía las opciones de filtro y el servidor devuelve solo las filas que el usuario puede ver, ya filtradas y ordenadas.

Un patrón práctico:

• Aplica permisos primero, luego filtros y orden.
• Devuelve una página a la vez (por ejemplo, 50 filas) más un conteo total.
• Cachea con cuidado (por usuario o por rol) para no mezclar resultados entre permisos.

Una pequeña excepción donde el filtrado en cliente está bien: datos diminutos y estáticos. Un dropdown de “Estado de contacto” con 8 valores puede cargarse una vez y filtrarse localmente con poco riesgo o coste.

Próximos pasos: documenta decisiones y construye con menos rehacer

Los equipos no suelen quemarse por elegir “mal” una vez. Se queman por tomar decisiones distintas en cada pantalla y luego intentar arreglar fugas y páginas lentas bajo presión.

Escribe una nota corta de decisión por pantalla con filtros: tamaño del dataset, coste de enviarlo, qué significa “lo bastante rápido”, qué campos son sensibles y cómo se cachearán (o no). Mantén servidor y UI alineados para no acabar con “dos verdades” sobre el filtrado.

Si estás construyendo pantallas rápido en Koder.ai (koder.ai), vale la pena decidir desde el principio qué filtros deben hacerse en el backend (permisos y acceso a nivel de fila) y qué toggles pequeños de UI pueden quedarse en React. Esa única decisión suele evitar las reescrituras más caras después.