I’ve heard about Azure Functions a lot and even more about Serverless as a concept. Why have I started this article with both of them? Well, the reason is very simple – I’ve changed projects recently and fell in love with Azure Functions yet again. So, let’s get back to the question of what are those, actually?

AZURE FUNCTIONS

Azure Functions are simply speaking functions (duh!) run in Azure with a specific trigger. The most common ones are run on a simple timer, but they can actually be triggered by HTTP (yes, you can easily build a CRUD REST API on Azure Functions alone), Service Bus, IoT Hub, Event Grid, and a few more, and they obviously offer a bunch of integration with Azure environment. Probably the main advantage of them from a developer’s perspective is that they are dirt-cheap to run and that’s because they are Azure’s implementation of Serverless.

I recall the first time I’ve heard about Serverless and thought the name was stupid, because it is still a hosted solution, so it does require a server, even though it doesn’t need an always-running host. With the scale of Azure, and the ability to tear down and raise up hosts quickly depending on the actual need, it becomes a huge advantage, which I wasn’t able to comprehend during my first encounter with Azure Functions. By their very nature, Serverless solutions do not require specific hosts, which limits their capabilities (as in: you cannot depend on host configuration) but raises their scalability dramatically, because you can easily run thousands of instances whenever you want.

Serverless (and Azure Functions) are scalable by their nature.

Azure Functions are powerful, very cost-effective, and just great to use, even though you have to adjust your mindset to use them because you need to write code, which is actually stateless.

REACT

I come from a desktop application background and have switched to web technologies, as the industry moved that way in my opinion. The thing that irritated me when writing XAML is two way binding of properties. The idea is great in theory, and it makes creating UI quite simple (I even fondly remember the days of designing XAML with a drag and drop interface – that was fun), but it’s hard to debug. Don’t get me wrong – it’s possible (I mean how hard is setting a breakpoint on get / set in property really?) and it probably comes down to personal preference but debugging a one-way flow seems just plain simpler, and I am a huge advocate for KISS rule (keep it simple stupid). I’ll always pick simpler solutions, even if writing them might take a few more minutes, because it always is worth it afterwards, when you inevitably will have to resort to debugging or just reading the code (that’s also a reason why I’m against too many abstractions, too many inheritance levels, or even automapper).

React, as opposed to Angular, takes one-way binding and incorporates it into the design of the framework (I’m more than aware that Angular can do one-way binding but it always seemed to me that the majority of projects use two-way bind). As a byproduct of this philosophy, we have Redux and great to work with Redux DevTools, allowing for easy step-by-step recreation of user input.

LINQ

That one is probably the easiest to love because it can make your code easily digestible not only by non-programmers but even by non-technical users. Let’s see an example:

Let’s dissect it line by line:

• Line 28 – we’re defining, that adultAge is 18 (depending on the country it may be e.g. 21)
• Line 29 – we’re starting the processing of predefined collection called users
• Line 30 – we’re filtering users by selecting only those that are currently adultAge or older
• Line 31 – we’re filtering users by selecting only those that possess permission to Create (Create what? That depends on the domain of the application, which we cannot infer from this example alone.)
• Line 32 – we’re selecting the first user that is a male
• Line 33 – we’re taking out just the FirstName of that user

LINQ allows us to chain simple operations, which is very similar to our everyday way of thinking (divide and conquer). Summarizing this example, we select the FirstName of the first user that is an adult male, with the permission to create.

The only thing to understand when working with LINQ is that each step of the chain operates on the outcome of the previous step. Since filtering (Where clause) selects multiple objects of the same type as the input, we can take lines 30 and 31 and change their places; we can easily filter first by permissions, then by age. On the other hand, the First clause selects a single user, so running First as an initial step would be useless because then we couldn’t filter down further.

LINQ for me is powerful and easy to read, so I would dare to say that using LINQ gets us a step closer to clean code. The only possible con I see against using it is that debugging is harder. Since debugger treats the whole LINQ clause as a single block of code, putting a breakpoint makes it stop on defining the example variable (line 29) and right after calculating the whole thing (line 34). For me, the pros still outweigh the cons of using it.

A simple solution to debug LINQ in Rider is to use the Evaluate expression command, available from the right-click menu.

Why all those 3 in the same article?

I’m more than aware I could have written 3 articles, giving more space to each topic, so why did I put all 3 in the same package? The reason is: I found the common ground between them and it opened my eyes to something.

• Azure Functions: serverless = stateless and scalable by design
• React: one-way binding = simplicity of control flow
• LINQ: chaining simple commands = simplicity of code reading / divide and conquer

I like using those 3 technologies, and all 3 for different reasons, but all 3 drive us to cleaner code. Clean code is easy to read and reason about, which leads to less bugs. All 3 remind me also of something else.

Those 3 reasons remind me of Functional Programming.

Azure Functions in my head are pure functions, not relying on any state and always producing the same output (for specific input arguments). React and LINQ are like a pipe operator, allowing for a simple order of operations and allowing for digesting data in chunks in steps that make sense not only for a computer but even for a human.

Recently, I’ve been looking into Functional Programming and I encourage you to do the same, as it’s refreshing in the best possible way. Even if you’ll wind up not using it, it can be an asset as a mindset shift alone – especially now, that C# is borrowing language features from F#. It’s also worth mentioning that F#, as a .NET language, can easily cooperate with C#, so if you feel like trying it out in a C# project – you can, without any compatibility issues.

In the next article, I’ll try to go further into Functional Programming and why it’s interesting, and how C# can borrow a lot from F#, but there are certain things it won’t be able to replicate.

Have a good day guys!