Desacoplar los scraper de la build del sitio

[AngelGuerra]

Ahora mismo el build es el que se encarga de hacer el scraping y formar la web. Molaría que el scraper se haga en algún otro momento, genere algún tipo de archivo (json, toml, yaml...) y que el build tire de ese archivo, con ello se conseguiría:

• Histórico de noticias (o cualquier otra cosa que haga scraping)
• Menos consumo en Netlify por tanto, más margen para aumentar los deploys

[ardillan]

Sería genial poder hacer eso. ¿Alguna idea de con qué herramienta se puede realizar?

Hace unos días estuve probando oclif, no sé si podría ser un buen candidato para desacoplar el scraper de la web, ¿qué opinas?

[AngelGuerra]

Uoh, qué agradable coincidencia, yo también estuve trasteando con oclif hace nada.

Al margen de la herramienta de programación, lo que hay que pensar más es en la comunicación entre el scraper y el build de Gatsby.

Quizá mezclando las GitHub actions con llamadas específicas para hacer el build de Netlify (webhooks?), hay que pensarlo.

[AngelGuerra]

Leyendo un poco me ha dado una idea más o menos formada, pero habría que probarlo:

El scraper se mete en un repo propio y con GitHub Actions, se genera un archivo Json (yaml, toml...) y se hace push con el Json generado (quizá a un nuevo repo llamado torlavegadata) en el que se empujarán todos los archivos con los data estáticos.

Este repo torlavegadata puede ser un paquete de node o un submódulo de GIT que se incluirá en el package del GatsbyJS (o si es submódulo se clona).

Con esto, al hacer npm i se traerán los datos estáticos.

En este artículo explica parte de lo que he comentado.

Quedaría lanzar la CI de GitHub de manera programada sin hacer push (webhooks?) y que no haya que lanzarlo a mano.