History: Principles of In-process Functions

Previously your Function code and the Azure Functions runtime shared the same process. It's a web host, and it's your Functions code, all running in one process.

The runtime handled the inbound HTTP requests by directly calling your method handler.

Background: Principles of Isolated Functions

The Azure Functions Host runtime is still responsible for handling the inbound HTTP requests. But, your Functions app is a totally separate .NET application, running as a different process. Even in a different version of the .NET runtime.

If you run it locally you'll see two processes:

1. The Functions Host process (Func.exe on Windows, dotnet WebHost on Debian Linux)
2. A separate .NET process launched with your Functions app

Your Isolated Functions app isn't too much different from a console app. It's definitely not a web host.

This makes even more sense when you consider that the entrypoint is Program.cs. It's clear that no other code is involved in initialising your app. That's quite different from In-process where you define a Startup class - i.e. a method called by the Azure Functions runtime code because they're part of the same process.

Actual answer: How the pipeline works

So if your Functions are running in something similar to a console app, how is it handling HTTP triggers if it's not a web host any more?

The answer is that your Functions app, although isolated, has a gRPC channel exposed. The Functions Host process handles the HTTP requests for you, and passes them to your Functions app through the gRPC channel.

The gRPC channel in your Functions app isn't obvious, and it's not something you explicitly open or have control over. You might stumble across it in a stack trace if you hit a breakpoint or have an unhandled exception.

The pipeline becomes:

1. Host process receives HTTP request
2. Host process calls your Functions app via gRPC
3. Functions app calls your Middleware classes, if you registered any
4. Functions app calls your Function method, and you return a response
5. Functions app returns the response back to the Host process via gRPC
6. Host process returns the HTTP response back to the caller

Other notable differences in the pipeline

As mentioned above, Isolated lets you add your own Middleware classes into the processing pipeline. These run in your Function code immediately before the actual Function method is called, for every request. In-process had no convenient way to achieve this.

Even though your Functions aren't handling the HTTP call directly, helpfully your Middleware classes can still access a representation of the HTTP request that's passed in from the Host. This enables you to check HTTP headers, for example. It's particularly useful in your Middleware classes because you can perform mandatory tasks like authentication, and it's guaranteed to execute before handling the request.

host.json

This part of your question has a good answer here: https://stackoverflow.com/a/79061613/2325216

References

https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-in-process-differences https://github.com/Azure/azure-functions-dotnet-worker