CrudService의 reservedXXX 들이 엔티티를 명확히 반환하면 어떨까요? (delete 제외)

[woowahan-kibae]

다시 고민해 보았으면 하는 부분이 있습니다.
reservedXXX() 메쏘드들이 type CrudResponseType<T> = Partial<T> | void;로 리턴하고 있습니다. 그래서 결과값의 타입 추론이 전혀 되지 않습니다.

Method 별로 케이스들을 보면

• readOne, readMany, search: 응답값을 none을 사용할 이유가 없음. id만 가져갈 경우가 거의... 전혀 없다고 봐야 합니다.
• create: 응답값을 none을 사용할 이유가 없음. 최소한 id, 보통은 엔티티를 주는 것이 소비자나 개발자 사용성이 높을것 같습니다.
• upsert, update, recover: id를 알고 있기 때문에 응답값을 id을 사용할 이유가 없음. none으로 선택하면 http status 값만 보고 성공 여부를 판단해야 하는데 API 소비자 입장에서는 저장 시 자동 변경되는 필드들이 있기 때문에 많은 경우 엔티티를 받아가기 원합니다.
• delete: 여기는 응답값이 있을 필요가 없습니다.

보통 갱신이 일어나는 경우 DB에서 최종 스냅샷을 다시 가져와서 응답을 하려 하기 때문에 성능상의 이슈로 아무 응답을 주지 않는 경우들이 있습니다. DB 스키마에 있는 기본값이 랜덤값이 있다거나 하는 경우들이 있어서요.(엣지 케이스)
하지만 현재 코드를 보면 갱신 후 다시 읽어서 응답하는 방식이 아니기 때문에 성능상의 이슈로 엔티티 응답을 하지 않을 이유가 없는것 같습니다.

그래서,

• 요청 시 options.response(entity, id, none) 옵션 제거
• crudService.toResponse() 메쏘드 제거
• 응답값을 CrudResponseType<T>가 아닌 T

응답값을 바꿀수 있는 옵션을 과감히 제거하고 delete 요청 외의 모든 요청에 엔티티를 내려주는게 어떨까 합니다.

또는 이 기능을 그대로 유지하면서도 CrudResponseType가 응답값의 타입 추론이 잘 되도록 하는 방법을 찾아봤으면 합니다. (제가 할 수 있는 시도들은 꽤 해봤으나 잘 안됐음...)

[jiho-kr]

초기의 불명확한 컨셉이 잘 정리되어가고 있는 것 같습니다. :)

추가로 현재 Response에 대해서 Interceptor를 통해 사용자가 가공을 할 수 있게 디자인 되어있는데,

#18 와 합쳐서 decorator 옵션에 swagger를 통해 사용자가 override 할 수 있게 하면 좋겠다는 생각이 들었습니다.

@Crud({
    entity: BaseEntity,
    routes: {
        create: {
            swagger: {
                body:  PickType(BaseEntity, ['name']) },
                response: OmitType(BaseEntity, ['hideKey']) }
            }
        }
    }
})

[woowahan-kibae]

저는 주로 CrudService에 대해 고민을 해보고 있는데요~
CrudService를 상속받은 서비스 객체를 활용하는 일들이 자주 있을것 같습니다.

overridedCreate(...) {
  const result = await this.reservedCreate(...);
  // do something. 그런데.. result. 이후로 아무 자동완성이 안되는!
  return result;
}

• 이럴 때 reservedXXX 의 리턴이 일정하고 타입추론이 제대로 되었으면 좋겠습니다.

그리고 추후에 CrudCqrsService 같은걸 만든다면 CrudService의 모든 오퍼레이션을 오버라이드하게 될 것인데요. 조회는 캐시에서, 갱신들은 메시지 버스로 보내는 식으로 오버라이드 되겠지요? 그 메시지는 실제 저장이 일어날 CrudService로 전달이 될 것인데 이 때도 요청 DTO에 있는 어떤 값을 항상 보고 동작해야 한다면 어려움들이 있을것 같아요.

그래서.. 이 유용한 기능을 어디에서 처리해야 할까? 역할 분담을 어떻게 해야 할까? 라는 고민을 하게 됐는데 service는 요청 DTO의 옵션과는 무관하게 항상 엔티티를 일정하게 리턴하고 abstract service <-> abstract controller 중에 controller가 응답값만 바꾸는 작업을 하면 어떨까? toResponse() 역할을 CrudRouteFactory가 생성해주는 컨트롤러 코드에 있으면 어떨까? 생각이 들었습니다