История разработки проекта LegiNote 2 - стек технологий и воркеры

Здравствуйте, это StatPan.

Я пишу о разработке сайд-проекта LegiNote.

Предыдущую часть можно найти по следующей ссылке.

Часть 1

Базовая архитектура

Leginote разрабатывается как веб-сервис, и планируется использовать следующий стек технологий.

Фронтенд: Svelte

Бэкенд: Rust (серьёзно рассматривается rupring, но может измениться)

Воркер: Go (стремление к использованию только стандартной библиотеки, за исключением необходимых зависимостей)

Анализ данных: Python (от предварительной обработки до последующей интеграции искусственного интеллекта)

Из этого стека, я планирую сосредоточиться на разработке воркера и анализа данных, которые являются моими основными областями вклада, и публиковать записи о разработке.

Начнем с обсуждения воркера.

Воркер

Выбор языка

Я начал программировать на Python, и поскольку моя текущая основная работа связана с областью Data Science, язык Python мне наиболее знаком. Однако, зная только скриптовые языки, у меня появилось желание освоить надёжные компилируемые языки, поэтому я заинтересовался Go и Rust.

В последнее время язык, за которым я особенно следил, был Rust. Когда Rust упоминается, обычно рядом с ним стоят C++ и Golang. (Конечно, C++ — отличный язык, но в разработке подобных сетевых сервисов я его не рассматривал. В будущем, если дело не дойдет до работы с внутренностями фреймворков глубокого обучения, я не уверен, буду ли я его использовать напрямую.)

Изучив Rust и Golang, а также попробовав их в действии для простых сетевых запросов, я кратко определил их сильные и слабые стороны. Подробно разбирать их плюсы и минусы в этой статье не буду, так как это растянет текст. Лучше будет посвятить этому отдельную статью. Если коротко, то…

В области сетевых технологий, для конфигурации без дополнительных зависимостей и для проекта с неопределённым будущим, в котором неясно, будет ли он приносить прибыль,Golangбыл выбран в качестве языка разработки.

Роль воркера

Роль воркера заключается в периодическом сборе и обновлении данных через сайт OpenAPI. Его работу можно разделить на три части:

1. Настройка логики сбора для конкретной информации

2. Настройка запускающего механизма для выполнения логики сбора

3. Загрузка собранных данных в базу данных

Цель — расширять этот процесс, применяя эти три шага к различным данным API.

Схема организации проекта

Существует множество архитектурных подходов к организации проекта. В частности, использование фреймворков позволяет начать проект с уже готовой структуры. Однако, как уже упоминалось, в этом проекте целью является минимизация зависимостей, поэтому я решил структурировать проект, разбив его на папки по функциональности, максимально приближенно к описанной выше логике.

Проект будет организован следующим образом:

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 — логика взаимодействия с OpenAPI для сбора данных. Так как в данный момент используется только один основной API, папка содержит только один файл клиента.

db — определена логика взаимодействия с базой данных. Внутри connection реализовано только подключение, а в repository — логика выполнения различных запросов upsert. Сами SQL-запросы пока находятся в коде, но в будущем я планирую вынести их в отдельные файлы.

util — здесь определена различная вспомогательная логика. error — это временный скрипт для удобной обработки результатов ошибок Go. Как будет видно из последующих статей, он станет причиной значительного количества побочных эффектов (?).

Файл config предназначен для чтения файла .env без использования сторонних пакетов, поэтому в нём реализована функция чтения файла .env.

worker — здесь находится основная логика, которая использует логику api и db для выполнения нужных действий. В будущем, при увеличении количества воркеров, нужно будет увеличивать и количество файлов в этой папке, но пока здесь реализован только один основной воркер.

В дальнейшем планируется развивать код, придерживаясь принципов многоуровневой архитектуры.

Зависимости проекта

pq для работы с PostgreSQL

sqlx для выполнения запросов

Завершение работы над воркером

Кажется, что просто перечислять теорию без кода может быть скучно, и я сам начинаю немного уставать. Поэтому, пожалуй, закончим на этом.

Вот и завершается вторая часть. Надеюсь, в третьей части мы сможем добавить хотя бы строчку кода и обсудить её.

В процессе разработки LegiNote, если вам нужны какие-либо функции или у вас есть вопросы о разработке, пожалуйста, оставляйте комментарии!