如果我的后端唯一的工作就是抓取和返回 API 数据，如何组织它？

问题描述 投票：0回答：1

我正在开发nodejs + Express应用程序，它只为每个端点执行以下操作（'/dataset-type1'，'/dataset-type2'，'/dataset-type3'，...）：

  1. 调用多个不同的第三方 API
  2. 将它们解析成与端点对应类型的数据集
  3. 返回所述数据集 还有一些用于从数据库保存和检索这些数据集的端点。

当前的文件结构有问题，因为它看起来像这样：

src
|- /routers
|    |- a bunch of express routers (e.g. for /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
|    |- lots of other similar files
|- /db
|    |- a bunch of SQL queries wrapped in javascript functions
|- app.js

除了 /util 是一个用词不当之外，因为它实际上只是保存所有数据集构建逻辑，这里主要的问题是它变得非常笨拙，并且很难区分哪些脚本用于哪些功能。

我正在网上寻找重构选项，一切都建议采用分层方法，例如路由/控制器/服务/数据访问层，我觉得这只会让我的代码更难遵循，将事物分成不必要的层。确实没有太多业务逻辑、请求处理逻辑或高级数据库使用，所以我想象的方案是这样的：

src
|- /routers
|   |- contents of existing routers folder, except logic in each router handler is moved to a controller
|- /controllers 
|   |- controller files that look like the old router files
|- /services 
|   |- contents of utils folder, probably refactored to look more service-like
|- /data
|- app.js

我会遇到与当前完全相同的问题，除了笨重的文件夹被命名为“services”而不是“util”，而且我有一堆额外的控制器文件。实际上，这个应用程序唯一涉及的部分是数据抓取和解析部分，我只想要一个用于组织文件的方案。

最终我的问题是：

  • 在我的案例中使用公共层架构是否合理？
  • 是否有一种明智的方法来组织数据集生成脚本，以便它们不会集中在一个文件夹中，并且它们的角色/它们的用途很明确？
node.js express architecture
1个回答
0
投票

需要将分层和功能切片（垂直切片）的元素结合起来。 使用图层通常是明智的，但您始终必须评估您实际需要的哪些图层。

看起来您需要确定一种模式来“解决”如何调用给定数据源（第 3 方 API）。 该模式可能包括以下元素：

  1. 基于技术的实用程序（JSON 解析器、REST 请求构建器等）。
  2. 数据源特定逻辑。
  3. 数据源特定数据类型。
  4. 构成应用程序运行时核心的应用程序逻辑。
  5. 应用程序使用的常见数据类型（API 配置等）。

该模式将是一次性编写并重复使用的通用代码与每个数据源唯一的数据源特定代码的组合。

这将为您提供 3 个逻辑层：

  • 核心应用
  • 实用程序和助手。
  • 数据来源。

就垂直切片而言，您可以说您有 N+1，其中：

  • N = 数据源/第 3 方 API 的数量，即每个 API 一个切片，并且
  • +1 = 主应用程序。

Robert C Martin 谈论“尖叫架构”，我没有读过很多这方面的内容，但基本思想是，当有人查看你的代码时，它的目的应该对你“尖叫”。 例如，如果您的代码排列在“controllers”等文件夹中，则不清楚其目的是什么，但如果您的代码包含“ChartOfAccount”、“Billing”、“AccountsPayable”等文件夹，那么很明显这是一个财务管理应用程序。

所以在你的情况下，你可能会遇到类似的情况：

 - /Common
 - /Common/DTO
 - /DataSources/API_A
 - /DataSources/API_B
 - /DataSources/API_X
 - /MainAppCode
 - /Utilities
 - /DataAccess
 - /DataAccess/Sqlite

我不确定这个名字

MainAppCode
，但希望你能了解大概的意思。

数据访问 - 意味着您的后端数据库，您应该考虑是否适合将其抽象出来，以及如何抽象。 纯粹的方法意味着在数据访问代码中使用代表物理数据库的 DTO，而不是其他任何地方 - 您的主应用程序逻辑将使用与数据库无关的实体。 另一种方法是使用一组 DTO，其中包括直接来自数据库的对象表示以及独立于数据库的对象 - 这不会那么复杂，但是一个需要权衡的选择。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.