Treat raw JSON string the same way as the output type

[adam-kov]

Describe the feature

I'd like to have the option to return raw JSON strings from route handlers, which get treated the same way on the client as if the handler returned nested structures. The idea behind this is to skip a round of JSON marshalling/unmarshalling when returning cached responses.

Currently, this is what happens if I serve a cached response:

1. Cache hit
2. Parse cached JSON string
3. Return JSON object from the handler
4. Stringify into the response body
5. Parse the response body on the client

If we could return plain strings from handlers and mark them to be treated as the schema/type defined in the output() method, we could skip steps 2-4.

Potentially, the 'detailed output' structure could be updated to something like this:

os.route({
  path,
  method,
  outputStructure: 'detailed'
})
.output(responseSchema)
.handler(() => {
  const cachedResponse: string = await cache.get(key);
  return {
    status: 200,
    preStringifiedBody: true, // <-- With this setting, the body is expected to be a string
    body: cachedResponse
  }
})

Or a top-level route setting could be added:

os.route({
  path,
  method,
  preStringifiedOutput: true // <-- New setting
})
.output(responseSchema)
.handler(() => {
  return await cache.get(key);
})

Additional information

• Would you be willing to help implement this feature?

[unnoq]

The main problem is that TS infers the body as a string, so it complains that it doesn’t match what .output defines, and this results in a validation error during the validation step.

[adam-kov]

Sorry, I forgot there's server-side validation because I use .output(type<...>()) instead of an actual schema.

On the other hand, if a handler is set up to have its output validated, then surely the body can be parsed before passing it on to the validator. And in every other case, the response could be sent as is.

I haven't had a look at the internals of oRPC, so I'm sure my approach is fairly naive, but if you reckon the feature is not impossible, and fits the goal of the project, then I could start exploring the possibilities.

[unnoq]

but if you reckon the feature is not impossible

This feature is possible actually, but require some strict conditions and may bypass some steps