Azure Functions, React and LINQ – how are they connected?

Azure Functions

Azure Functions, React and LINQ – how are they connected?

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!

Marcin Kern, Senior Software Engineer in Rite NRG.

My experience spans writing and designing desktop applications, websites and cloud solutions. Entirety of my 9-year-long commercial experience consists of writing .NET exclusively, although through the past few years I’ve added a Frontend spin to the mix in the form of React. I’ve also spent a lot of time advocating Agile, as I believe it can be very useful if it’s understood and done right.

Outside of work I’m a dad of a happy 1 year old boy, husband, video-game lover (Amazon, bring me Lost Ark already, I can’t wait!), I like digital painting and enjoying a nice sauna. I also enjoy learning programming languages, when my curiosity gets the better of me.

Share:

Most recent

We have been recognized for our ability to deliver exceptional services in 2024. (2)

Rite NRG Recognized as a Clutch Global Leader and Clutch Champion for Spring 2024

Leading the Way in B2B Software Solutions with Exceptional Client Satisfaction and Industry ...
Read more
futsal

Rite NRG becomes a part of the Gold Partners group of WKS Śląsk Futsal!

For several years, we’ve been proud supporters of WKS Śląsk Futsal. Our collaboration ...
Read more
53129605-A9B6-4179-A665-500D94E07720

Sicily Workation: Where Work Meets Paradise

Are you up for an adventure that blends work with a slice of ...
Read more
We have been recognized for our ability to deliver exceptional services in 2024. (2)

Rite NRG Recognized as a Clutch Global Leader and Clutch Champion for Spring 2024

Leading the Way in B2B Software Solutions with Exceptional Client Satisfaction and Industry ...
Read more
futsal

Rite NRG becomes a part of the Gold Partners group of WKS Śląsk Futsal!

For several years, we’ve been proud supporters of WKS Śląsk Futsal. Our collaboration ...
Read more
53129605-A9B6-4179-A665-500D94E07720

Sicily Workation: Where Work Meets Paradise

Are you up for an adventure that blends work with a slice of ...
Read more
IMG_6091

Rite’s Triumph at Just Join Games in Gdańsk!

On August 18th, 2023, our Rite team participated in the Just Join Games ...
Read more

Cookies & Privacy

This website uses cookies to ensure you get the best experience on our website. Read more…