> Markdown version of [/videos/1026-how-aws-generates-polyglot-libraries-based-on-a-single-typescript-codebase?t=426](https://www.wearedevelopers.com/videos/1026-how-aws-generates-polyglot-libraries-based-on-a-single-typescript-codebase?t=426). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# How AWS Generates Polyglot Libraries Based on a Single TypeScript Codebase

How did AWS scale the CDK across Java, Python, .NET, and Go without duplicating code? Discover their open-source JSII toolchain that turns one TypeScript codebase into native polyglot libraries.

- **Speakers:** [Markus Ziller](https://www.wearedevelopers.com/@markus-ziller)
- **Event:** World Congress 2024
- **Published:** August 20, 2024
- **Duration:** 26:11
- **URL:** https://www.wearedevelopers.com/videos/1026-how-aws-generates-polyglot-libraries-based-on-a-single-typescript-codebase

## Summary

Modern microservice architectures often result in engineering teams utilizing multiple programming languages, which complicates maintaining cross-cutting concerns like internal tooling, logging, or Infrastructure as Code (IaC). Amazon confronted this challenge while scaling the AWS Cloud Development Kit (CDK). Realizing that manually duplicating the framework to support Java, Python, .NET, and Go users would be unsustainable, AWS needed a mechanism to maintain a single source of truth while meeting developers in the languages they natively use.

To solve this, AWS built JSII, an open-source interoperability toolchain that allows developers to write a library once in TypeScript and generate native bindings for other languages. Rather than directly transpiling source code—which often fails across differing language paradigms—JSII relies on a cross-language execution host. At build time, JSII compiles the TypeScript codebase into JavaScript, generates a robust `.jsii` metadata file describing the types and interfaces, and leverages the `jsii-pacmak` utility to build and publish native packages across diverse package managers like Maven or PyPI.

At runtime, JSII executes the core JavaScript logic inside a dedicated Node.js child process, while the host language (e.g., Python or Go) runs natively in its own runtime. Communication between the two happens via STDIN/STDOUT, marshaling and unmarshaling payloads as JSON. While JSII successfully enables rapid polyglot SDK development and underpins the massive ecosystem of the AWS CDK, its architecture enforces distinct tradeoffs. Engineers must navigate non-idiomatic syntax requirements (such as overcoming Go's composition preference over inheritance), tolerate limited documentation during setup, and absorb a "latency tax" caused by continuous JSON serialization, making the framework ideal for DevOps tooling and IaC abstractions rather than latency-sensitive execution paths.

**Keywords:** aws cdk, jsii framework, polyglot libraries, typescript transcompilation, infrastructure as code, microservices decomposition, cross-language interoperability, jsii-pacmak, node.js inter-process communication, json serialization tax, multi-language sdk development, cross-cutting concerns, devops tooling, language bindings generation, native package management, cloudformation templating

## Chapters

1. **Scaling microservices with multi-language cross-cutting concerns** (00:00) — Decomposing monolithic business architectures creates technical overlap and shared tooling challenges across multiple programming languages.
1. **Managing infrastructure as code with AWS CDK** (02:26) — The AWS Cloud Development Kit replaces complex CloudFormation declaration templates with functional programmatic resource definitions.
1. **Building hierarchical infrastructure constructs with AWS CDK** (04:03) — Combining individual cloud resources into higher-level logical constructs automates complex cloud infrastructure provisioning operations.
1. **Scaling developer adoption by supporting additional programming languages** (05:47) — Expanding open-source availability beyond initial typescript logic fulfills diverse customer technical and platform deployment requirements.
1. **Enabling cross-language library interoperability with the JSII framework** (07:06) — The JSII toolchain facilitates seamless interactions with native typescript processes directly from external runtime environments.
1. **Understanding JSII compiler operations and architecture components** (08:20) — Generating language-agnostic frameworks requires a compiler build step that isolates core class and type metadata mappings.
1. **Developing a foundational TypeScript catalog application** (09:30) — Standard applications written with standard typescript logic operate as the underlying functionality payload model.
1. **Configuring package manifests to invoke JSII compilation** (10:29) — Modifying module manifest file attributes with required framework definitions establishes functional code bindings execution models.
1. **Building and distributing polyglot libraries with JSII Pacmak** (12:43) — Specialized toolchains process generated typescript metadata completely automatically into globally deployable, native package manager artifacts.
1. **Adhering to strict typing constraints for Java bindings** (13:42) — Translating typescript methods into strictly typed Java interfaces mandates strategic naming conventions to bypass rigid compiler restrictions.
1. **Bridging dynamic typing paradigms for Python cross-language libraries** (15:08) — Enforcing type safety during flexible runtime execution heavily dictates establishing intentionally non-idiomatic library interaction techniques.
1. **Resolving structural execution differences in C# and Go bindings** (16:33) — Translating javascript object inheritance designs into composition-heavy ecosystems forces developers into adopting explicitly unique syntax workflows.
1. **Implementing generated polyglot bindings in target applications** (18:08) — Acquiring compiled package artifacts enables simple external invocations capable of natively rendering underlying logic computations.
1. **Mapping runtime execution models with background node processes** (19:10) — Invoked native libraries resolve class methods accurately by streaming marshaled JSON operations continuously against nested Node hosts.
1. **Evaluating development advantages in multi-language ecosystems** (22:00) — Single-source polyglot library foundations lower operational redundancy rates across separated engineering teams rapidly building specialized tools.
1. **Assessing JSII latency overhead and complex debugging concerns** (23:21) — Constant execution serialization loops heavily tax raw compute latency metrics while framework abstractions routinely complicate critical troubleshooting.
1. **Determining effective deployment patterns for JSII framework implementations** (24:42) — Centralized software abstractions focusing heavily on internal systems engineering or cloud operations present highly ideal implementation scenarios.

## Related Moments

- [Lambda compatibility, interface security, and career advice](https://www.wearedevelopers.com/videos/873-interface-contracts-in-microfrontend-architectures) (from "Interface Contracts in Microfrontend Architectures")
- [Expanding JavaScript horizons with WebAssembly and backend possibilities](https://www.wearedevelopers.com/videos/118-how-to-stop-choosing-javascript-frameworks-and-start-living) (from "How to Stop Choosing JavaScript Frameworks and Start Living")
- [The origins and early problems solved by TypeScript](https://www.wearedevelopers.com/videos/100061-typescript-features-that-changed-the-game) (from "TypeScript Features That Changed the Game")
- [Bringing JavaScript developers into web artificial intelligence](https://www.wearedevelopers.com/videos/1896-how-web-ai-can-power-the-agentic-web-jason-mayes-google) (from "How Web AI Can Power the Agentic Web - Jason Mayes (Google)")
- [Moving from the .NET ecosystem to JavaScript and Go](https://www.wearedevelopers.com/videos/902-coffee-with-developers-brian-morrison) (from "Coffee with developers - Brian Morrison")
- [Audience Q&A on language support, performance, and tradeoffs](https://www.wearedevelopers.com/videos/588-using-webassembly-for-in-database-machine-learning) (from "Using WebAssembly for in-database Machine Learning")

## Related Articles

- [Dev Digest 136 - No JS(on) of mine](https://www.wearedevelopers.com/magazine/482-dev-digest-136-no-js-on-of-mine)
- [Dev Digest 131 - AI'm not sure about OSS](https://www.wearedevelopers.com/magazine/472-dev-digest-131-ai-m-not-sure-about-oss)
- [Web Development Best Practices: What The Data Tells us](https://www.wearedevelopers.com/magazine/84-web-development-best-practices-what-the-data-tells-us)
- [How we Build The Software of Tomorrow](https://www.wearedevelopers.com/magazine/120-how-we-build-the-software-of-tomorrow)

## Related Jobs

- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/15942-senior-software-engineer) at **GitHub**
- [Principal Software Engineer, Enterprise AI Platform](https://www.wearedevelopers.com/jobs/ext/1467292-principal-software-engineer-enterprise-ai-platform) at **GitHub**
- [Staff Software Engineer, Copilot Experiences](https://www.wearedevelopers.com/jobs/ext/164361-staff-software-engineer-copilot-experiences) at **GitHub**
- [Agile Full Stack Engineer](https://www.wearedevelopers.com/jobs/48325-agile-full-stack-engineer) at **synava GmbH**
- [Staff Software Engineer](https://www.wearedevelopers.com/jobs/ext/1425755-staff-software-engineer) at **GitHub**
- [Senior Software Engineer, Enterprise Products](https://www.wearedevelopers.com/jobs/ext/1841248-senior-software-engineer-enterprise-products) at **GitHub**