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

Azure Functions

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 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. (...)

To read the full article, follow the link: https://bit.ly/338c3Gh