mm-ninja-turtles / turtle-express

My attempt of making Express.JS a typesafe router with Zod.
3 stars 0 forks source link

[feature]: response structure analysis #51

Open PyaePhyoKyaw61194 opened 2 years ago

PyaePhyoKyaw61194 commented 2 years ago

Currently , our response structure is

{
  success: boolean,
  message: string,
  data: any,
  error:  any
}

// and status code (HTTP status code)

The resolver can only define the status code and data property of the response(generally saying response, not to be conflict with the library's response object). The success, message and error are controlled by the library. In real world, we may want to response custom error message( for explaining customer about the business logic related error details). We may want to set our custom error object ( perhaps, with custom error code(not HTTP) with internal rules). In this case, how should we attach that? Just in data property of the response ?

MrMyatNoe commented 2 years ago

Status code mean internal status for clients dealing with some meaningful messages and errors, not included in HTTPS status code sheet, correct?

PyaePhyoKyaw61194 commented 2 years ago

Sorry for misunderstanding , @MrMyatNoe it HTTP status code. Our lib can send the statusCode(HTTP) and the above structure {success , message .. } back to client. We use res.status() and res.send() of express's res object.

wai-lin commented 2 years ago

For this problem, I'm thinking of providing the new API in createRouter function options which can define global response object shape or adding custom fields as the users want.

eg.

const router = createRouter(Router(), {
  basePath: '/v1',
  // ...
  responseShape({ status, message, data, error }) {
    return {
      myStatus: status,
      message,
      data,
      error
    }
  }
})

I don't know it would be like this when implemented. This is how I would like to use at least as a user. There might be better way to this problem too.