Http[Request/Response]Data contract classes design discussion about azure-functions-dotnet-worker

[fabiocav]

Adding a quick comment here so this doesn't go unanswered, but will be sharing more, in depth, details on this very soon

A note about the current HttpRequestData and HttpResponseData, the design that is out with the current preview was indeed extremely basic/limiting and not reflective of what we want to support with it. Things that were called out (e.g. the Type used for the body) are not in the final design, which we'll be sharing here and shipping in the next preview.

To add some context, the out-of-proc model is not new in Functions, it is the model that has been used by all of the other stacks, except for .NET. It unfortunately does not expose the rich set of features we need in order to provide the HTTP experience we want to have with the worker from day one, and imposes severe limitations on a lot of the scenarios supported by the HTTP functionality built into .NET, which is something customers would expect. So instead of hacking things around to make it work with the existing HTTP types and having to provide caveats on a number of things wouldn't work as expected (which would lead to a lot of bad surprises and frustration), we are following the same approach used by the other language workers and providing a representation of the HTTP request and response in a way that is very clear that this is not compatible with what you're used to in .NET/ASP.NET. We of course want to make sure those types are as flexible and performant as possible for what they're intended to do, and will be enhancing them prior to GA, as mentioned above.

The good thing about bringing this model to .NET is that we're investing in the out-of-proc integration layer to bring the enhancements required to support the proper HTTP types with all of the capabilities users would expect, which not only will bring back all of the behavior we currently have in .NET, but improve other language experiences as well.

As you've pointed out, a lot of work and time have gone into the existing HTTP stack design and implementation in .NET, and we have no intention to reinvent the wheel. Our approach at the moment is to ensure that we can still handle straight forward HTTP workload requirements without having to wait for the significant amount of work that needs to be done before we light up the rich experience we want, and do so in a way that is clear to customers and won't be impacted by the enhancements we have planned.

With the current and future models, we won't be pinning ourselves against any specific versions of HTTP types (built in .NET types or our data representations). Updates and new versions will be released as Nuget packages (different extension versions) putting customers in control of when they want to upgrade and giving us the ability to adopt new versions as soon as they become available.

We'll be sharing more as we go along, but I hope this helps better understand the current approach and what's on the roadmap for HTTP.

[anthonychu]

Short answer is now that we are running out of process, we’re working with a representation of the http request that came into the function app, not the actual http request itself. We want to be explicit that that’s the case. It also means we don’t have the full capabilities of an http request, so a separate type helps us expose only the functionality that is available.

@drub0y’s feedback is valid and we’ll be looking at expanding HttpRequestData’s surface area to address some of those concerns.

/cc @fabiocav

[Matthewsre]

@anthonychu I have some methods that map results into the desired IActionResult and use that for both Azure functions and App Services that share the same libraries. Currently IActionResult is just being treated as a POCO and the response is returned like this:

{
  "Value": [
    {
      "Id": "e3c30113-eca5-45d9-b66b-c041d77d797a",
      "PartitionKey": "key1",
      "Value": "MyValue"
    },
    {
      "Id": "3f470275-abb8-4da8-b305-5aa38673b203",
      "PartitionKey": "key1",
      "Value": "MyValue2"
    }
  ],
  "Formatters": [],
  "ContentTypes": [],
  "DeclaredType": null,
  "StatusCode": 200
}

This wouldn't be much of a problem if I could just toss the code and value into the HttpResponseData, but as mentioned above it only accepts a string value.

Because of this I must now create another mapper that is also going to handle the serialization, content-type, etc. I would much rather have the serialization managed/configured globally for the function in this scenario and suppose I can probably now do that with my own middleware. Is this something that will be supported in the final v1 without me needing to build custom middleware or mappers?

I was hoping Functions/AspNet would move closer together, and with direct access to the host builder this is a huge step forward, but it looks like this new direction is a big reset and will take quite a while to reach feature parity with the experiences and bindings many of us are used to.

I am very excited for the possibilities this approach opens up, but disappointed it is going to take quite a bit of time before it gets to where it needs to be and is holding back .Net 5 adoption for many of us. Hopefully this can be open sourced soon so others are able to pitch in and contribute :)

[chrisl-za]

I find it amazing that no-one from the worker team has replied to this.

I'd like to know the rationale for the introduction of those classes as well. Just seeking to understand as it does feel like a strange design decision from my outside perspective.

[justinyoo]

As I wasn't able to see the actual implementation/code of HttpRequestData, I'm not sure whether it's safe to say or not:

• Can we have some request metadata like method, scheme (http or https), host and path at some stage?

Because those metadata information is frequently used, I think it should be implemented to HttpRequestData.

[fabiocav]

Transferred the issue to the worker repo so we can continue updating here. The first wave of changes towards the design shared above is in PR right now. Still in draft, as it is being iterated on.