Вопрос или проблема
Я работаю над приложением на nodejs + Express, которое выполняет следующие действия для каждой конечной точки (‘/dataset-type1’, ‘/dataset-type2’, ‘/dataset-type3’, …):
- Совершает запросы к нескольким различным API третьих сторон
- Парсит их в набор данных типа, соответствующего конечной точке
- Возвращает указанный набор данных. Также есть несколько конечных точек для сохранения и извлечения этих наборов данных из БД.
Текущая структура файлов вызывает вопросы, так как она выглядит так:
src
|- /routers
| |- куча маршрутизаторов express (например, для /dataset-type1, /dataset-type2, ...)
|- /utils
| |- get-apiA-data.js
| |- get-apiB-data.js
| |- get-apiC-data.js
| |- get-apiD-data.js
| |- axios-instances.js
| |- standardize-apidata-format-util.js
| |- handle-missing-data-util.js
| |- helper-function-for-specific-edge-case.js
| |- parse-dataset-type1.js
| |- dataset-type1-helpers.js
| |- parse-dataset-type2.js
| |- parse-dataset-type3.js
| |- dataset-type3-helpers.js
| |- много других похожих файлов
|- /db
| |- куча SQL-запросов, обернутых в функции javascript
|- app.js
Кроме того, что /util является неправильным названием, так как на самом деле он просто хранит всю логику построения наборов данных, основная проблема в том, что это становится очень громоздким, и становится трудно понять, какие скрипты предназначены для каких функций.
Я искал варианты рефакторинга онлайн, и все рекомендовали многоуровневый подход с чем-то вроде маршрутов/контроллеров/сервисов/уровня доступа к данным, что, по моему мнению, только усложнит мой код, разделяя вещи на несущественные уровни. На самом деле не так много бизнес-логики, логики обработки запросов или сложного использования БД, поэтому схема, которую я представлял, выглядела бы так:
src
|- /routers
| |- содержимое существующей папки маршрутизаторов, за исключением того, что логика в каждом обработчике маршрутизатора перемещается в контроллер
|- /controllers
| |- файлы контроллеров, которые выглядят как старые файлы маршрутизаторов
|- /services
| |- содержимое папки utils, вероятно, переработанное так, чтобы выглядеть более сервисно
|- /data
|- app.js
Где у меня была бы та же проблема, что и сейчас, за исключением того, что громоздкая папка называется ‘services’ вместо ‘util’, и у меня есть куча дополнительных файлов контроллеров. На самом деле единственная сложная часть этого приложения – это часть о scraping и парсинге данных, и я просто хочу схему для организации файлов для этого.
В конечном итоге мои вопросы:
- Оправдано ли не использовать общую архитектуру уровней в моем случае?
- Существует ли рекомендуемый способ организовать скрипты генерации наборов данных так, чтобы они не были собраны в одной папке и их роль/намеченное использование было ясно?
Ответ или решение
В вашей ситуации, когда основной задачей вашего приложения на Node.js и Express является скрейпинг данных и возврат их через API, важно правильно организовать структуру кода для обеспечения его читаемости, поддерживаемости и масштабируемости. Давайте рассмотрим предложенные вопросы более подробно.
1. Достаточно ли уместно не использовать многослойную архитектуру?
В вашем случае можно сделать вывод, что многослойная архитектура может показаться избыточной, учитывая простоту вашего приложения. Однако она всё же имеет свои преимущества:
-
Модульность: Разделение кода на логические компоненты делает его более понятным и удобным для сопровождения. Если вы решите в будущем добавить больше возможностей в приложение, таковая структура поможет избежать путаницы.
-
Тестирование: Более модульный код проще тестировать. Вы сможете легче изолировать различныe части приложения, что упростит написание тестов.
Тем не менее, если ваше приложение действительно невелико и не обладает сложной логикой, то использование упрощенной структуры может быть оправдано. Вы можете даже разработать свой собственный легковесный подход, избегающий чрезмерной абстракции.
2. Как организовать скрипты генерации наборов данных?
Вместо того, чтобы помещать все скрипты в одну папку, я рекомендую использовать более структурированный подход, который чётко разделит обязанности. Вот как можно организовать вашу папку src:
src
|- /routers
| |- datasetRoutes.js // маршруты для разных наборов данных
|- /controllers
| |- datasetController.js // обработка запросов и вызов соответствующих сервисов
|- /services
| |- /dataset-type1
| | |- apiAService.js // взаимодействие со сторонним API A для тип1
| | |- apiBService.js // взаимодействие со сторонним API B для тип1
| | |- parseDataset.js // парсинг данных для тип1
| |- /dataset-type2
| | |- apiCService.js // ...
| | |- parseDataset.js // ...
| |- /dataset-type3
| | |- apiDService.js // ...
| | |- parseDataset.js // ...
|- /data
| |- db.js // взаимодействие с базой данных
|- app.js Преимущества предложенной структуры:
-
Спецификация по типу набора данных: Каждая папка внутри
servicesимеет свою собственную структуру, понятную по наименованию, что облегчает навигацию. -
Изоляция логики обработки: Все, относящееся к конкретному типу набора данных, группируется вместе (например, API-интерфейсы и парсеры), что минимизирует путаницу и делает код более поддерживаемым.
-
Логическая организация: Вы сможете легко добавить новые типы наборов данных, не мешая существующим компонентам.
Заключение
Применяя описанный подход, вы сможете значительно улучшить читаемость вашего кода и его структуру, не прибегая к избыточной абстракции или множеству слоёв, которые могут лишь усложнить вашу работу. Это даст возможность сосредоточиться на самой важной части вашего приложения — скрейпинге и парсинге данных.
Разумная организация структуры кода и файлов позволит вам справляться с увеличением объёма данных и возможностью дальнейшего расширения функций без потери ясности в архитектуре приложения.