- LegiNote Projektentwicklungsgeschichte 1 - Die Idee
- StatPan hat das LegiNote-Projekt gestartet, um die Zugänglichkeit zu Gesetzesentwürfen und Protokollen des Parlaments zu erhöhen und die Effizienz der Gesetzgebung mithilfe von KI zu verbessern.
![translation](/_next/image?url=https%3A%2F%2Fcdn.durumis.com%2Fnb3qb%2F_next%2Fstatic%2Fmedia%2Ftrans.d6fac012.png&w=64&q=75)
Dies ist eine KI-übersetzte Version.
Zusammenfassung des Beitrags durch durumis AI
- Das LegiNote Projekt nutzt für die Entwicklung von Webservices Technologien wie Svelte, Rust, Go und Python. Insbesondere der in Go entwickelte Worker übernimmt die Aufgabe der OpenAPI-Datenerfassung und -aktualisierung.
- Der Worker führt Funktionen wie die Konfiguration der Datenakquisitionslogik, die Ausführung und die Datenübertragung in die Datenbank aus und zielt auf Skalierbarkeit in Bezug auf verschiedene API-Daten ab.
- Das Projekt ist funktionsbasiert in Ordner aufgeteilt, um die Abhängigkeiten zu minimieren. PostgreSQL, pq und sqlx werden verwendet, um die Datenbankverbindung und die Abfrageverarbeitung zu ermöglichen.
Hallo, ich bin StatPan.
Ich schreibe über die Entwicklung des LegiNote-Nebenprojekts.
Bitte beachten Sie den folgenden Link für den vorherigen Teil.
Grundlegende Architektur
Mit freundlicher Genehmigung von Tae Yang Tokki: Leginote-Design
Leginote soll zunächst als Webservice entwickelt werden und wird voraussichtlich den folgenden Technologie-Stack verwenden.
Frontend: Svelte
Backend: Rust (rupring wird stark in Betracht gezogen, kann sich aber ändern)
Worker: Go (Streben nach extremer Verwendung von std, mit Ausnahme der notwendigen Abhängigkeiten)
Datenanalyse: Python (von der Vorverarbeitung bis hin zur späteren Integration von künstlicher Intelligenz)
Innerhalb dieses Stacks werde ich mich in dieser Blogserie hauptsächlich auf die Entwicklung der Worker- und Datenanalyse-Komponenten konzentrieren, da dies meine Schwerpunkbereiche sind.
Lassen Sie uns zunächst über die Worker sprechen.
Worker
Sprachwahl
Golang Logo
Ich habe mit Python programmiert und bin aufgrund meiner aktuellen Tätigkeit im Bereich Data Science mit dieser Sprache am vertrautesten. Da ich aber nur Skriptsprachen kannte, entwickelte ich den Wunsch nach einer stabilen kompilierten Sprache, was mich dazu brachte, mich für Go und Rust zu interessieren.
Besonders Rust hat mich in letzter Zeit sehr interessiert, und oft werden C++ und Golang in Verbindung mit Rust erwähnt. (C++ ist natürlich auch eine großartige Sprache, aber ich habe sie für die Entwicklung solcher Netzwerkdienste ausgeschlossen. Ich weiß nicht, ob ich sie in Zukunft direkt verwenden werde, es sei denn, es geht um die Entwicklung von Deep-Learning-Frameworks.)
Durch das Erlernen von Rust und Golang und das Experimentieren mit einfachen Netzwerk-Anfragen habe ich die Vor- und Nachteile von Rust und Golang grob verstanden. Eine detailliertere Diskussion der Vor- und Nachteile in diesem Beitrag würde den Rahmen sprengen, daher werde ich sie in einem separaten Beitrag behandeln. Kurz gesagt,
habe ich mich aufgrund der Möglichkeit, die Anwendung ohne zusätzliche Abhängigkeiten im Netzwerkbereich zu konfigurieren und ein unbekanntes Projekt durchzuführen, für das der Erfolg ungewiss ist, fürGolangentschieden.
Rolle des Workers
OpenAPI-Bildschirm
Die Aufgabe des Workers besteht darin, Daten periodisch über die OpenAPI-Website zu sammeln und zu aktualisieren. Dies kann in drei Schritte unterteilt werden:
1. Konfiguration der Sammellogik für bestimmte Informationen
2. Konfiguration des Runners zur Ausführung der Sammellogik
3. Speichern der gesammelten Daten in der Datenbank
Das Ziel ist es, diese drei Schritte für verschiedene API-Daten gleich anzuwenden und zu erweitern.
Projektstruktur
Es gibt verschiedene Architekturen für die Projektstruktur, insbesondere die Verwendung von Frameworks kann dazu beitragen, dass das Projekt von Anfang an eine strukturierte Form erhält. Wie bereits erwähnt, zielt dieses Projekt jedoch darauf ab, die Abhängigkeiten zu minimieren, daher wollte ich die Ordner entsprechend der implementierten Logik und den einzelnen Funktionen aufteilen.
Das Projekt ist wie folgt aufgebaut:
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 - Die Datenerfassung erfolgt über die öffentliche Daten-OpenAPI. Daher wird der grundlegende Code für die Kommunikation mit OpenAPI im api-Ordner abgelegt. Derzeit wird nur eine API als Haupt-API verwendet, daher besteht sie nur aus einer Client-Datei.
db - Die Logik für die Kommunikation mit der Datenbank ist definiert. Der Code innerhalb von connection ist nur für die Verbindung zuständig, während repository verschiedene Upsert-SQL-Anweisungen enthält und deren Ausführungslogik definiert. Die SQL-Anweisungen selbst sind im Code enthalten, was zu komplex werden kann, daher werde ich die SQL-Anweisungen später in eine separate Datei auslagern.
util - Hier sind verschiedene unterstützende Logiken definiert, die während der Arbeit verwendet werden. error ist ein temporäres Skript, das erstellt wurde, um die Fehlerergebnisse, die in Go ausgegeben werden, einfacher zu verarbeiten. Wie in späteren Teilen dieser Blogserie erläutert, wird dies zu einer enormen Kettenreaktion führen (?).
Die Konfigurationsdatei enthält eine selbstdefinierte Funktion zum Lesen der .env-Datei, da keine separaten Pakete zum Lesen der .env-Datei verwendet werden.
worker - Hier befindet sich die Hauptlogik, die die api- und db-Logik sinnvoll nutzt, um die gewünschte Funktionalität zu erstellen. Wenn die Anzahl der Worker später zunimmt, muss dies entsprechend angepasst werden. Derzeit enthält sie jedoch nur die Logik für einen einzigen Haupt-Worker.
In Zukunft plane ich, den Code unter Einhaltung der Prinzipien der Layered Architecture weiterzuentwickeln.
Projektabhängigkeiten
pq zur Verwendung von Postgres
sqlx zur Verwendung von Abfragen
Abschluss der Worker-Diskussion
Nur Theorien aufzulisten, ohne Code zu zeigen, ist irgendwie langweilig, und ich merke, dass ich auch etwas ins Stocken geraten bin, daher werde ich jetzt etwas schneller zum Ende kommen.
Teil 2 ist schon abgeschlossen. Ich hoffe, dass ich ab Teil 3 mehr Code einfügen und darüber sprechen kann.
Wenn Sie während der Entwicklung von Leginote Funktionen benötigen, die Ihrer Meinung nach notwendig sind, oder wenn Sie Fragen zur Entwicklung haben, können Sie jederzeit einen Kommentar hinterlassen!