> I tend to think of microservices as mostly good for solving organizational problems Yeah, they're frequently used for that. In the case of my cloud service,

> I tend to think of microservices as mostly good for solving organizational problems Yeah, they're frequently used for that. In the case of my cloud service, though, there are multiple pieces that are beneficial to scale independently (browser servers, WebRTC servers, functions for orchestration, and functions for the user-facing web-based administration). I also want to put as much onto AWS Lambda as possible to simplify scaling, but the stateful browser and WebRTC services can't run on Lambda. > That said, I still don't really understand why you'd use TypeScript on the server at all if you need C# for other services That's fair. One reason is that I feel that I develop the fastest with TypeScript. Another is that I develop the web front-end in TypeScript and like being able to share code for the web-related parts. Another is that I like to leverage AWS Lambda for the non-stateful parts, and Lambda's cold start times for Node are lower than those for .NET, which can help provide lower latency for user-initiated web requests. > In particular, it sounds like it'd be necessary to write wrappers on both ends, so that you have idiomatic C++ or C# everywhere except at the boundary. Yeah, you're right. The parts that C# calls must C linkage, so C++ functions must be wrapped in `extern "C"`. My understanding is that C is the lingua franca between languages because it has a simple ABI, whereas the ABI for C++ is complex and may between compilers.