TypeScript

TypeScript has transformed how FSS Technology builds large IoT platforms. Where JavaScript gives engineers flexibility, TypeScript gives them confidence — compile-time verification that the telemetry schema a Node.js ingestion service expects matches what a React dashboard displays, that an MQTT payload interface defined for an ESP32 device matches the handler that processes it in the cloud. In connected device platforms where data shape mismatches between firmware, backend, and frontend layers have historically caused silent data corruption and operational incidents, TypeScript’s static type system is not a luxury — it is a safety net. FSS has standardised on strict TypeScript for all new IoT platform development since 2019.

Advantages of TypeScript in IoT Projects

Compile-Time Safety for IoT Data Schemas

IoT platforms are fundamentally about structured data flowing between layers: firmware defines a telemetry payload format, a backend service validates and processes it, a database stores it, and a frontend displays it. In a pure JavaScript stack, each layer maintains its own implicit understanding of the data structure, and discrepancies between these understandings cause runtime errors — often silent ones that produce incorrect values rather than exceptions. TypeScript interfaces make the data structure explicit and shared, and the TypeScript compiler verifies that every layer correctly handles the agreed structure.

FSS defines TypeScript interfaces for every MQTT payload schema, REST API request/response body, database document shape, and WebSocket message type. When device firmware is updated to add a new telemetry field, the TypeScript interface is updated in the shared @fss/device-types package, and the TypeScript compiler immediately identifies every location in the backend and frontend codebase that needs to handle the new field. This prevents the scenario — common in JavaScript IoT platforms — where a firmware update silently breaks telemetry display in a dashboard because the frontend code was never updated to handle the new data shape.

Shared Interfaces Across the Full Stack

TypeScript’s ability to share type definitions across frontend and backend via npm packages is uniquely valuable in IoT platforms where the same data structures appear in multiple layers. A DeviceTelemetryReading interface defined once in @fss/device-types is imported by the Node.js MQTT ingestion service that validates incoming messages, the InfluxDB writer that serialises records to storage, the REST API handler that serves historical data, the Zustand store in the React dashboard that manages live readings, and the React component that renders gauge values. All six consumers are statically verified to correctly handle the same structure. Adding a field requires one interface update and a compiler run to find all consumers.

This shared-type architecture has a measurable impact on development velocity at FSS. Integration testing between backend and frontend layers catches fewer runtime type errors because compile-time checking catches them first. Code reviews are faster because reviewers can rely on the type system to enforce correct data handling rather than manually verifying it. New engineers onboarding to a TypeScript IoT platform can navigate the codebase more confidently because TypeScript’s IntelliSense integration in VS Code provides immediate feedback about data shapes at every point in the code.

Refactoring Confidence in Long-Lived Platforms

IoT platforms are typically long-lived systems that must evolve over years as device fleets grow, new sensor types are added, and product requirements change. Refactoring a JavaScript codebase after 3 years of accumulated changes is a high-risk operation — any rename, restructure, or interface change can silently break consumers in distant parts of the codebase. TypeScript’s type system makes refactoring safe: renaming a property in a TypeScript interface, running the compiler, and fixing every red error the compiler reports is a reliable, complete refactoring process. FSS IoT platforms that have been in production for 4+ years have been safely extended with new device types and features because TypeScript’s type system makes the scope of each change visible.

MQTT Event Schema Typing

MQTT-based IoT communication involves a hierarchy of topic patterns and associated payload schemas. TypeScript enables FSS engineers to model this hierarchy explicitly: a union type where each topic pattern maps to a specific payload interface, and a discriminated union that the TypeScript compiler narrows correctly based on the topic string. An MQTT message handler that switches on topic pattern and processes the payload gets full type narrowing — within the case 'devices/+/telemetry/temperature' branch, TypeScript knows the payload is a TemperatureReading interface, not a generic unknown type.

This level of type safety for MQTT processing is particularly valuable when a single Node.js service subscribes to wildcard topics and handles multiple device types with different payload schemas. TypeScript makes the handling code self-documenting — each case in the topic switch statement is a named, typed interface — and prevents the class of bug where a handler incorrectly accesses a field that exists in one payload type but not another.

Decorator Support for IoT Service Architecture

TypeScript’s experimental decorator support, used extensively by NestJS, enables a declarative programming model for IoT backend services that is significantly more readable than equivalent imperative code. NestJS’s @MessagePattern() decorator on a controller method declares that method as the handler for a specific MQTT topic without boilerplate registration code. @InjectRepository() declares database repository injection. @Cron() declares scheduled tasks. This decorator-driven architecture makes IoT backend services self-documenting — reading a NestJS controller reveals immediately which topics it handles, what it injects, and when its scheduled tasks run.

Limitations and Considerations

Initial Setup Overhead

TypeScript requires a build step that pure JavaScript does not. Configuring tsconfig.json correctly, setting up ts-node or tsx for development execution, integrating TypeScript compilation into CI/CD pipelines, and training developers unfamiliar with TypeScript adds initial project overhead. FSS’s internal TypeScript project templates absorb most of this overhead, but teams starting TypeScript adoption from scratch should budget for a setup and training phase.

Strictness Requires Discipline

TypeScript’s benefits are proportional to the strictness of its configuration. A TypeScript codebase with strict: false, pervasive any type usage, and unenforced type assertions provides little more safety than JavaScript. FSS enforces strict: true in all TypeScript projects and prohibits any usage via ESLint’s @typescript-eslint/no-explicit-any rule, but projects that adopt TypeScript without these guardrails often find the type system provides less value than expected.

Generated Types Can Become Stale

TypeScript interfaces for IoT device schemas that are generated from external sources — OpenAPI specifications, device twin schemas, database ORM models — can become stale if the generation process is not integrated into the CI/CD pipeline. FSS automates type generation as part of the build process for all IoT projects that use generated types, ensuring the TypeScript interfaces remain in sync with the source of truth.

TypeScript IoT Patterns at FSS

FSS Commitment to TypeScript

FSS Technology made TypeScript the mandatory language for all new IoT platform development in 2019 after several years of experience with the maintenance challenges of large JavaScript IoT codebases. The transition required training investment and initial productivity adjustment, but the long-term benefits — fewer production incidents related to data shape mismatches, faster and safer refactoring, improved developer onboarding — have consistently justified the investment on every subsequent project. Every FSS engineer working on IoT platform development is proficient in TypeScript, and our internal code review process enforces TypeScript best practices on every pull request. If you are considering TypeScript for your IoT platform or want to migrate an existing JavaScript codebase to TypeScript, FSS can advise on migration strategy and provide hands-on engineering support.