数据库 - 前端应用结构

Question

这个问题对于 SO 社区来说可能过于宽泛/概念化，但我会试一试。

快速项目概览：

我有一个项目，它包含一个前端应用程序，它通过 Angular $http 请求从数据库请求数据。每个请求几乎都与一个控制器一对一地映射，该控制器可视化该请求中指定的数据。

例如，我可以在特定时间范围内指定关键字：

get/A/kwords/?year=2013&month=9

并接收：

[
    {"kword": "a", "count": 100, },
    {"kword": "b", "count": 200, },
    ...
]

然后我将其插入d3 directive。

问题：

我已经到了这个项目的地步，我不得不为开发后端或前端的人员提供额外的工作。就应用程序当前而言，数据库发送大量 JSON 数据，然后前端必须对其应用转换函数，以便将数据塑造成不同 d3 directives 所需的格式。例如，一些 JSON 请求发送了前端需要逻辑来标准化输入指令的数据的多余数据。

这是我认为不应该强制前端处理的逻辑。 在我看来，前端应该只需要与 JSON 请求参数交互，而不是实际传入数据的格式。我认为后端能够服务更有意义根据 URL 参数以一致的格式上传数据。

例如，不是后端提供格式如下的数据：

/get/B/kwords/?year=2013&month=9&limit=6

[
    {
    "kword": "a",
    "data": [{"impressions": 100, "clicks": 150, "conversions": 200} ]
    },
    {
    "kword": "b",
    "data":[{"impressions": 50, "clicks": 60, "conversions": 70} ]
    },
    ...
]

并强制前端分解这个数组对象数组对象，我应该能够在请求中指定一个 data=impressions 参数：

/get/B/kwords/?year=2013&month=9&limit=6&data=impressions

[
    {
    "kword": "a",
    "data": 100,
    },
    {
    "kword": "b",
    "data": 50,
    },
    ...
]

这有意义/这是一个合理的要求吗？

Answer 1

我遇到了类似的情况，最初我最终选择了后端处理过滤而前端只处理将数据绑定到 d3 的路由。

问题是这非常非常慢。每个 $http 请求需要 1-3 秒，因此过滤体验不是很好，因为您必须单击过滤器并等待看到响应。

实际上将尽可能多的数据发送到前端并在那里进行过滤要容易得多。因此，虽然初始页面加载需要更长的时间，但过滤是即时的。我最终重写了后端和前端来完成前端的工作。我试图使从后端发送的初始数据尽可能平坦，并遍历该数组并将相关数据推送到 javascript 对象上的属性以快速转换数据。

如果我要再次做这个项目，我可能会尝试探索库 dc.js 和 crossfilter 以避免编写一些过滤逻辑。

这些是客户端过滤速度的示例：

http://dc-js.github.io/dc.js/

http://square.github.io/crossfilter/