Cómo añadir búsqueda a tu app: de los filtros simples a la búsqueda de texto completo

Para añadir búsqueda a tu app, empieza con lo más simple que funcione: un cuadro de búsqueda que llame a una ruta de servidor, que filtre las filas de tu base de datos comparando la consulta con unas pocas columnas, más filtros para cosas como categoría o precio. Cuando eso no sea suficiente —necesitas ordenar por relevancia, reducir palabras a su raíz o manejar muchos registros—, pasa a la búsqueda de texto completo de tu base de datos, y solo cambia a un motor de búsqueda alojado si necesitas una gran tolerancia a erratas o resultados instantáneos sobre datos muy grandes. Elijas lo que elijas, la búsqueda debe respetar los permisos: los usuarios nunca deben encontrar registros que no tienen derecho a ver.

Qué significa «búsqueda» en tu app

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

Búsqueda por palabras clave: un cuadro de texto, por ejemplo «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: «restuarant» todavía encuentra «restaurant».

Para un directorio, una bolsa de empleo o una tienda, los filtros suelen importar más que el cuadro de texto. Decide cuáles de estas 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 del servidor tipo «el nombre contiene el texto», sin distinguir mayúsculas	Apps pequeñas y medianas, herramientas de administración	Sin ranking; 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 ordena las coincidencias	Apps con mucho contenido	Débil ante erratas salvo que añadas coincidencia difusa
Coincidencia difusa (trigramas)	Postgres compara la similitud de secuencias de caracteres	Nombres, campos cortos, tolerancia a erratas	Requiere una extensión y un índice; ajustarla lleva trabajo
Motor de búsqueda alojado	Un servicio aparte indexa tus datos (Algolia, Meilisearch, Typesense, Elasticsearch y otros)	Catálogos grandes, búsqueda instantánea, gran 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 es un término medio muy sólido. Divide el texto en palabras, las reduce a sus raíces (así «running» coincide con «run»), ignora las palabras comunes y puede ordenar los resultados según lo bien que coincidan. Con el índice adecuado sigue siendo rápida en tablas grandes.

Prompts de ejemplo

Un comienzo 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 atrás funcione. Muestra un estado vacío amable cuando no haya coincidencias.

Pasar a 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 correcto, 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 pequeñas erratas sigan encontrando resultados. Usa 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 busca la gente. ¿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».
Pon 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 atrás funciona y los buscadores pueden rastrear páginas filtradas si quieres que lo hagan.
Aplica 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.
Mejora por etapas: texto completo, luego coincidencia difusa y después un motor alojado; solo cuando el paso más simple falle a usuarios reales.
Prueba con datos realistas: cientos o miles de filas, caracteres raros, consultas vacías, consultas muy largas, otros idiomas si los admites.

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 la entrada del usuario sin procesar. Usa siempre consultas parametrizadas. Un constructor de IA normalmente lo hace, pero comprueba si ves cadenas pegadas unas a otras.
Sin estado vacío. Un «sin resultados» con una sugerencia (quitar filtros, revisar la ortografía) evita que la gente se vaya.
Sin índices. La búsqueda parece bien con datos de prueba y se ralentiza a medida que 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 proteger otro conjunto de claves, a menudo sin ganancia visible.
Olvidar el móvil. Los filtros deben 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 pegada en SQL
El estado de la búsqueda vive en la URL
La escritura tiene 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 coincidencia de patrones y luego búsqueda de texto completo de Postgres cuando necesites ordenar por relevancia. Si quieres un motor de búsqueda alojado, trae tu propia cuenta y tu clave, guárdala como secreto del proyecto y pide 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 web 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, una ruta de servidor que filtre filas con una coincidencia sin distinguir mayúsculas en unas pocas columnas es el comienzo más fácil. Para una lista pequeña que ya está cargada en el navegador, filtrar en el navegador es todavía más simple.

¿Necesito Algolia o Elasticsearch para buscar?

Normalmente no al principio. La búsqueda de texto completo de Postgres maneja bien la coincidencia de palabras, el ranking y desde miles hasta millones de filas. Un motor de búsqueda alojado merece la pena cuando necesitas una gran tolerancia a erratas, resultados instantáneos al escribir sobre datos muy grandes o un ajuste avanzado de 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 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 cualquier cosa 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.