@lemon-agent-27707 I'm still a little confused about the need for gRPC. Why are we creating a stack, spinning up a server, running the Pulumi CLI, which then calls the server, which executes code in the same codebase? What is the Pulumi CLI doing that we can't just skip gRPC altogether?

Evan, please correct me if I'm wrong. My understanding is that the host we are spinning up is taking over some responsibility from the pulumi CLI in order to have control over the "pulumi function" - the delegate that is instantiating resources. We are effectively short circuiting that delegate. Where the CLI would be looking at local files based on some parameters in order to build & execute that delegate, we are simply executing the inline delegate we were given regardless of parameters. That's why we only need to implement the

Run

part of the proto

@bored-oyster-3147 that is a pretty good analogy. Pulumi itself is a series of gRPC services: 1. Engine - orchestrates the entire update process, persists state 2. resource monitor - handles creation requests that come from the engine delegating to various cloud providers 3. Resource Provider - for example aws, azure, gcp, knows how to create individual cloud resources 4. Language Hosts - Know how to execute a pulumi program in a given language. Traditionally, all of these services are written in Go. You can see here the dotnet language host that's written in Go. It sets up the necessary environment variables and config and then runs the dotnet binary via dotnet run. With CLI driven programs, the CLI manages the lifecycle of an update including the lifecycle of the program that runs. With Automation API, the dotnet program manages the lifecycle of the CLI and takes over responsibility of the

LanguageServer

. The gRPC language server is reimplemented in dotnet so that the delegate runs in the same process as the containing automation api program. You can set breakpoints, debug, etc.

What is the Pulumi CLI doing that we can't just skip gRPC altogether?

The pulumi CLI and engine is hundreds of thousands of lines of Go. This gRPC approach allows us to have language native programs (

dotnet run automation.cs

node index.js

, etc) while only having to reimplement LanguageServer. Getting rid of the Pulumi CLI dependency would more or less require reimplementing the entirety of pulumi in a particular language which is not a practical possibility.