LegiNote Projektentwicklungsgeschichte 2 - Technologie-Stack und Worker

Hallo, ich bin StatPan.

Ich schreibe über die Entwicklung des LegiNote-Nebenprojekts.

Bitte beachten Sie den folgenden Link für den vorherigen Teil.

Teil 1

Grundlegende Architektur

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

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

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!