Elegir un proyecto de crawler de código abierto es más sencillo si se separan cuatro funciones: crawling general, automatización del navegador, planificación y colas, y análisis y almacenamiento. Aquí se explican sus tareas, fallos comunes al integrarlas y cuatro criterios verificables.
Buscar crawlers en GitHub puede sacar a la luz cientos o miles de repositorios. Mucha gente elige mirando el número de estrellas y empieza por el proyecto más popular.
La popularidad y la adecuación a tu caso son cosas distintas. Por conocido que sea un proyecto, si su enfoque no encaja con tu escenario acabará dando más trabajo. Un punto de partida más sencillo es separar responsabilidades: un sistema de recopilación capaz de funcionar durante mucho tiempo suele estar formado por varios componentes con tareas diferentes. Entender qué hace cada pieza reduce mucho la dificultad de comparar implementaciones concretas.
Frameworks de crawling general: para páginas con estructura estable
Estos frameworks gestionan la planificación de solicitudes, la captura concurrente y las canalizaciones de datos. Reciben lotes de URL y producen resultados estructurados. Sus ecosistemas maduros y mecanismos de middleware permiten insertar lógica propia y sostener trabajos de gran escala durante largos periodos.
No pueden resolver por sí solos páginas cuyo contenido aparece únicamente después de ejecutar JavaScript. En esos casos solo reciben una carcasa vacía y hace falta añadir un motor de renderizado. Son adecuados para objetivos estables como páginas de listado, páginas de detalle y APIs abiertas.
Automatización del navegador: para renderizado e interacción
Las páginas que requieren renderizado real, una sesión iniciada o varios clics antes de mostrar contenido deben delegarse en automatización del navegador. Estas herramientas pueden trabajar con distintos motores, cuentan con mecanismos de espera maduros y permiten controlar directamente las solicitudes y respuestas de la página.
El coste es un consumo de recursos mucho mayor que con solicitudes HTTP simples. El límite de concurrencia depende en gran medida de la memoria y la CPU locales. Además, la automatización deja señales detectables y los sitios con controles estrictos pueden reconocerla.
Planificación y colas: necesarias cuando crece el número de tareas
Con pocos objetivos, un bucle puede ser suficiente. Cuando hay miles de tareas y además se necesita controlar frecuencia y reintentos, conviene una capa de planificación independiente: cómo se encolan las tareas, cuánta concurrencia se permite, cuánto esperar antes de reintentar un fallo y qué tareas deben abandonarse. Meter toda esta lógica en el framework de crawling termina complicando el código.
Un error frecuente al montar esta capa es usar una cola solo en memoria del proceso. Si el proceso se reinicia, desaparecen todas las tareas pendientes. Como mínimo, la cola debe ser persistente y permitir consultar el estado.
Análisis y almacenamiento: determinan si los datos se pueden usar directamente
Lo que se descarga es HTML; lo que se necesita son campos. La capa de análisis debe gestionar reglas de extracción, validar campos, eliminar duplicados y guardar los datos. Para sitios que cambian de estructura con frecuencia, puede ser útil una extracción adaptativa que localice los datos mediante características de la página en lugar de selectores rígidos, reduciendo así el mantenimiento.
En almacenamiento, hay que cuidar la idempotencia. Los reintentos son normales, por lo que las escrituras deben deduplicarse mediante un identificador único; de lo contrario, los datos repetidos contaminarán los análisis posteriores.
Problemas habituales al unir las piezas
Cada componente por separado no es especialmente complejo. Los problemas suelen aparecer en las uniones.
- La capa de planificación reintenta, pero la capa de análisis no deduplica y aparecen filas repetidas
- La capa del navegador no tiene límite de concurrencia, agota los recursos locales y hace fallar todo el lote
- Las reglas de análisis están codificadas de forma rígida y cualquier cambio del sitio exige una nueva versión
- Los componentes usan identificadores distintos para una misma tarea, los estados no coinciden y no es posible reanudar desde un punto de control
Cuatro criterios de evaluación
Una vez decidida la categoría necesaria, usa estos cuatro criterios para filtrar proyectos concretos.
Para la actividad de mantenimiento, mira la frecuencia de commits y la velocidad de respuesta a issues durante los últimos meses, no el total de estrellas. Un proyecto sin mantenimiento puede dejar de funcionar en cuanto cambie el sitio objetivo.
La documentación y los ejemplos determinan el coste de aprendizaje. Si la documentación es ambigua o solo muestra los casos más simples, el tiempo necesario suele superar lo previsto.
Para la extensibilidad, comprueba qué puntos de integración ofrece: si permite cambiar el proxy, conectar tu propio motor de renderizado o sustituir el almacenamiento. Con buenas extensiones, las adaptaciones posteriores no requieren tocar el código fuente.
La licencia y los riesgos de cumplimiento suelen pasarse por alto. Antes de un uso comercial, confirma el tipo de licencia y evita las que sean incompatibles con tu uso. También deben evaluarse el alcance de la recopilación, la frecuencia de solicitudes y las condiciones del sitio objetivo; estas cuestiones son independientes de la calidad técnica del framework.
La capa de entorno es otro nivel
El framework resuelve cómo recopilar datos, no los problemas de identidad y escala. Si las tareas requieren inicio de sesión, separación por región o varias cuentas en paralelo, ejecutar todo en un mismo entorno de navegador crea dos problemas: las sesiones se contaminan porque cookies y almacenamiento local se solapan, y el sitio objetivo puede interpretar tareas no relacionadas como el mismo grupo de visitas.
Una práctica madura consiste en tratar los entornos de navegador como una capa de recursos independiente. Las tareas solicitan un entorno de un grupo y lo liberan al terminar. En este tipo de arquitectura, PurpleMark ocupa esa capa y proporciona recursos de entorno que pueden crearse por lotes, vincularse a salidas de red independientes y consultarse por estado.
Límites de cumplimiento
Respeta las reglas de robots y los términos de servicio del sitio objetivo, no recopiles información personal, no eludas medidas técnicas de protección y controla la frecuencia de solicitudes para no afectar al funcionamiento normal del servicio. La selección del proyecto resuelve una cuestión de eficiencia; estas decisiones determinan si la recopilación debe realizarse.
