TypeScript Ends at Runtime: Validate Your Boundaries
TypeScript catches mistakes during development, but external data still needs runtime validation.
TypeScript can prove that your code uses a value consistently, but it cannot prove that an API, form, environment variable, or database returned the value you expected. Type annotations disappear when JavaScript runs. Writing "as User" changes the compiler's opinion; it does not change the data.
Treat every external boundary as unknown. Parse request bodies, URL parameters, webhook payloads, environment variables, and third-party responses before using them. A schema validator can produce a trusted type only after the runtime checks pass. This prevents malformed values from travelling deep into the application and failing far from their source.
Validation should describe business constraints, not only primitive types. An email must be a valid address, a page size must be within a safe range, and an enum must contain one of the supported values. Normalize intentionally: trim fields where whitespace is meaningless, but do not silently rewrite data when the user should see an error.
Return useful errors without exposing internals. API clients benefit from a stable error code, field path, and human-readable message. Logs can include diagnostic context, but passwords, tokens, and complete private payloads should never be recorded.
Avoid validating the same object everywhere. Validate once at the boundary, then pass the parsed domain value into the rest of the system. Internal functions can rely on their types because the untrusted input has already crossed a guarded boundary.
TypeScript is still doing essential work: it keeps trusted values consistent after parsing. Runtime validation and static typing are not competing approaches. Together, they form a complete contract from unpredictable input to predictable application code.
