JeffC
My feedback
-
71 votes
No plans for this one, but please keep the votes coming!
An error occurred while saving the comment JeffC
supported this idea
·
-
1,218 votes
Thank you for the feedback, we are reviewing this feature request.
An error occurred while saving the comment JeffC
commented
Just had another project defer gRpc because of lack of support on Azure App Services.
I'm getting more and more interest in moving to gRpc architectures but many project owners don't want to sacrifice using App Services.
An error occurred while saving the comment JeffC
commented
Unfortunately we've already had to skip on gRPC for a project because it won't run on Azure App Service.
And there's another where the owners are considering now not using Azure App Service because they really want gRPC.
I'll probably be facing more of these opportunities next year. I'm hoping that there will be progress on this at some point in the near future.
An error occurred while saving the comment JeffC
commented
This is holding up several projects to move from rest to grpc. (Because we require rest fallback for some older consumers)
JeffC
supported this idea
·
-
26 votes
Upvotes: 43
An error occurred while saving the comment JeffC
commented
AT TIME ZONE is slow enough that I just avoid it and use .NET TimeZoneInfo methods to convert at the client application.
If SQL could deliver the performance at least equal to client applications using TimeZoneInfo I'd be included to use it frequently.
JeffC
supported this idea
·
-
9 votes
Upvotes: 2
JeffC
supported this idea
·
-
170 votes
Thanks for feedback. We are planning on adding DateTimeOffset in addition to the new functions we’ve already released.
Thanks.
An error occurred while saving the comment JeffC
commented
This would be extremely helpful. We have to use DateTimeOffset for proper date handling and display throughout our application and SQL Server does it quite well. But I want to move part of our application over to Cosmos DB and can't do it until there is support for DTO.
JeffC
supported this idea
·
-
65 votes
Leaving as started becasue we don’t have full docs out yet but this is completed. Just need to document and provide samples
JeffC
supported this idea
·
An error occurred while saving the comment JeffC
commented
I can see how this would be useful in some situations. I guess you'd have to have a setting for the max number of items to fetch from SB. Then your main function method (Run) would need to have the arguments expect a list of message objects.
-
112 votes
This is currently on our radar and is now planned work. Thanks for voting!
- Cary, Azure Functions
JeffC
supported this idea
·
An error occurred while saving the comment JeffC
commented
For sure Azure SQL. We're using Service Bus as a go between now but it would be better to have a SQL trigger.
-
88 votes
Here’s the latest as there seem to be 2 types of ask here and so two seperate updates. Need comments for if this issue should close to be focused on one or other:
1. I want to control how many calls my function can make to another API (the 3rd party API rate limiting).
– In all plans we now have a way to specify the max instances. This can limit how far a function app instance can scale: https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#limit-scale-out2. I want to stop my function from triggering more than x times an hour.
Nothing planned in this in the short term. Using API Management for HTTP functions with throttles would be our recommendation for HTTP, nothing out of box for non-HTTP triggers yet.JeffC
supported this idea
·
An error occurred while saving the comment JeffC
commented
I'd like to have this ability to protect our functions from misuse.
-
16 votesJeffC
shared this idea
·
-
245 votes
An error occurred while saving the comment JeffC
commented
This is the #1 missing feature that prevents me from going live with Azure Scheduler. I have jobs that need to run at specific local times across timezones all around the world.
Examples: job1 run at 3am PST Los Angeles, job2 run at 3am EST New York, job3 run 3am IST Dublin.
For a scheduler to work for our needs there must be the ability to schedule the job to run in a specific timezone and then the scheduler must account for daylight savings time to be sure the job always runs at the correct local time.
We are using a home grown scheduler that is short on features and I'd like to leave it to run on Azure but timezone and DST support is a showstopper for us. Our homegrown system has been able to handle this for years. A few lines of C# can handle the conversion between future job schedule time and UTC and will account for what the target timezone DST offset will be (if any) at the scheduled date and time.
Agree. gRPC is important and I've had several projects face choosing between gRPC vs Azure App Services and Azure Functions because those services don't support gRPC.
It is my understanding that the problem is due to lack of support in Http.sys for HTTP/2 response trailers which are required for using gRPC.
I believe a big part of the problem is that we're dealing with multiple MS teams here. There is a version of Http.sys in Windows Server vNext insider builds that is compatible with gRPC HTTP/2 requirements.
Great! But does that mean we have to wait until there's a new Windows server release? And likely some time after that as the App Services team will need time to prepare and test its version(s).
My thoughts are the someone at MS should have seen this coming a long time ago and gotten the compatible Http.sys into earlier server builds.