My TypeScript apps talk to Python ML services every day and neither side knows the other's internals. That's on purpose.

My TypeScript apps talk to Python ML services every day, and neither side knows a thing about the other's internals. That's the design.

The best ML libraries live in Python. My best product velocity lives in TypeScript. Forcing one language to pretend it's the other is where these systems go wrong. So I put a clean wire contract between them instead.

My job scraper's heavy lifting runs in a small Python service that wraps a scraping library and exposes one endpoint returning normalized rows. The TypeScript side depends only on that row shape. It never touches the Python package, its version, or its quirks. I can swap the scraping library underneath and the TypeScript app never notices, because all it was ever promised was the contract.

The vision and quant services follow the same pattern. Python does what Python is good at, TypeScript orchestrates the product, and a typed contract sits on the boundary so the two halves never rot into each other.

That's how you ship polyglot systems that stay maintainable. Pick the right language per job, then isolate the seam.

Building across Python and TypeScript? Ask me how I keep the boundary clean.