1

With .Net 5, Azure Functions require the host to be instantiated via Program.cs

class Program
{

    static Task Main(string[] args)
    {
        var host = new HostBuilder()
            .ConfigureAppConfiguration(configurationBuilder =>
            {
                configurationBuilder.AddCommandLine(args);
            })
            .ConfigureFunctionsWorkerDefaults()
            .ConfigureServices(services =>
            {
                services.AddLogging();
            })
            .Build();

        return host.RunAsync();
    }

}

If I was to add some global variables in Program.cs (say static) so that they can be accessed by any of the endpoints in the Azure Function project, if the global variable value was changed during the execution of one of these endpoints, is there a chance (even small) that this update propagate into the execution of another endpoint executing just after? I struggle to understand to what extent the Host is concurrent.

These were useful readings, but I did not find what I was looking for:

Ama
  • 1,373
  • 10
  • 24

1 Answers1

1

See Azure Functions as stateless workers. If you want them to have state either use Durable Entities or external storage. Implementations can change, even of the underlying Azure Functions runtime. Design accordingly is my advice.

Static global variables are often a bad idea. Especially in this case you can't reliably predict what will happen. The process can be killed, new instances can be brought up / taken down possibly spanning multiple machines due to dynamic scaling. So different executions can see different values of the static variable.

Again, you should design your functions in such a way that you do not have to worry about the underlying mechanisms, otherwise you will have a very tight coupling between the code and the hosting environment.

Peter Bons
  • 26,826
  • 4
  • 50
  • 74
  • Thanks Peter, this is in line with the direction I was taking. I need a static field to store the identity of the request caller, via some sort of middleware mechanism which verifies and then stores the identity as an "environment variable". The static field is now only a factory, which could be injected via DI but for the purpose it would be overkill. – Ama Sep 23 '21 at 14:46
  • @peter-bons So if I have a Queue triggered Function, that needs to get a BearerToken from a target server, is it not possible to store the BearerToken some where "globally" or where it can be shared by other instantiated AZ Functions? Or do I really need to think like you said as stateless workers, and for each triggering of the AZ Function, I need to call the target server to get a BearerToken every time? Thus not being able to "reuse" an existing BearerToken. – Oliver Nilsen Jan 17 '23 at 08:04
  • @OliverNilsen you could have a second token system which identifies your ServerBearerToken. Say at the first call your function calls the server and gets the token, then it stores it into a cache where the token can be accessed by a guid. Your function returns this guid to the user, and then any subsequent call from that same user would provide the guid so that your function can then retrieve the token from the cache. Works similarly to a website session system. You may want a cryptographic guid and a cache expiration policy to protect your BearerTokens. The cache could be NoSQL, etc. – Ama Jan 18 '23 at 10:50
  • @Ama So you are basically saying that I could store the BearerToken in a Redis cache. That could be an option. – Oliver Nilsen Jan 18 '23 at 20:34
  • Redis or any other caching system. I would just be particularly careful with the risk of leaking your ServerTokens; depending on how sensitive they are. – Ama Jan 19 '23 at 07:56