Simplify tRPC Request/Response/Message Interfaces

Originally posted by @KATT

See @jlalmes’ PR https://github.com/trpc/trpc/pull/1759

Potential things. Not definitive, just ideas.

Remove unused fields

Before:

[
  {
    "id": null,
    "result": {
      "type": "data",
      "data": {
        "id": "1",
        "title": "Hello tRPC",
        "body": "..."
        // ...
      }
    }
  },
]

After:

[
  {
    "result": {
      "data": {
        "id": "1",
        "title": "Hello tRPC",
        "body": "..."
        // ...
      }
    }
  },
]

Changed response to a mapped object

Potential ease of allowing for streaming… maybe we could start sending response as procedures are finalised and not wait for all of them to be finalized before returning… but it also breaks HTTP-codes so not sure.

Probably not a good idea, just a thought

{
  // 0 means index 0 of the batch
  "0": { 
    "id": null,
    "result": {
      "type": "data",
      "data": {
        "id": "1",
        "title": "Hello tRPC",
        "body": "..."
        // ...
      }
    }
  },
]

Remove JSONRPC

Remove JSNORPC stuff on the request/response for internal requests…

[KATT]

Why don’t we also remove the result.data wrapper?

{ "greeting": "Hello tRPC" }

// batched request response
[
  { "greeting": "Hello tRPC" },
  { "greeting": "Hello tRPC2" }
]

It’s a good idea and I was thinking about that for a while but I probably will want to decorate responses with extra metadata in the future.

One of the ideas I’ve been toying with is an edge-cached tRPC service that could work a bit like GraphCDN - for that to work I would need to provide caching hints for each individual procedure.

[jlalmes]

Is there a reason why we don’t we send these payloads as an array type?

To correctly serialize undefined: #669 (comment)

Thanks @sachinraja! Understood 👍