Azure
Provide gRPC as a configurable endpoint trigger
Probably depends on #738 (at least evaluating how it interacts with billing). Definitely depends on the wider Azure infrastructure supporting HTTP/2. HTTP/2 is now supported by API Gateways, although it's off by default (and it's not clear how far this support extends).
Will almost certainly require work in the various host/runners to provide the necessary support.
@Clockwork-Muse Can you provide more detail on the value proposition (perhaps some example scenarios that would benefit from this) and what you would expect the programming model to look like (e.g. an example function using this trigger)?
Well, there are performance arguments to make, but I feel that's somewhat of a minor point to try to reach for.
Many of the benefits follow from the use of WebSockets and HTTP/2 generally - the ability to keep a connection between client and server open, bidirectional streams, and closer-to-native async/cancellable code. Further, it has interesting implications for load balancing, because some of the current function hosts are actually set up as gRPC endpoints.
For the programming model, many simple cases are liable to look not materially different than they do today (taken from the gRPC getting started samples):
public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
{
return Task.FromResult(new HelloReply { Message = "Hello " + request.Name });
}
Some of the real benefits happen for cases that gRPC handles well, like streaming results back to the client (from the gRPC streaming tutorial):
public override async Task ListFeatures(Rectangle request,
IServerStreamWriter<Feature> responseStream,
ServerCallContext context)
{
var responses = features.FindAll(feature => feature.Exists() && request.Contains(feature.Location));
foreach (var response in responses)
{
await responseStream.WriteAsync(response);
}
}
To do this currently requires manually allocating a queue the client can tap into, or as a binary blob. Except a queue object would be shared, whereas a gRPC stream is part of the connection, and the binary blob would require manual de/serialization.
Thanks. I agree with your linking to #738 as some of the challenges I mentioned there apply here too - websockets and GRPC are stateful protocols while functions has a stateless programming model and it is not exactly obvious how to reconcile the two. That simple server side streaming example could probably be adapted to work OK with the functions programming model because its not that hard to define the "start" and the "end" of the execution. But take the bidirectional streaming example and its much tougher...
Agreed.
Now, I imagine simple request/response would comprise probably 90% of use cases, so it might be possible to expose just that capability (certainly all of my stuff falls into that category for now), but even that is likely to take a while.
Been doing some work on Azure Functions and gRPC separately. Now those efforts want to combine. Any update on an endpoint trigger for gRPC?
Is there some updates on this thread? With C# 9 drastically improving the performance of gRPC, we really need this as and endpoint. I'm ready to use it on production environments
There's no ETA for this functionality, but I can at least spell out some of the things that would need to happen to make it a reality:
- App Service needs to support gRPC (since Azure Functions and App Service run on the same infrastructure). There is a user voice item for that here. I believe that has its own set of dependencies, one of which is the work described here.
- Determine whether scoping down to shortlived request/response patterns is enough. If so, it fits well with the functions programming model, which is stateless and also would fit well with the consumption billing model that requires an explicit start/stop event and has a max execution time.
- Build the gRPC trigger implementation based on wherever we end up on point 2
- Figure out how to best handle dynamic scaling for gRPC workloads and get that implemented.
@paulbatum was there any update in the last 4 months? Its wired to see no progress on such an important topics for so a long time.
I'm not aware of any changes. I believe that App Service support for gRPC is still the major blocker.
I'm not aware of any changes. I believe that App Service support for gRPC is still the major blocker.
@paulbatum Is it possible to deploy an ASP.NET gRPC service to an Azure App Service? If so, would that provide the basis for the Azure Function functionality? I'm also very interested in being able to have gRPC as an Azure Functions trigger. Thanks!
are there any updates on this? Or are we still waiting on App Service support for gRPC?
Oh man. Patience is a virtue. In the meantime, . . . Here's the link to some of the related feedback.azure.com ideas (do we still call it user voice?):
Please up vote those.
Support for short lived gRPC request/response scenarios would be good enough for the use cases where I see gRPC being a good fit for use with Azure Functions. Streaming seems like a different can of worms. Maybe best fit for some new kind of Azure Function, if any.
I agree with @bryanknox that even partial support of gRPC would be awesome - though maybe a bit confusing for developers, I can imagine the sheer number of warning boxes on the docs page explaining the caveats, haha.
Personally, I like gRPC because of the rich tooling associated with it by default in .NET. Things like the automatic clients generated from the protos are excellent, and massively easier to work with than the Swagger/OpenAPI alternative. I don't need the bi-directional streaming that the full spec provides - which I imagine is very difficult to map to the consumption-based stateless function model anyway.
I wonder if a shorter-term solution of supporting the gRPC-Web protocol via an extension to the SDK set would be something the community would accept? Since gRPC-Web does not require HTTP2, I'm guessing it might not need infrastructure changes (unless I'm way off the mark). The support for server->client streaming might also hit a lot of developer's requirements as well, with the caveat of the maximum function runtime under consumption plans, of course.
