Proyecto de APIs abiertas (egov)

A veces me da algo de pena que se tiren tantos millones de dinero de impuestos en desarrollar sistemas cerrados y generar datos inaccesibles. Es por eso que llevo un tiempo trabajando en un proyecto que me gustaría presentaros casi en primicia.

El proyecto se llama “egov” a falta de un nombre mejor. Consiste en hacer APIs abiertas para poder consultar datos que ahora sólo están disponibles en páginas web, documentos en formatos de todo tipo, etc. He hecho un pequeño portal público para intentar explicarlo para humanos aunque no sé si lo habré conseguido. Si se os ocurre un buen nombre de dominio lo puedo pillar.

El código y la info más técnica está en un repo de github palmerabollo/egov con algunos ejemplos. Es un API GraphQL para consultar por ahora unas pocas cosas como códigos postales, antenas de telefonía, etc. haciendo scraping de recursos web. Se agradecen ideas y contribuciones.

También hay una demo que consulta datos reales que he montado en Heroku, si queréis cacharrear. Por ejemplo esta sería una consulta sencilla para saber dónde está un código postal.

Lo dicho, animaos a colaborar y a difundirlo un poco por ahí si os gusta la idea, porque no lo voy a poder mantener yo solo.

Me encanta el portal público que has hecho, me parece fundamental para que la gente no técnica entienda de qué va.

Por lo que entiendo el api de egov lo que hace es de puente entre el usuario (o una app/web que consulte) y un “provider” que es el que realmente extrae los datos de donde sea, que supongo que en muchos casos será un scrapper de datos de alguna web o servicio.

Algunas preguntas,

• ¿Todos los providers tienen que estar programados en node?
• ¿Tienes pensando crear una librería para facilitar las tareas de scrapping que muchas veces son muy repetitivas para que no haya que reescribir mucho código para cada provider?
• ¿Alguna estrategia para detectar cuando un provider está roto porque cambiaron el formato de la fuente original?

Un saludo y ¡enhorabuena por la iniciativa!

Edit: Me olvidaba, quizá pueda ser interesante una sección donde la gente puede informar (y votar) de información que está disponible pero que no se puede consumir de forma sencilla, como listado de deseos para la gente que quiera crear providers.

Por ahora sí. En el API GraphQL las distintas partes del árbol se van componiendo con distintos “resolvers” (es el nombre que se usa en terminología GraphQL) y no vi forma, al menos con la librería que uso (apollo-server). No soy para nada experto en GraphQL, igual alguien que sepa más que yo sabe cómo se podría hacer.

Sí, esto sí que está en el TODO del repo. No sé si hacer una librería o reutilizar alguna que haya por ahí opensource. En un mundo ideal se podría hacer hasta con algún tipo de asistente visual sobre la propia página que estás procesando. Probablemente haya también cosas hechas.

Lo que tenía pensado es incluir tests que se estén ejecutando continuamente con distintas aserciones. Desde pruebas básicas (que la página cargue) hasta cosas más avanzadas como que existan determinados elementos o que el contenido sea semánticamente correcto.

Sí, por ahora están en las issues de github con el label “ideas-providers”, pero para personas no técnicas puede ser un poco complicado todavía. Le doy una vuelta.

Gracias por las ideas.

Sí, esto sería ideal. Imagino algo que un usuario pueda ver la página donde está el contenido y hacer clic en los elementos que se deberían extraer, eso generaría un código que luego alguien técnico podría revisar antes de incorporar.

A lo mejor hay alguna integración de github issues que permite mostrarlas en el portal y que la gente vote (algo tipo user voice), tendrían que iniciar sesión con github pero bueno, en algún sistema tendrían que hacerlo al fin y al cabo.

En la página del catálogo de datasets he incluido la lista de datos disponibles y las ideas propuestas. Las ideas las consulta directamente con el API de github. Aún no se pueden votar, pero es un primer paso.

He estado haciendo una prueba de concepto con los radares de tráfico de la DGT, para extraer la información con Python. La idea es que corre en un proceso independiente (lo llamo “adaptador”) que hace el scraping de los datos, los transforma y los expone ya cocinados por HTTP. De esta forma el “provider” principal sólo hace una petición HTTP al adaptador:

consulta ––[http]–> data-provider ––[http]–> adaptador python --> datos públicos

La verdad es que funciona bastante bien y abre la puerta a hacer scrapers en cualquier lenguaje popular (la verdad es que Python para esto es super cómodo). He aprovechado para colgar una demo de este caso en la seccion de ejemplos del portal (en móvil no va fino aún).

El adaptador lo despliego como una “función serverless” con https://serverless.com/ para no necesitar pedir donativos todavía.

Aunque es otro tema, sería super chula una extensión del navegador que te permitiese ceder tiempos en los que no lo estás utilizando para ejecutar en una especie de sandbox pequeñas tareas de scraping de este tipo. Una especie de red distribuida de procesamiento para no depender del AWS de turno. Aunque no tengo claro qué incentivos habría.

Ya me callo