LegiNote projektfejlesztési történet 2. rész - Tech stack és worker

Ü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:

1. rész

Alap architektúra

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

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

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!