TypeScript 개입: Byzantium으로 런타임 확인 중독을 깨뜨려보세요

보세요, 중독을 확인하는 유형에 대해 이야기해야 합니다. 예, 당신은 인증 미들웨어에 47개의 검사 인스턴스가 있는 사람입니다. 실제 코드보다 테스트 케이스를 더 많이 작성하는 개발자. TypeScript를 마치 JSDoc 주석처럼 다루는 사람.

개입

그림을 하나 그려보겠습니다. 지금은 정오이고 커피를 네 번째 마시고 있으며 생산 문제를 디버깅하고 있습니다. 로그에는 사용자가 어떻게든 런타임 유효성 검사의 15개 레이어를 통과했음이 표시됩니다. Twitter의 활성 사용자보다 더 많은 단위 테스트가 있는데 어쨌든 누군가 문자열이 있어야 할 곳에 숫자를 보냈습니다.

"하지만 그건 불가능해요!" 당신은 깨끗한 100%를 보여주는 테스트 적용 범위 보고서를 스크롤하면서 울었습니다. "이거 확인했어요!"

그래도 그랬나요? 정말로 그랬나요? 아니면 같은 수표를 세 번이나 썼나요?

1. TypeScript 인터페이스에서 한 번
2. 다시 검증 미들웨어에서
3. 그리고 다시 단위 테스트에서

TypeScript가 이미 알고 있는 내용 테스트 중지

여기 혁명적인 아이디어가 있습니다. 만약 우리가 컴파일러를 신뢰한다면 어떨까요? 나도 알아, 거친 개념. 하지만 내 말을 들어보세요.

interface ValidRabbit {
    username: string;
    password: string;
}
interface InvalidRabbit {
    username: number;
    password: string;
}


type ValidateRabbit<rabbit> = Assert,
    //custom compile time exceptions
    "Trix are for kids. Provide a username and password.",
    User
>;

// Ha! Silly Rabbit...
function checkRabbit<t>(rabbit: ValidateRabbit<t>) {
    // .... protect your trix
}

declare const rabbit1: ValidRabbit;
declare const rabbit2: InvalidRabbit;

checkRabbit(rabbit1);
checkRabbit(rabbit2);
/**        ~~~~~~~~~
 *           └───── Type Exception! "...Provide a username and password"
 */
</t></t></rabbit>

"하지만 생산은 어떻습니까?"

이제 들리네요. "하지만 누군가 내 API에 잘못된 JSON을 보내면 어떻게 될까요?"

먼저, 누가 당신에게 상처를 주었나요? 둘째, 그렇습니다. API 경계를 확인하세요. 하지만 해당 데이터가 TypeScript 도메인에 들어오면 이제 놓아야 할 때입니다. 컴파일러를 경비원으로 활용하세요.

Byzantium이 신뢰 문제 당사자에게 제공하는 기능은 다음과 같습니다.

// Define your trust boundaries
type APIRequest<request> = Assert,
    Or<is.in>, Is.In<request>>
>;,
    "Someone's being naughty with our API"
>;

// Now everything inside is type-safe
function handleRequest<r>(req: APIRequest<r>) {
    // If it compiles, it's valid
    // If it's valid, it compiles
    // This is the way
}
</r></r></request></is.in></request>

DevOps 팀이 당신을 사랑할 것입니다(한 번만)

이렇게 생각해 보십시오. CI/CD 파이프라인은 몇 시간이 아닌 몇 분 만에 완료됩니다. 프로덕션 로그는 유형 오류로 채워지지 않습니다. AWS 청구서가 전화번호와 일치하지 않는 것 같습니다.

어떻게요? Byzantium은 유형 검사를 컴파일 시간으로 이동하기 때문입니다. 더 이상:

• 유형만 확인하는 수천 개의 단위 테스트 실행
• 동일한 유형을 반복해서 확인하면서 CPU 주기를 소모합니다
• 문자열을 원한다고 명확하게 말한 함수에 누군가가 정의되지 않은 값을 전달하여 새벽 3시에 일어났습니다.

// Before: Your CPU crying for help
function validateUserMiddleware(req, res, next) {
    try {
        validateId(req.params.id)        // CPU cycle
        validateBody(req.body)           // CPU cycle
        validatePermissions(req.user)    // CPU cycle
        validateToken(req.headers.auth)  // CPU cycle
        // Your CPU is now considering a career change
        next()
    } catch (e) {
        res.status(400).json({ error: e.message })
    }
}

// After: Your CPU sending you a thank you note
type ValidRequest = Assert,
        Is.On<request>,
        Is.On<request>,
        Is.On<request>
    >,
    "Invalid request shape"
>;

function handleRequest(req: ValidRequest) {
    // Just business logic, no trust issues
}
</request></request></request>

"하지만 나는 시험 작성을 좋아해요!"

엄청난! 실제로 테스트가 필요한 항목에 대한 테스트를 작성하세요.

• 비즈니스 로직
• 통합 지점
• 사용자 작업 흐름
• 복잡한 알고리즘

테스트가 필요하지 않은 것이 무엇인지 아시나요? 문자열이 실제로 문자열인지 여부입니다. TypeScript가 이러한 실존적 위기를 처리하게 하세요.

실제 대화: 이점

1. 더 빠른 개발

   • 더 이상 세 가지 다른 방식으로 동일한 유효성 검사를 작성하지 마세요
   • 오전 3시가 아닌 컴파일 타임에 오류를 잡아라
   • 검증 상용구가 아닌 기능에 시간을 투자하세요

2. 더 나은 성능

   • 유형 검사를 위한 런타임 오버헤드 없음
   • 더 작은 번들 크기(검증 라이브러리 없음)
   • 행복한 CPU, 행복한 삶

3. 보안 강화

   • 유형별 보증은 우회할 수 없습니다
   • 더 이상 "죄송합니다. 확인하는 것을 잊어버렸습니다."
   • 기본적으로 전체 보장

4. DevOps의 꿈

   • 더 빠른 CI/CD 파이프라인
   • 인프라 비용 절감
   • 생산사고 감소
   • 더 행복한 SRE 팀(결과는 다를 수 있음)

시작하기

interface ValidRabbit {
    username: string;
    password: string;
}
interface InvalidRabbit {
    username: number;
    password: string;
}


type ValidateRabbit<rabbit> = Assert,
    //custom compile time exceptions
    "Trix are for kids. Provide a username and password.",
    User
>;

// Ha! Silly Rabbit...
function checkRabbit<t>(rabbit: ValidateRabbit<t>) {
    // .... protect your trix
}

declare const rabbit1: ValidRabbit;
declare const rabbit2: InvalidRabbit;

checkRabbit(rabbit1);
checkRabbit(rabbit2);
/**        ~~~~~~~~~
 *           └───── Type Exception! "...Provide a username and password"
 */
</t></t></rabbit>

선택은 당신의 것입니다

모든 것에 대한 런타임 검사를 작성하고 TypeScript를 JavaScript의 선택적 입력처럼 취급하면서 계속 두려움 속에 살 수 있습니다.

아니면 2024년에 우리와 함께 하여 우리의 컴파일러를 신뢰하고 제대로 작동하도록 하세요.

기억하세요: 런타임 유형 검사를 작성할 때마다 TypeScript 컴파일러가 울부짖습니다.

결론

Byzantium은 단순한 또 다른 라이브러리가 아닙니다. 유형에 대한 신뢰 문제에 대한 개입입니다. 이제는 런타임 확인을 버리고 컴파일 타임 보장의 힘을 받아들여야 할 때입니다.

CPU가 감사할 것입니다. DevOps 팀이 감사할 것입니다. 사용자들은 (유형 관련 버그를 찾지 않음으로써) 감사할 것입니다.

그리고 가장 중요한 것은 제작 중 유형 오류를 디버깅하는 대신 푹 자고 있는 새벽 3시에 자신에게 감사한다는 것입니다.

---

P.S. 여전히 확신할 수 없다면 코드베이스에 얼마나 많은 런타임 유형 검사가 있는지 세어보세요. 그런 다음 시간당 요금을 곱하십시오. 이것이 바로 TypeScript를 신뢰하지 않고 소비하는 시간입니다.

P.P.S. 이 블로그 게시물을 작성하는 동안 피해를 입은 유형은 없습니다. 여러 런타임 검사가 영구적으로 중단되었지만

*P.P.P.S. 기여하고 싶다면 내 Github에 들러서 저장소를 복제하세요. 모든 것이 아직 신선하므로 기여할 수 있는 기회가 많습니다.

JSR.io에서 사용할 수 있는 문서 및 패키지

위 내용은 TypeScript 개입: Byzantium으로 런타임 확인 중독을 깨뜨려보세요의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!