[feature]: whole new code base changes with well typed system

[wai-lin]

While I was researching about the OpenApi for the #42, I kind of feel like current code base needs a more systematic structure to support OpenApi integrations.

When I first started the library, I just had an idea to include OpenApi and didn't thought much about it during features implementation. After researching about OpenApi and experiencing zod with open-api, I can now structure the code base for the proper OpenApi first-class support.

Also during the research, I found some solutions to solve the currently opened issues. So, I'll be focusing my effort to rebasing the code with the new typed system with OpenApi first-class support in mind. After this, hopefully most of the opened issues will be done.

[wai-lin]

reminder @mm-ninja-turtles/core-maintainers.

[wai-lin]

The new typed system might not support hover documentations for each http-status-codes and this is the trade off I'm willing to make in order to get better typed system.

[wai-lin]

@mm-ninja-turtles/core-maintainers

Decided to remove guard function and add middlewares options in handler function. middlewares accepts express handler functions. And context will be passed to request and response objects accordingly with where the context should be provided. middlewares options will also available in path function. As for the createRouter, currently exposing of express's use function might be enough.

const users = router.path('/users', {
  middlewares: [usersLogger],
})

users.handler({
  method: 'get',
- guard({ ctx }) {
-   returne { pass: false, data: null }
- },
+ middlewares: [authGuard],
  // ...
})

function usersLogger(req, res, next) {
  console.log('users logger')
  next()
}

function authGuard(req, res, next) {
  console.log('authGuard')
  next()
}

[wai-lin]

The new typed system might not support hover documentations for each http-status-codes and this is the trade off I'm willing to make in order to get better typed system.

The typed system support hover documentation on resolver return type but not in handler response schema object which is not too bad rather there is no documentation.

[wai-lin]

New handler function life-cycle

flowchart TD
  middlewares -- next --> request_validation 
  request_validation -- validation success --> resolver
  request_validation -- validation failed --> before_response --> final
  resolver -- uncontrolled type --> final
  resolver -- controlled type --> resolver_validation -- done --> before_response

This new handler flow will be easier to track and more compact.