De Scrapy a Apify: El Caso Real Que Me Hizo Repensar Cómo Construyo Scrapers en Producción
Hay un momento concreto en la vida de cualquier proyecto de scraping.
Empiezas con Scrapy o Playwright en local. Funciona. Lo subes a un servidor. Sigue funcionando. Luego necesitas escalar: más URLs, más frecuencia, más rotación de proxies, manejo de CAPTCHAs, almacenamiento estructurado, monitoring…
Y de repente lo que era un script de 200 líneas se convierte en infraestructura que tienes que mantener.
Eso es exactamente lo que le pasó a Daltix, una empresa de inteligencia de precios. Gestionaban sus propios servidores EC2, y cuando necesitaron escalar a volúmenes reales, la ecuación dejó de cuadrar. Migraron a Apify. Resultado: 90% de reducción en costes de EC2 y capacidad para procesar 5 millones de recursos al día.
Vamos a ver por qué, y cuándo tiene sentido para ti hacer ese mismo salto.
El problema real de Scrapy en producción
Scrapy no tiene ningún problema como framework. Es potente, flexible y tiene una comunidad enorme. El problema aparece cuando llegas a producción y tienes que resolver cosas que están fuera del scraping en sí:
- ¿Dónde guardo los datos? ¿Cómo exporto a 15 formatos distintos?
- ¿Cómo gestiono las colas de URLs cuando falla un nodo?
- ¿Quién monitoriza que el scraper no se ha muerto a las 3 de la mañana?
- ¿Cómo roto proxies residenciales sin que me baneen?
- ¿Cómo escalo sin provisionar más servidores a mano?
Estas preguntas no tienen respuesta en el propio Scrapy. Tienes que construirla tú. Y eso es tiempo de ingeniería que no va al producto.
Apify intenta responder todas esas preguntas desde el primer día.
Qué es Apify realmente
Apify es una plataforma de web scraping y automatización. Fue elegida la herramienta de web scraping #1 en Capterra en 2024 y tiene a clientes como Intercom o la propia Comisión Europea (que la usa para monitorizar precios de más de 42.000 productos en 720 retailers).
La unidad central de Apify es el Actor: un contenedor que encapsula un scraper con toda su lógica, configuración, input/output y lifecycle. Puedes verlo como una función serverless especializada en extracción de datos.
Lo interesante es que puedes:
- Usar Actors del Marketplace — más de 1.500 scrapers pre-construidos listos para usar sin escribir una línea de código. El Actor de Google Maps tiene más de 193.000 usuarios activos.
- Construir tu propio Actor — con el SDK de JavaScript o Python, usando la librería Crawlee por debajo.
Construyendo tu primer Actor con Crawlee
Crawlee es la librería open-source de Apify que unifica Playwright, Puppeteer y Cheerio bajo una sola API. Es lo que realmente diferencia la experiencia de desarrollo.
Lo que Crawlee resuelve automáticamente: gestión de la cola de requests, reintentos, concurrencia, y la integración con el storage de Apify.
La trinidad del storage en Apify
Uno de los puntos donde Apify realmente brilla frente a soluciones propias es el almacenamiento:
- Datasets — Para datos estructurados en filas (como una tabla de productos). Exportables a más de 15 formatos: JSON, CSV, Excel, XML…
- Key-Value Stores — Para estado, configuraciones, o capturas de pantalla. Funciona como un objeto clave-valor simple.
- Request Queues — La cola de URLs pendientes de scrape, persistente y distribuida. Si un nodo falla, la cola sobrevive.
Esta trinidad es lo que permite a Daltix procesar 5 millones de recursos diarios sin perder datos entre reinicios.
Proxies, anti-bot y el juego del gato y el ratón
En producción, el scraping técnico es solo el 50% del problema. El otro 50% es no ser bloqueado.
Apify tiene gestión de proxies integrada con dos modos principales:
- Datacenter proxies — Más rápidos y asequibles, pero más fáciles de detectar.
- Residential proxies — IPs de usuarios reales, mucho más difíciles de bloquear, pero con coste más elevado.
Para sitios con JavaScript heavy y detección activa de bots, Apify incluye Puppeteer Stealth y manejo de CAPTCHAs integrado. La librería Crawlee tiene fingerprinting realista activado por defecto.
La realidad es que ninguna solución es infalible. Es una carrera entre las técnicas de detección y las técnicas de evasión. Pero tener esto resuelto a nivel de plataforma te ahorra semanas de trabajo.
El elefante en la habitación: lo legal
Esto es crítico, especialmente en España y la Unión Europea.
La sentencia LinkedIn v. hiQ en Estados Unidos estableció que el scraping de datos públicos es generalmente legal. Pero en Europa tienes que cruzar eso con el GDPR.
Regla práctica:
- Datos públicos sin información personal → generalmente seguro
- Datos que incluyen nombres, emails, o identificadores personales → zona roja GDPR
- Violación de Terms of Service → riesgo legal real, aunque no siempre implica ilegalidad
La Comisión Europea usa Apify precisamente porque sus casos de uso son monitorización de precios de productos, no extracción de datos personales. Si tu caso de uso es similar (precios, inventario, contenido público), estás en territorio relativamente seguro. Si vas a extraer información personal, necesitas asesoramiento legal específico.
¿Cuándo NO usar Apify?
Seré directo: si tienes un scraper sencillo que rasca 500 páginas al mes para uso interno, Apify es excesivo. Un script de Python con Requests + BeautifulSoup en un cron job es suficiente.
Apify tiene sentido cuando:
- Necesitas escalar a volúmenes que harían que gestionar tu propia infraestructura sea inviable
- Tu equipo no quiere dedicar tiempo de ingeniería a mantener la capa de infraestructura
- Necesitas scheduling, monitoring y alertas sin construirlo todo desde cero
- Quieres usar uno de los 1.500+ Actors pre-construidos del Marketplace sin tocar código
El caso de Daltix es el ejemplo perfecto: el 90% de ahorro en EC2 no vino de que Apify sea más barato por página scrapeada. Vino de no tener que pagar ingenieros para mantener servidores.
Por dónde empezar
Dos rutas dependiendo de tu situación:
Si solo necesitas extraer datos sin código: Ve directamente al Marketplace, busca el Actor para tu caso (Google Maps, Amazon, LinkedIn público, etc.) y ejecútalo con los parámetros que necesitas. Apify tiene créditos gratuitos mensuales suficientes para probar sin compromiso.
Si necesitas un Actor personalizado: Empieza con Crawlee localmente:
Cuando estés listo para desplegarlo en Apify:
El workflow de deployment está integrado. En minutos tienes tu Actor corriendo en la nube con scheduling, storage y monitoring incluidos.
La conclusión que nadie suele mencionar
El scraping no es un problema de código. Es un problema de infraestructura.
Scrapy, Playwright, y cualquier otra librería resuelven la parte del código brillantemente. Lo que no resuelven es todo lo demás: dónde viven los datos, quién los monitoriza, cómo escalan, cómo sobreviven a los bloqueos.
En 2026, cuando el tiempo de desarrollo es más escaso que nunca, pagar por infraestructura gestionada en vez de construirla tú tiene mucho más sentido de lo que parece al principio.
Daltix lo aprendió escalando. Tú puedes aprenderlo antes.
¿Cuál es tu caso de uso de scraping? ¿Estás en la fase de script local o ya en la fase de infraestructura? Cuéntamelo en los comentarios.
