- LegiNote Projesi Geliştirme Hikayesi 1 - Fikir
- StatPan, LegiNote projesine, Türkiye Büyük Millet Meclisi'ndeki yasa tasarılarına ve tutanaklarına erişimi artırmayı ve yapay zekayı kullanarak yasama verimliliğini artırmayı hedefleyerek başladı.
AI tarafından çevrilmiş metin.
statpan
LegiNote Projesi Geliştirme Hikayesi 2 - Teknoloji Yığını ve Worker
- Yazım Dili: Korece
- Referans Ülke: Tüm Ülkeler
durumis AI tarafından özetlenen yazı
- LegiNote projesi, web hizmeti geliştirmek için Svelte, Rust, Go, Python gibi dilleri kullanıyor ve özellikle Go ile geliştirilen worker, OpenAPI verilerini toplama ve güncelleme görevini üstleniyor.
- Worker, veri toplama mantığı ayarlama, yürütme, DB'ye yükleme gibi işlevleri yerine getirir ve çeşitli API verilerine yönelik genişletilebilirliği hedefler.
- Proje, bağımlılıkları en aza indirmek için işlevlere göre klasör ayrımıyla yapılandırılır ve PostgreSQL, pq, sqlx gibi araçlar kullanılarak veritabanı bağlantısı ve sorgu işleme gerçekleştirilir.
Merhaba, StatPan burada.
LegiNote yan proje geliştirme sürecini yazıyorum.
Önceki bölümü aşağıdaki bağlantıdan inceleyebilirsiniz.
Temel Mimari
Tae Yang Tokki'nin (태양토끼) katkılarıyla Leginote tasarımı
Leginote, öncelikli olarak bir web hizmeti olarak geliştirileceğini göz önünde bulundurarak aşağıdaki teknoloji yığınını kullanmayı planlıyor.
Ön uç: Svelte
Arka uç: Rust (rupring'i çok dikkate alıyoruz, ancak değişebilir)
Çalışan: Go (zorunlu bağımlılıklar dışında, aşırı std kullanımı hedefleniyor)
Veri Analizi: Python (ön işleme, daha sonra yapay zeka entegrasyonu)
Yukarıdaki yığında, benim ağırlıklı olarak katkıda bulunduğum alan olan çalışan ve veri analizi bölümlerine odaklanarak geliştirme sürecini yayınlamayı planlıyorum.
Öncelikle çalışan hakkında konuşalım.
Çalışan
Dil Seçimi
golang logosu
Python ile programlamaya başladım ve şu anda temel işim veri bilimi alanında olduğu için Python dili bana en tanıdık gelen dildir. Ancak yalnızca betik dillerini bilen ben, sağlam bir derlenmiş dile olan isteğimi geliştirerek Go ve Rust dillerine ilgi duymaya başladım.
Özellikle son zamanlarda en çok ilgi duyduğum dil Rust'tı ve Rust, genellikle C++ ve Golang ile birlikte anılıyordu. (Elbette C++ da mükemmel bir dildir, ancak bu tür ağ tabanlı hizmet geliştirmelerinde hariç tuttum. Gelecekte de derin öğrenme çerçevesinin içini ele almak yerine doğrudan ele alıp almayacağım konusunda emin değilim.)
Bu şekilde Rust ve Golang'ı öğrendim ve basit ağ isteklerinde kullanarak Rust'ın güçlü ve zayıf yönlerini ve Golang'ın güçlü ve zayıf yönlerini kısaca belirledim. Bu yazıda ikisinin güçlü ve zayıf yönlerini karşılaştırmak yazıya uzunluk katacaktır, bu nedenle ayrı bir bölümde ayrıntılı bir şekilde ele almak daha uygun olur gibi görünüyor. Kısaca bahsetmek gerekirse,
Ağ alanında ek bağımlılık olmadan yapılandırılabilir ve gelirin olup olmayacağı belli olmayan bilinmeyen bir proje yürütmek içinGolangkullanmaya karar verdim.
Çalışan Rolü
OpenAPI ekranı
Çalışanın rolü, her döngüde OpenAPI sitesi aracılığıyla verileri toplamak ve güncellemektir ve aşağıdaki üç kategoriye ayrılabilir.
1. Belirli bilgiler için toplama mantığı ayarlama
2. Toplama mantığını çalıştıran bir yürütücü ayarlama
3. Toplanan verileri DB'ye yükleme
Yukarıdaki üç adımı çeşitli API verileri için aynı şekilde uygulayarak genişletmek hedeftir.
Proje Yapılandırma Yöntemi
Bir projenin yapılandırılması için çeşitli mimariler mevcuttur ve özellikle bir çerçeve kullanılırsa, proje başlangıcından itibaren yapılandırılmış bir şekilde başlatılabilir. Ancak, yukarıda belirtildiği gibi, bu projede bağımlılıkları en aza indirerek geliştirmeyi hedeflediğimiz için, yukarıda tanımlanan mantığın uygulanmasına ve her işlev için klasör ayırmaya yakın bir şekilde ilerlemek istedik.
Proje aşağıdaki gibi yapılandırılmıştır.
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 - Veri toplama, kamu verileri OpenAPI aracılığıyla gerçekleştirilir. Bu nedenle, OpenAPI ile iletişim kuran temel kod, api klasörünün altına yerleştirilir. Şu anda yalnızca bir API ana olarak kullanıldığı için yalnızca bir istemci dosyasıyla yapılandırılmıştır.
db - DB ile iletişim kuran mantık burada tanımlanmıştır. connection içindeki kod yalnızca bağlantıyı ele alır ve repository, çeşitli upsert SQL'lerini içerir ve bunları çalıştırır. SQL'in kodda olması yine de çok karmaşık olur, bu nedenle SQL'i daha sonra ayrı bir dosyaya taşımayı planlıyorum.
util - Çalışma sırasında işlevleri destekleyen çeşitli mantıkların tanımlandığı yerdir. error, Go'dan gelen hata sonuçlarını kolayca işlemek için geçici olarak oluşturulmuş bir komut dosyasıdır. Daha sonraki geliştirme hikayelerinde görüleceği gibi, bunun inanılmaz bir kelebek etkisi kaynağı olduğu ortaya çıkıyor (?)
config dosyası, .env dosyasını okurken ayrı bir paket kullanmamak için .env dosyasını okuyan işlevi doğrudan tanımladığım dosyadır.
worker - api ve db mantığını uygun şekilde kullanarak istenen işlemi oluşturan önüm işlevselliğin yer aldığı yerdir. Daha sonra çalışan türleri artarsa, benzer şekilde artması gerekecek gibi görünüyor, ancak şu anda yalnızca bir ana çalışan işlemi içeriyor.
Gelecekte, katmanlı mimari ilkesinin korunmasıyla birlikte kodu geliştirmeyi planlıyorum.
Proje Bağımlılıkları
Postgres kullanımı için pq
Sorgu kullanımı için sqlx
Çalışan Sonu
Kod olmadan yalnızca teoriyi sıralamak biraz sıkıcı olabilir ve ben de biraz uzadığımı hissediyorum, bu nedenle biraz hızlıca sonlandırıyorum.
2. Bölüm zaten bitti. 3. Bölümden itibaren en azından bir satır kod ekleyerek konuşmayı sürdürmek istiyorum.
Legino geliştirme sürecinde, gerekli olduğunu düşündüğünüz bir özellik varsa veya geliştirmeyle ilgili herhangi bir sorunuz varsa, lütfen yorumlarda belirtin!
