架构决策：如何构建大型 Json 响应答案

【问题标题】：Architectural Decision: How to structure a big Json Response架构决策：如何构建大型 Json 响应
【发布时间】：2021-12-19 16:34:46
【问题描述】：

我正在开发一个可能会生成一个非常大的 Json 的应用程序。在我的测试中，这是 8000 行。这是因为是一年的数据聚合，需要在 UI 中显示详细信息。

例如：

"voice1": {
    "sum": 24000,
    "items": [
        {
            "price": 2000,
            "description": "desc1",
            "date": "2021-11-01T00:00:00.000Z",
            "info": {
                "Id": "85fda619bbdc40369502ec3f792ae644",
                "address": "add2",
                "images": {
                    "icon": "img.png",
                    "banner": null
                }
            }
        },
        {
            "price": 2000,
            "description": "desc1",
            "date": "2021-11-01T00:00:00.000Z",
            "info": {
                "Id": "85fda619bbdc40369502ec3f792ae644",
                "address": "add2",
                "images": {
                    "icon": "img.png",
                    "banner": null
                }
            }
        }
    ]
},

关键是我可能有 10 个声音，每打几十个项目。

我想知道您是否可以向我指出一些最佳实践，或者您是否有一些关于它们的提示，因为我觉得这可以做得更好。

【问题讨论】：

标签： json architecture design-decisions

【解决方案1】：

听起来您发现 JSON 是一种相当冗长的格式（不像 XML 那样糟糕，但仍然非常冗长）。如果您担心服务器客户端之间的消息大小，您有几个选择：

JSON 压缩得相当好。您可以看到大多数令牌如何重复多次。因此，在发送给客户端之前，请确保 Gzip 或 Snappy。这将大大减小尺寸，但会消耗一些充气/放气性能。
另一种选择是不使用 JSON 进行传输，而是使用更优化的格式。这里最好的选择之一是Flat Buffers。它确实需要您提供要发送的数据的模式，但它是一种优化的二进制格式，开销最小。它还将大大加快您的应用程序的速度，因为它将消除对 JSON 需要大量时间的序列化/反序列化的需要。另一个流行但速度稍慢的替代方案是Protobuf。

【讨论】：

【解决方案2】：

对我来说唯一显而易见的是，您可能想要列出声音（就像您对项目所做的那样），而不是声音 1、声音 2 等。

除此之外，它实际上只取决于您开始使用的数据结构（创建 json）和目标数据或代码的结构（如果需要考虑大小，还可能还有传输数据的方法）。如果您在任一端进行大量处理以对 json 进行编码/解码，这可能表明有一种更简单的数据结构方式。你能分享一些额外的背景或整个过程的例子吗？

【讨论】：