Azure Function Project Structure (C# vs CSX) and Best Practices

Question

Recently I got other developer Azure function code written in C# Script (.csx), I used to write Azure function using visual studio.

I love C# Script imperative binding, it make code more easy (no need to manage connections)

I saw some problem with C# Script

1. Code quality tool doesn't works (StyleCop/Sonar)
2. Can't write unit test against .csx file

If you have a different opinion, Please share.

So I decided that I will convert all functions(10) into .net project with sonar integration and UnitTest.

Question My most of functions not having any business logic they are getting triggers from EventHub and dumping data into cosmos DB, I'm not able to decide should I create 10 projects or 1 project under single solution?

I believe single project with multiple function having single host.json file, If I will change host.json value for scaling particular function, it will impact other function as well. Am'I right?

Number of function = number of project is a correct solution?

How it would impact cost?

Answer 1

Personal opinion is the CSX files are fine for experimenting or something quick and dirty but for production you should be using compiled c#.

Adjusting any setting in the host.json file will impact all functions within that function app. There is no universally correct answer on when to break out your function into separate apps but there are a few questions you can ask to help answer it for your scenario:

1. Does a particular function have a dramatically different scaling characteristic then the other function(s). (e.g. does one of your message triggers get very different message volume or processing logic then others - do you need to change the host.json)
2. Is your function doing a separate business process then the other functions (e.g. one is receiving device telemetry messages while the other is handling audit telemetry)
3. Do #1 and #2 justify the management and devops overhead of creating a separate function app (lots and lots of functions apps, especially in micro-service like architectures can be a challenge to manage)

In your case you have some flexibility with your function apps because they are just message listeners they aren't impacted as much as say http triggers if you find you want to break out the function into a separate app later (e.g. http endpoints changing).

Answer 2

Your overall idea to move to precompiled projects makes sense. That's recommended by Microsoft for all but simplest ad-hoc Functions.

Single project vs multiple projects should be decided based on whether you want a single Function App or multiple Apps. Function App is a scaling unit. If you want multiple Functions to scale independently, they should be in separate Apps and projects.