- Historia del desarrollo del proyecto LegiNote 1 - Idea
- StatPan ha iniciado el proyecto LegiNote con el objetivo de mejorar la accesibilidad a los proyectos de ley y actas del parlamento, y aumentar la eficiencia legislativa utilizando la IA.
Texto traducido por IA.
Resumen de la publicación por la IA de durumis
- El proyecto LegiNote utiliza Svelte, Rust, Go y Python para el desarrollo del servicio web, y el Worker desarrollado en Go es responsable de la recopilación y actualización de datos de OpenAPI.
- El Worker realiza funciones como la configuración de la lógica de recopilación de datos, la ejecución y la carga en la base de datos, con el objetivo de lograr la escalabilidad para diversos datos de API.
- El proyecto se estructura mediante la separación de carpetas por función para minimizar las dependencias, y utiliza PostgreSQL, pq y sqlx para la conexión y el procesamiento de consultas de la base de datos.
Hola, soy StatPan.
Estoy escribiendo sobre el desarrollo del proyecto paralelo LegiNote.
Para la parte anterior, consulte el siguiente enlace.
Arquitectura básica
Diseño de Leginote cortesía de 태양토끼님
Leginote se desarrollará principalmente como un servicio web y planea utilizar la siguiente pila de tecnologías.
Frontend: Svelte
Backend: Rust (se está considerando seriamente rupring, pero puede cambiar)
Worker: Go (buscando el uso extremo de std, excluyendo las dependencias esenciales)
Análisis de datos: Python (desde el preprocesamiento hasta la posterior integración de la inteligencia artificial)
Dentro de esta pila, planeo publicar una serie de artículos sobre el desarrollo, centrándome en las áreas de Worker y análisis de datos, las cuales son las que contribuyo principalmente.
Empecemos con la historia de Worker.
Worker
Selección del lenguaje
logo de golang
Comencé a programar con Python y, dado que mi trabajo principal se centra en el campo de la ciencia de datos, estoy más familiarizado con este lenguaje. Sin embargo, al solo conocer lenguajes de script, desarrollé el deseo de un lenguaje compilado sólido y comencé a interesarme en Go y Rust.
En particular, Rust era el lenguaje que más me interesaba últimamente, y a menudo se menciona junto con C++ y Golang. (Si bien C++ también es un lenguaje excelente, lo excluí del desarrollo de este tipo de servicios de red. Todavía no estoy seguro de si lo usaré directamente en el futuro, a menos que tenga que manejar el interior de un framework de aprendizaje profundo).
Aprendí Rust y Golang, los utilicé para solicitudes de red simples y comprendí brevemente sus ventajas y desventajas. Sería demasiado extenso analizar sus pros y contras en este artículo, por lo que creo que sería mejor resumirlos en otro artículo. En resumen,
Para un proyecto desconocido en el que no sabemos si habrá ingresos, y que puede configurarse sin dependencias adicionales en el campo de la red,Golanges el lenguaje que hemos decidido utilizar.
Función del Worker
Pantalla de OpenAPI
La función del Worker es recopilar y actualizar datos a través del sitio web OpenAPI cada cierto tiempo, y se puede dividir en tres partes:
1. Configurar la lógica de recopilación para información específica
2. Configurar el ejecutor que ejecuta la lógica de recopilación
3. Cargar los datos recopilados en la base de datos
El objetivo es aplicar y ampliar el mismo procedimiento de estas tres partes a una variedad de datos de API.
Plan de estructura del proyecto
Existen diversas arquitecturas para la estructura de un proyecto, y el uso de un framework permite comenzar el proyecto con una estructura definida desde el principio. Sin embargo, como se mencionó anteriormente, el objetivo de este proyecto es minimizar las dependencias durante el desarrollo, por lo que queríamos separar las carpetas por función para que fueran lo más parecidas posible a la lógica definida anteriormente.
El proyecto se estructurará de la siguiente manera:
leginote-worker-bill/
├── main.go
├── api/
│ └── client.go
├── db/
│ ├── connection.go
│ └── repository.go
├── util/
│ ├── error.go
│ └── runner.go
│ └── config.go
├── worker/
│ └── worker.go
├── go.mod
└── go.sum
api: la recopilación de datos se realiza a través de OpenAPI de datos públicos. Por lo tanto, el código básico para la comunicación con OpenAPI se incluirá en la carpeta api. Actualmente, solo se utiliza una API principal, por lo que solo hay un archivo de cliente.
db: la lógica para la comunicación con la base de datos está definida aquí. El código dentro de connection solo se encarga de la conexión, y repository contiene la lógica para ejecutar varias sentencias SQL upsert. Realmente, tener el código SQL dentro del código es demasiado complejo, así que planeo crear un archivo separado para el SQL más adelante.
util: aquí se define una variedad de lógica auxiliar para las tareas. error es un script temporal creado para manejar los resultados de error de Go de manera conveniente. Como se verá en las historias de desarrollo posteriores, esto causará un gran efecto mariposa (?).
El archivo config define una función para leer archivos .env directamente, en lugar de usar un paquete separado para leer el archivo .env.
worker: contiene la lógica principal que utiliza la lógica de api y db para producir el comportamiento deseado. Si el número de workers aumenta en el futuro, también debería aumentar, pero por ahora solo contiene la operación de un worker principal.
En el futuro, planeamos seguir desarrollando el código manteniendo los principios de la arquitectura en capas.
Dependencias del proyecto
pq para el uso de Postgres
sqlx para el uso de consultas
Finalización del Worker
Creo que enumerar solo la teoría sin código podría ser aburrido, y me siento un poco lento, así que creo que voy a terminar esto un poco rápido.
¡La parte 2 ya ha terminado! Espero poder incluir más código en las siguientes partes y hablar de ello.
¡Durante el desarrollo de LegiNote, si hay alguna función que crea que es necesaria o si tiene alguna pregunta sobre el desarrollo, no dude en dejar un comentario!