Cómo añadir búsqueda a tu app: desde filtros sencillos hasta la búsqueda de texto completo

Para añadir búsqueda a tu app, empieza por lo más sencillo que funcione: un cuadro de búsqueda que llame a una ruta del servidor, la cual filtra las filas de tu base de datos comparando la consulta con unas pocas columnas, más filtros para cosas como la categoría o el precio. Cuando eso no sea suficiente (necesitas clasificación por relevancia, reducción de palabras a su raíz o muchos registros), pasa a la búsqueda de texto completo de tu base de datos, y solo recurre a un motor de búsqueda alojado si necesitas una buena tolerancia a erratas o resultados instantáneos sobre volúmenes de datos muy grandes. Elijas lo que elijas, la búsqueda debe respetar los permisos: los usuarios nunca deben encontrar registros que no tienen permiso para ver.

Qué significa «búsqueda» para tu app

La búsqueda abarca varias cosas distintas, y la mayoría de apps necesitan más de una:

Búsqueda por palabras clave: un cuadro de texto, «encuentra anuncios que mencionen "jardín"».
Filtros: opciones estructuradas: categoría, ciudad, rango de precio, fecha, estado.
Ordenación: lo más reciente, lo más barato, lo más relevante.
Autocompletado: sugerencias mientras escribes.
Tolerancia a erratas: «restarante» sigue encontrando «restaurante».

En un directorio, una bolsa de trabajo o una tienda, los filtros suelen importar más que el cuadro de texto. Decide cuáles de estas cosas necesitas de verdad antes de elegir una herramienta.

Tus opciones

Enfoque	Cómo funciona	Ideal para	Límites
Filtrar en el navegador	Cargar la lista y filtrarla con JavaScript	Listas públicas pequeñas (unos cientos de elementos)	Envía todos los datos a cada visitante; lento con listas grandes
Coincidencia de patrones en la base de datos	Consulta en el servidor tipo «el nombre contiene el texto», sin distinguir mayúsculas	Apps pequeñas o medianas, herramientas de administración	Sin clasificación; puede ir lento en tablas grandes; sin reducción a raíces
Búsqueda de texto completo en la base de datos	Postgres indexa las palabras y clasifica las coincidencias	La mayoría de apps con mucho contenido	Débil con erratas si no añades coincidencia difusa
Coincidencia difusa (trigramas)	Postgres compara secuencias de caracteres para medir la similitud	Nombres, campos cortos, tolerancia a erratas	Necesita una extensión y un índice; requiere ajuste
Motor de búsqueda alojado	Un servicio aparte indexa tus datos (Algolia, Meilisearch, Typesense, Elasticsearch y otros)	Catálogos grandes, búsqueda instantánea, mucha tolerancia a erratas	Otro servicio que mantener sincronizado, pagar y asegurar

Si tus datos ya están en Postgres, su búsqueda de texto completo integrada es un término medio muy sólido. Divide el texto en palabras, las reduce a su raíz (así «corriendo» coincide con «correr»), ignora las palabras comunes y puede clasificar los resultados según lo bien que coinciden. Con el índice adecuado sigue siendo rápida en tablas grandes.

Prompts de ejemplo

Un inicio sencillo:

Añade un cuadro de búsqueda y filtros a la página de anuncios. La búsqueda debe comparar la consulta con el título y la descripción, sin distinguir mayúsculas. Filtros: categoría (desplegable), ciudad (desplegable) y precio máximo. Haz la búsqueda en el servidor con una ruta de API paginada, 20 resultados por página. Mantén la búsqueda y los filtros en la URL para que los resultados se puedan compartir y el botón de volver funcione. Muestra un mensaje amable cuando no haya coincidencias.

Pasar a la búsqueda de texto completo:

Cambia la búsqueda de anuncios a la búsqueda de texto completo de Postgres sobre el título (con más peso) y la descripción. Añade el índice adecuado, ordena los resultados por relevancia y mantén los filtros y la paginación actuales. No cambies ningún dato existente.

Añadir tolerancia a erratas en nombres:

Añade coincidencia difusa sobre el nombre del negocio para que las erratas pequeñas sigan encontrando resultados. Usa la similitud por trigramas si está disponible, con un índice, y recurre a la búsqueda actual si no lo está.

Paso a paso

Haz una lista de lo que buscan las personas. ¿Qué campos (título, descripción, etiquetas, nombre)? ¿Qué filtros? Pregunta a algunos usuarios reales si puedes.
Empieza en el servidor. Añade una ruta de API que reciba la consulta y los filtros, y devuelva una página de resultados. No cargues todo en el navegador.
Aplica los permisos en la consulta. Si los usuarios solo ven sus propios registros, o solo los publicados, esa condición debe ir en la misma consulta que la búsqueda.
Añade paginación desde el principio: números de página o «cargar más».
Guarda el estado de la búsqueda en la URL (por ejemplo, ?q=jardin&city=leeds). Así los enlaces se pueden compartir, el botón de volver funciona y los buscadores pueden rastrear las páginas filtradas si lo quieres.
Aplica un retardo (debounce) a la búsqueda mientras escribes. Espera unos cientos de milisegundos tras dejar de escribir antes de consultar, para no enviar una petición por cada pulsación.
Añade índices cuando sepas por qué columnas filtras y buscas.
Pasa a un nivel superior solo cuando el paso anterior falle con usuarios reales: texto completo, luego coincidencia difusa y después un motor alojado.
Prueba con datos realistas: cientos o miles de filas, caracteres raros, consultas vacías, consultas muy largas, otros idiomas si los soportas.

Errores habituales

Cargar toda la tabla en el navegador. Vale para 50 elementos, es doloroso para 50.000, y expone cada registro, incluidos los que el usuario no debería ver.
Una búsqueda que ignora los permisos. La búsqueda es una fuga habitual: aparece un registro privado o un borrador porque la consulta olvidó la condición de «solo los míos» o «solo los publicados».
Construir SQL con lo que escribe el usuario. Usa siempre consultas parametrizadas. Un creador con IA normalmente lo hace, pero comprueba si ves cadenas unidas a mano.
No tener estado vacío. «Sin resultados» con una sugerencia (quitar filtros, revisar la ortografía) evita que la gente se vaya.
No tener índices. La búsqueda parece bien con datos de prueba y se ralentiza según crecen los datos reales.
Saltar directamente a un servicio de búsqueda. Entonces tienes que mantener una segunda copia de tus datos sincronizada, gestionar los borrados y asegurar otro conjunto de claves, a menudo sin ninguna mejora visible.
Olvidarse del móvil. Los filtros tienen que caber en un teléfono; un cajón de filtros o un panel plegable suele funcionar mejor que una barra lateral.

Lista de comprobación

Sabes qué campos se buscan y qué filtros existen
La búsqueda se ejecuta en el servidor y devuelve resultados paginados
La consulta aplica los mismos permisos que el resto de la app
La entrada del usuario se pasa como parámetros, nunca unida al SQL
El estado de la búsqueda vive en la URL
La escritura tiene retardo (debounce)
Las columnas buscadas y filtradas tienen índice
Los estados vacío, sin resultados y de error son claros
Probado con volúmenes de datos realistas y entradas desordenadas

Añadir búsqueda con Mythex

En una app creada con Mythex, los datos suelen vivir en la base de datos Postgres propia del proyecto, así que puedes empezar con los prompts de arriba: primero la coincidencia de patrones y después la búsqueda de texto completo de Postgres cuando necesites clasificación. Si quieres un motor de búsqueda alojado, usa tu propia cuenta y clave, guárdala como secreto del proyecto y pídele al agente que indexe y consulte desde el servidor, como se describe en Integrar cualquier API.

La búsqueda es el núcleo de muchas apps: consulta cómo crear un sitio de directorio, cómo crear una bolsa de empleo y cómo crear un marketplace para ver cómo encaja en el resto del producto.

Preguntas

¿Cuál es la forma más fácil de añadir búsqueda a una app?

Si tus datos están en una base de datos, lo más fácil para empezar es una ruta del servidor que filtre las filas con una coincidencia sin distinguir mayúsculas en unas pocas columnas. Para una lista pequeña que ya está cargada en el navegador, filtrar en el navegador es todavía más sencillo.

¿Necesito Algolia o Elasticsearch para la búsqueda?

Normalmente no al principio. La búsqueda de texto completo de Postgres gestiona bien la coincidencia de palabras, la clasificación de resultados y desde miles hasta millones de filas. Un motor de búsqueda alojado merece la pena cuando necesitas buena tolerancia a erratas, resultados instantáneos mientras escribes sobre grandes volúmenes de datos o un ajuste avanzado de la relevancia.

¿Por qué mi búsqueda no encuentra resultados con erratas?

La coincidencia básica y la búsqueda de texto completo estándar buscan las palabras tal como se escriben (o sus raíces), así que una falta de ortografía no encuentra nada. Necesitas una coincidencia difusa, como la similitud por trigramas en Postgres o un motor de búsqueda con tolerancia a erratas.

¿La búsqueda debe ejecutarse en el navegador o en el servidor?

En el servidor, para todo lo que vaya más allá de una lista pública pequeña. La búsqueda en el servidor escala, respeta los permisos y no envía todo tu conjunto de datos a cada visitante.