언제나처럼 typescript-json 개발하고 있었는데
TypeBox 개발자가 찾아와서 자기꺼도 벤치마크 해달라고 DTO 만들어서 PR 때리더라
그래서 벤치마크 돌려봤는데, 첨에 is() 함수 속도 보고 개 놀램
아, 다른 머저리같은 validator 라이브러리 말고, 진짜 경쟁할 만한 놈이 생겼구나 싶음 ㅇㅇ
그래서 TypeBox 소스코드 좀 뜯어봤고,
무슨 이유로 빠르되 무슨 이유로 검사 자체를 못하고,
왜 is() 함수 외에서는 느린지 대강 리해 완료
재미난건 TypeBox 내 특정 로직이 1만배라는 경이로운 속도륾 만들었지만
그 때문에 복잡한 타입에 대한 검사가 불가능하다는 단점도 같이 가져간다는 것 ㄷㄷ
근데 is(), assertType(), validate() 저 함수들이 실제 워크로드들에서 차지하는 비중이 얼마나 되나요? TypeScript는 웹 응용에 많이 쓰이는 걸로 아는데, 웹 응용들은 대부분 I/O bound해서 타입 체크하는 시간이 높은 비중을 차지할지 궁금하네요
프론트보다는 백엔드에서 중요합니다. 프론트가 전송한 request body의 데이터가 정확한지 유효성을 검사하는데 쓰이죠. 그리고 백엔드에서 일어나는 대부분의 작업은 네트워크나 DB I/O 등 백그라운드 프로세스에서 돌아가는 것들인데, 유독 이 validation 만은 메인 스레드를 점거하는 작업이구요. 그래서 validation 느리면 느린만큼 받을 수 있는 동접자 수가 팍팍 줄어듭니다
이거 만들게 된 이유도, 타입스크립트 백엔드는 NestJS + Class-validator 로 만드는게 국룰인데, class-validator 가 하도 느려서 지대로 피 본 적이 있기 때문입니다. 구글 드라이브 같은 API 만드는데, 무슨 validation 에 1초씩 걸리니까, 걍 동접 그 자체를 못 받는 상황을 겪었던 거죠. 그래서 승질 뻗쳐서 걍 내가 만듦 ㅇㅇ
그리고 class-validator고 io-ts고 typebox고, 타입스크립트 타입 그대로 쓰는게 아니라, 걔들한테 필요한 스키마를 중복 정의해야하는데, 그것도 개발하다보면 토 나오는 일입니다. 그래서 타입스크립트 인터페이스 타입 그대로 DTO로도 쓰고 validation으로도 쓸 수 있게 직접 만든 것
메인 쓰레드에 부하가 몰리는 경향이 있나보네요. Class-validator의 성능도 문제지만 근본적으로는 데이터 유효성 검사가 메인에 몰리는 것이 문제인 거 같은데, 혹시 validation 작업을 worker 쓰레드에서 처리하게 바꿀 수는 없는 걸까요?
오 이해완료
멋져요형님
오 재밌네
글로벌 머형 개발자의 탄생을 실시간으로 보는중 ㄷㄷ
옥찬호, 정동하 개발자님 커미터에 뭐임? 진짜 한국의 전설들 한테 인정을 받았네 와 - dc App
나도 보고 놀랐는데 readme 오탈자 수정인 거 보고 인간미 느낌 났음 ㅋㅋㅋㅋㅋ
뭔지는 잘 모르겠지만 속도에 존나 진심인 새끼..그래서 멋있는 새끼
그의이름은 소닉
https://dev.to/samchon/i-found-10000x-faster-typescript-validator-library-36mj
이번에 stc 하고 비교하면 어캐될지가 기대됨... ㄹㅇ...
윗댓이 stc 언급해서 궁금한게 생각났음. 현재 빌드 구성이 esbuild/swc 를 주로 사용하고 있어서 ttypescript 같은 확장은 못쓰는데 추후에 다른 컴파일러/런타임에서 쓸 수 있도록 지원할 계획이 있음?
와 미쳤네