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

Question

我正在开发一个可能会生成 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 个声音，每一个和几十个项目。

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

Answer 1

对我来说唯一显而易见的是，您可能想要制作一个语音列表（就像您对物品所做的那样），而不是语音 1、语音 2 等。

除此之外，它实际上只取决于您开始使用的数据结构（创建 json）和目的地的数据或代码结构（如果可能，还可能是传输数据的方法）大小是一个问题）。如果您在 encode/decode 和 json 的任一端都进行了大量处理，这表明有一种更简单的数据结构方法。您能否分享一些额外的背景信息或整个过程的示例？

Answer 2

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

JSON 压缩得很好。您可以看到大多数标记是如何重复多次的。因此，在发送给客户之前，请确保使用 Gzip 或 Snappy。这将大大减小尺寸，但会消耗一些膨胀/放气的性能。
另一种选择是不使用JSON进行传输，而是一种更优化的格式。这里最好的选择之一是 Flat Buffers. It does require you to provide schemas of the data that you are sending but is an optimized binary format with minimal overhead. It will also drastically speed up your application because it will remove the need for serialization / deserialization, which takes a significant time for JSON. Another popular, but slightly slower alternative is Protobuf.

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

Architectural Decision: How to structure a big Json Response

architecture

json

design-decisions