- LegiNote projektfejlesztési történet 1. – Ötlet
- A StatPan elindította a LegiNote projektet, melynek célja a parlamenti jogszabálytervezetek és jegyzőkönyvek hozzáférhetőségének növelése, valamint a mesterséges intelligencia felhasználásával történő jogalkotási hatékonyság javítása.
AI által fordított szöveg.
A bejegyzés durumis AI által generált összefoglalója
- A LegiNote projekt webes szolgáltatás fejlesztéséhez a Svelte, Rust, Go és Python nyelveket használja, és különösen a Go nyelven írt worker felelős az OpenAPI adatok gyűjtéséért és frissítéséért.
- A worker feladata az adatgyűjtési logika beállítása, végrehajtása és az adatbázisba való betöltése, célja pedig a különböző API adatokkal való skálázhatóság.
- A projekt a függőségek minimalizálása érdekében funkciók szerinti mappákba van rendezve, és a PostgreSQL, pq és sqlx eszközöket használja az adatbázis-kapcsolathoz és a lekérdezések feldolgozásához.
Üdvözlet, StatPan vagyok.
A LegiNote mellékprojekt fejlesztési naplóját írom.
Az előző részt a következő linken találhatod meg:
Alap architektúra
태양토끼님 협찬 Leginote 설계
A Leginote elsősorban webes szolgáltatásként való fejlesztését szem előtt tartva, a következő technológiai stacket fogja használni.
Frontend: Svelte
Backend: Rust (rupring-et erősen fontolgatjuk, de ez változhat)
Worker: Go (a kötelező függőségeken kívül a std könyvtár extrém használatára törekszünk)
Adatelemzés: Python (az előfeldolgozástól a későbbi mesterséges intelligencia beépítéséig)
A fenti stackben, a worker és az adatelemzési részre, amelyek a fő hozzájárulási területeim, fogok fókuszálni a fejlesztési napló sorozatban.
Kezdjük a workerrel.
Worker
A nyelv választása
golang logo
Pythonnal kezdtem programozni, és jelenleg az adattudomány területén dolgozom, így a Python nyelv a legkényelmesebb számomra. De mivel csak a szkripnyelveket ismertem, vágytam egy megbízható kompilált nyelvre is, így Go és Rust nyelvek felé fordultam.
Különösen a Rust nyelv érdekel a közelmúltban, és gyakran C++-szal és Golang-gal említik együtt. (Természetesen a C++ is kiváló nyelv, de a hálózatokkal kapcsolatos szolgáltatások fejlesztése során nem vesszük figyelembe. A jövőben sem valószínű, hogy közvetlenül használjuk, hacsak nem mélytanulási keretrendszerek belső működését nem kell kezelnünk.)
Tanulmányoztam a Rust és a Golang nyelveket, és kipróbáltam őket egyszerű hálózati kérésekben, így röviden megértettem a Rust és a Golang előnyeit és hátrányait. Ebben a cikkben nem szeretnék részletesen foglalkozni az előnyök és hátrányok összehasonlításával, mert túl hosszú lenne, hanem egy másik részben külön foglalkozunk majd ezzel. Röviden csak annyit mondanék, hogy
A hálózati területen további függőségek nélkül konfigurálható, és egy ismeretlen projekt esetén, ahol a bevétel bizonytalan,Golangnyelvet választottuk.
A worker szerepe
OpenAPI képernyő
A worker szerepe, hogy minden ciklusban adatokat gyűjtsön és frissítsen az OpenAPI webhelyről, és ezt három részre bonthatjuk:
1. Adott információk gyűjtési logikájának beállítása
2. A gyűjtési logika futtatásához szükséges futtató beállítása
3. A gyűjtött adatok betöltése az adatbázisba
A cél, hogy a fenti három lépésből álló folyamatot különböző API adatokra is alkalmazhassuk és kibővíthessük.
A projekt felépítése
A projekt felépítésére számos architektúra létezik, és a keretrendszerek használata lehetővé teszi, hogy a projekt elejétől fogva strukturáltan kezdjük a fejlesztést. De ahogy korábban említettem, célunk a függőségek minimalizálása, ezért a meghatározott logika megvalósításához közelíteni szeretnénk, és a funkciók szerint szeretnénk a mappákat szétválasztani.
A projekt a következőképpen fog felépülni:
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 - Az adatgyűjtés nyilvános adatok OpenAPI-ján keresztül történik. Ezért az OpenAPI-val való kommunikáció alapvető kódja az api mappába kerül. Jelenleg csak egy API-t használunk főként, ezért csak egy kliensfájlból áll.
db - Az adatbázissal való kommunikáció logikája itt van meghatározva. A connection fájl csak a kapcsolatért felelős, a repository pedig különböző upsert SQL-eket tartalmaz, amelyek végrehajtásának logikáját tartalmazza. Az SQL kódba írás túl bonyolult, ezért később külön fájlokban szeretnénk tárolni az SQL-eket.
util - A munkavégzés során a funkciók támogatásához szükséges különböző logikákat tartalmaz. Az error egy ideiglenes szkriptek, amelyek megkönnyítik a go által generált hibák kezelését. Később, a fejlesztési napló következő részeiben kiderül, hogy ez milyen jelentős hatással lesz a projektre (?)
A config fájl a .env fájl beolvasásakor nem használ külső csomagot, hanem egy saját függvényt definiál a .env fájl beolvasásához.
worker - Az api és db logikák megfelelő használatával hozza létre a kívánt műveleteket. Ez a fő logika. Ha később több worker típusra lesz szükség, akkor ezt a részt is bővíteni kell, de egyelőre csak egy fő worker művelet van benne.
A jövőben a rétegzett architektúra elvei alapján szeretnénk továbbfejleszteni a kódot.
A projekt függőségei
postgres használatához pq
lekérdezésekhez sqlx
Worker befejezés
Valószínűleg unalmas lenne csak elméletileg tárgyalni a dolgokat, és én is kicsit elfáradtam, ezért gyorsan befejezem ezt a részt.
Ez már a 2. rész vége. A 3. részben remélhetőleg már több kódot is be tudok mutatni, és részletesebben tudok beszélni a dolgokról.
Ha a Leginote fejlesztése során bármilyen funkcióra van szükségetek, vagy bármi kérdésetek van a fejlesztéssel kapcsolatban, nyugodtan írjatok kommentben!