By the way, tRPC is good for building toy projects, but not suitable for developing enterprise level backend server. In such reason, many NestJS lovers had requested tRPC team to support NestJS. But considering principle of tRPC, it never can support NestJS.
https://dev.to/samchon/nestia-boost-up-your-nestjs-server-much-faster-and-easier-maximum-20000x-faster-59o5
Nestia 소개한 블로그 포스팅에서 본 글인데
trpc가 엔터프라이즈 레벨에 맞지않는 이유가 뭐야?
그리고 trpc팀이 nestjs를 support하지않는다는게 뭘 서포트하지않는다는거야?
이 포스팅 말고는 다른곳에서 비슷한 내용을 찾을수가 없다
development 상태라 breaking change가 많아서 엔터프라이즈에선 쓰기 힘들다는거 아니냐
그런이유라면 trpc대신 nestia를 쓰라는게 말이 안되잖아 상대적으로 더 안정된건 trpc일텐데
삼촌 아재가 쓴 글은 자기 기술이 가장 우월한 단 하나의 선택지인 어떤 평행우주에서 건너왔다는 설정으로 보셈 ㅇㅇ
tRPC로 개발하려면 프론트도 서버 코드 들고있어야하는게 문제고, 이거 tmp 떡칠된거라 (zod + router) api 개수 80개 전후로 타입스크립트 컴파일러가 스택오버플로 에러 내면서 터짐. Tsc는 복불복으로 터지고, tsc --watch는 백퍼 터지고. 그래서 api 개수가 많은 상용에선 못 쓰고, 나도 간단한 거 만들 때만 씀
레딧에도 tmp 남용하면 tsc 터진다는 얘기 종종 있음
그래서 옛날에는 tRPC 추천하고 다니다가, 매운맛 함 보고 더 이상 주변에 추천 안 하는 중
아 80개 훌쩍넘는다 안되겠네. 이런건 저 블로그글에 추가하는건 어때? 이런내용이 없으니까 설득력이 확 떨어짐.
혹시 이 내용에 대한 이슈 링크좀 줄수있음? 찾아봐도 잘 안나오네
https://www.reddit.com/r/typescript/comments/13sldut/how_do_people_use_zod_on_a_large_project/
https://www.reddit.com/r/typescript/comments/13twezh/askts_what_do_you_think_will_be_the_future_of/
프로젝트 커지면 zod만 써도 IDE 딜레이 5초씩 걸린다는 글임. 여기다가 API 더 박고 TMP로 프로젝트 통 참조까지 해야하는 프론트 얽히면 겉잡을 수 없음. Validator에 TMP 쓰는게 왜 망한 전략이고, AOT 방식이 나은지 나중에 별도 글로 쓸 예정 ㅇㅇ