- LegiNote Project Ontwikkelverhaal 1 - Idee
- StatPan is gestart met het LegiNote-project met als doel de toegankelijkheid van wetgevingsvoorstellen en vergaderverslagen van het parlement te vergroten en de wetgevingsefficiëntie te verbeteren met behulp van AI.
Dit is een door AI vertaalde tekst.
Samenvatting van de tekst door durumis AI
- Het LegiNote project gebruikt Svelte, Rust, Go en Python voor de ontwikkeling van de web service. De worker, ontwikkeld in Go, is verantwoordelijk voor het verzamelen en updaten van OpenAPI-gegevens.
- De worker voert functies uit zoals het instellen van de gegevensverzamellogica, uitvoering en het laden in de database. Het doel is om schaalbaarheid te bereiken voor verschillende API-gegevens.
- Om afhankelijkheden te minimaliseren, is het project gestructureerd met een aparte map voor elke functie. PostgreSQL, pq en sqlx worden gebruikt voor de databaseverbinding en queryverwerking.
Hallo, dit is StatPan.
Ik ben het ontwikkelproces van het LegiNote-zijproject aan het beschrijven.
Raadpleeg de volgende link voor het vorige deel.
Basisarchitectuur
Gesponsord door 태양토끼 (Taeyangtokki) Leginote Ontwerp
Leginote is voornamelijk ontworpen als een webdienst en zal de volgende technologie stack gebruiken.
Frontend: Svelte
Backend: Rust (rupring wordt serieus overwogen, maar dit kan veranderen)
Worker: Go (streef naar extreem gebruik van std, behalve voor essentiële afhankelijkheden)
Gegevensanalyse: Python (van voorverwerking tot toekomstige integratie van kunstmatige intelligentie)
Vanuit deze stack zal ik me voornamelijk richten op de Worker- en gegevensanalyse-secties, waar ik een belangrijke bijdrage lever. Ik zal deze secties in deze serie beschrijven.
Laten we eerst eens kijken naar de Worker.
Worker
Keuze van de programmeertaal
golang logo
Ik ben begonnen met programmeren in Python en aangezien mijn huidige werk zich richt op data science, ben ik het meest vertrouwd met Python. Maar doordat ik alleen scripts talen kende, kreeg ik de wens naar een betrouwbare gecompileerde taal, waardoor ik geïnteresseerd raakte in Go en Rust.
Vooral Rust was een taal die ik de afgelopen tijd met veel interesse heb gevolgd. Rust wordt vaak genoemd in combinatie met C++ en Golang. (Hoewel C++ ook een uitstekende taal is, heb ik het uitgesloten voor de ontwikkeling van dergelijke netwerkservices. Ik weet eerlijk gezegd niet zeker of ik het in de toekomst direct zal gebruiken, tenzij het gaat om het bewerken van de interne werking van deep learning frameworks.)
Door Rust en Golang te leren en ze te gebruiken voor eenvoudige netwerkverzoeken, heb ik een basisidee gekregen van de voor- en nadelen van beide talen. Omdat het te lang zou duren om de voor- en nadelen van beide in deze blogpost te bespreken, is het beter om dit in een ander deel te doen. In het kort:
Voor netwerkgerelateerde taken, zonder extra afhankelijkheden en voor een onbekend project met een onzeker toekomstige omzet, Golanggebruiken we als programmeertaal.
Rol van de Worker
OpenAPI Scherm
De Worker is verantwoordelijk voor het verzamelen en updaten van gegevens via de OpenAPI-site op regelmatige basis. Dit kan in drie stappen worden opgedeeld:
1. De ophaallogica instellen voor specifieke informatie.
2. De runner instellen die de ophaallogica uitvoert.
3. De opgehaalde gegevens opslaan in de database.
Het doel is om deze drie stappen te herhalen voor verschillende API-gegevens en zo de Worker uit te breiden.
Projectstructuur
Er zijn verschillende architecturen voor de projectstructuur en het gebruik van een framework kan ervoor zorgen dat het project vanaf het begin een gestructureerde vorm heeft. Zoals eerder vermeld, is het doel van dit project om het aantal afhankelijkheden te minimaliseren. Daarom heb ik ervoor gekozen om de mappen per functie te scheiden, zodat deze zo dicht mogelijk aansluiten bij de gedefinieerde logica.
Het project is als volgt gestructureerd:
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 - Het ophalen van gegevens gebeurt via de OpenAPI van openbare gegevens. Daarom komt de basiscode voor de communicatie met OpenAPI in de api-map terecht. Momenteel wordt er slechts één API gebruikt, dus de structuur bestaat uit slechts één client-bestand.
db - De logica voor de communicatie met de database is hier gedefinieerd. De code binnen connection is alleen verantwoordelijk voor de verbinding. In repository bevindt zich de logica voor het uitvoeren van diverse upsert SQL-opdrachten. Het direct opnemen van SQL-code in de code is echter te complex, dus ik ben van plan om SQL later in een afzonderlijk bestand op te slaan.
util - Verschillende hulpfactoren zijn hier gedefinieerd om de taken te ondersteunen. error is een tijdelijke script om de error-resultaten van Go gemakkelijk te verwerken. Zoals later in de ontwikkelblog zal blijken, is dit een grote oorzaak van het vlindereffect (?).
Het config-bestand bevat de functie die het .env-bestand inleest. We gebruiken geen afzonderlijk pakket voor het lezen van .env-bestanden.
worker - De belangrijkste logica voor het realiseren van de gewenste functionaliteit met behulp van de api- en db-logica is hier te vinden. Als er later meer soorten Workers komen, zal dit ook moeten toenemen. Momenteel bevat het alleen de logica voor één hoofdworker.
In de toekomst ben ik van plan om de code verder te ontwikkelen, waarbij ik de principes van de gelaagde architectuur in acht neem.
Project-afhankelijkheden
pq voor het gebruik van Postgres.
sqlx voor het gebruik van query's.
Worker afsluiting
Het is misschien niet zo leuk om alleen maar theorie te behandelen zonder code, en ik merk dat ik zelf ook een beetje afdwaal, dus ik maak het snel af.
Deel 2 is alweer voorbij. Hopelijk kan ik in deel 3 wat meer code laten zien en erover praten.
Tijdens de ontwikkeling van Leginote, aarzel niet om een reactie achter te laten als je denkt dat er een bepaalde functie nodig is of als je vragen hebt over de ontwikkeling!