In this series, we’ll demonstrate how to create a client-side Blazor application with a Telerik UI for Blazor component. We’ll then show how we can integrate this application with a simple Serverless Function API from each of the “big three” cloud providers. This post features a comparison of the three.
Hello and a very warm welcome to this five-part series where we’re going to:
» The chart component will be used to display a dataset containing some arbitrary information.
» Each cloud solution will be created using the equivalent “serverless function” service, coded using C# .NET, in a way to make them as similar as possible.
» The reader can choose to go directly to the article
applicable to the platform that they already use/prefer—or read all three to learn how the development experience compares.
This series is not intended for the absolute beginner, but could suit existing .NET developers looking to learn a bit more about “serverless” solutions using straightforward examples.
If you’re planning to follow along with this series, you will need to create a Blazor client application, following the instructions in Part 2. Having completed that step, we’ll then look at creating a backend API.
If you already have a preferred cloud provider, you can go straight to the matching article.
If you’re interested to learn how the experience compares between the cloud providers, a succinct comparison is below, and you may further be interested in reading all three of the platform-specific articles in this series.
“Blink … and you’ll miss the latest framework!” is a meme familiar to many developers … yet somehow Blazor has now been with us for about four years (at the time of writing)!
Briefly, ASP.NET Blazor first appeared in 2017 as an experiment by Microsoft’s Steve Sanderson and was adopted shortly thereafter by Microsoft’s ASP.NET team. Blazor was formally announced early in 2018.
Shortly after, Progress Telerik announced a suite of UI components that complemented Blazor. The first release of these components appeared early in 2019.
Blazor was fully released early in 2020, including full product support for both flavors of Blazor—Blazor WebAssembly (WASM) and Blazor Server.
With the release of .NET 6 in November 2021, we also received LTS (long-term support) for Blazor. Combined with a number of appealing improvements, such as reduced download size, this makes Blazor an increasingly appropriate choice for production and enterprise use—especially for teams already strong with .NET skills.
It’s a fast-evolving product, with interesting features emerging, such as Blazor ahead-of-time (AOT) compilation, which purports significant runtime performance gains.
Telerik Blazor evolves quickly too. Today, the current version is Telerik UI for Blazor 3.0, representing a matured selection of versatile and easy-to-use components that broadly fall into the following categories:
A requirement often faced by developers, especially those more accustomed to frontend work, is:
"How can I create a simple backend API(s) to support my app, using a straightforward-to-use, managed cloud service?"
This is an example of where “serverless computing” is a great option.
Briefly, serverless computing is a way to host small pieces of event-driven code, usually with very little involvement in the underlying infrastructure. Typically, those computing resources are allocated on demand, which leads to usage efficiencies and scaling benefits.
In order to maintain commonality, each example of a serverless API in this blog series will address the following key focal points:
Image credit: Andrea Piacquadio on Pexels
While researching the individual articles in this series, I have been able to create side-by-side prototypes, using all three cloud providers.
I had initially intended to only present a series of how-to guides, but having the opportunity to work with all three platforms side-by-side—and having the editorial independence to comment without commercial bias—has presented an interesting opportunity to learn and form opinions.
Despite many similarities, there were some interesting differences between the developer experiences of these three cloud providers that you may be interested in reading about.
Note: If you are not interested in an objective opinion, and just want a “give me the facts tutorial”—it’s absolutely fine to skip over the rest of this particular article and dive straight into the other articles in this series!!! :-D
Let’s first acknowledge that different professional people/teams have very different needs, perspectives and skill sets. Whereas one group may absolutely love managed platforms, others may seek finer-grained control, or perhaps the flexibility offered by having many options.
It would be naive to attempt a generalized comparison—e.g., “Cloud X is better than Cloud Y.” A quick search will return dozens of such articles, which generally end up being nothing much more than subjective marketing spiel or feature listings that don’t really tell us much. As such, we’re not going to explore the breadth, reach, performance, reliability nor costs of the various cloud providers.
It would be more objective to focus upon the relative learning and development experience, as applicable to just that single “slice”—a simple HTTP-triggered serverless function—of the respective services.
More specifically, this would be from the perspective of a “relative newcomer, looking for a quick solution to a simple API requirement.”
I was particularly interested in:
» I’m highlighting this because an endpoint is not an intrinsic part of Serverless Compute (even those that are intended to be HTTP triggered)—it’s conceptually a separate service. Granted, this endpoint won’t be named in a way that we would want to present directly to our customers (in which case, we would use another API Gateway service), but it’s perfect for internal service-to-service connections and testing. The fact that this is provisioned automatically cuts out needless process and friction.
Note: The process of creating a storage account is better streamlined if using alternative “Wizard” tools, such as those found in the Web Portal.
Read the full Azure post here.
» One minor critique was that there were instructions (big buttons!) directing the reader to go and do something using the web-based Console. I felt that the guide would have been better to use entirely CLI examples (which is what I’ve done in article 5 of this series).
» Local development was possible, in a way very similar to working with a conventional ASP.NET Web API service—e.g., being able to readily attach HTTP testing tools or our client application.
Read the full Google Cloud post here.
Note: I have a larger volume of comments relating to AWS, compared to Azure or GC. This reflects the greater amount of time and effort it took me to research the AWS version of the article in this series.
» Strictly speaking, everything needed is “literally there” in the docs … it just kept feeling like the reader would need to “locate and coalesce resources” in order to make progress.
» For example, the main developer guide AWS: Building Lambda functions with C# opens with a paragraph telling
us that various .NET libraries are available (see the screenshot above), but then provides no guidance on how or where to use them, nor does it link to where that information can be found. This information does exist—but it does
so separately at
Github: AWS Lambda for .NET Core (which is a separate repo to https://github.com/awsdocs).
This is an important resource for .NET developers using AWS, but the reader is left to find it themselves.
» For example, the main developer guide Developing an HTTP API in API Gateway mentions that a specific permission needs to be configured, but leaves the reader to search for the solution elsewhere (incidentally, the solution to this is buried away in an AWS knowledge base article).
» AWS documentation doesn’t present a singular quickstart that targets our specific use case. Instead, this information can be found spread between a quickstart using the Web-Console and JavaScript, a section related to C# and another document related to the CLI.
» We are provided with an “empty” template, but initially it is not obvious how this can be used as an HTTP trigger.
» Eventually, we learn that a separate API Gateway service is required, at which point the puzzle pieces start to fall into place.
» The “empty” template can be partly used with the gateway. It
still seems to be left to the reader to piece together the use of a separate Gateway proxy class in order to fully progress.
» Commendably, in addition to the main sample, the templates also scaffold a unit test project
(using xunit
)—including a basic example of a unit test. Having taken things in the direction of unit testing, it would have been great to see examples that paved a path for how we could expand upon this, using our own mocked dependencies. Instead what we have is hard-coded or using AWS-provided test interfaces (Amazon.Lambda.TestUtilities
).
» There are ways around this (such as hosting an ASP.NET application from within serverless infrastructure), but the default experience is that a “lambda function” needs to be deployed to the cloud in order to work.
» AWS does provide a “Lambda Function Test Tool”—this requires a prebuilt .dll
that is run from within its process and provides a constrained way to trigger the function. This is not a good development
experience in my opinion.
» While I understood that providing choice and flexibility to the customer brings with it a multitude of entities, requiring a prescriptive matrix of permissions … I found that, for my simple use case, these activities only
served to add a bunch of fiddly extra work that the other providers have shown need not be necessary.
» For example, authorizing just the CLI tooling before even being able to use it was unnecessarily more complicated than
when compared to either Azure or GCP.
Read the full AWS post here.
Image credit: Merelize on Freerange
I hope you’ll join me in the rest of the series! You can read about the client app setup in Part 2, Azure in Part 3, AWS in Part 4 or Google Cloud in Part 5
Thanks to Mandy Mowers & Layla Porter for the overall document review.
I always disclose my position, association or bias at the time of writing. As an author, I received a fee from Progress Telerik in exchange for the content found in this series of articles. I have no association with Microsoft, Amazon nor Google—this series of articles is in no way intended to offer biased opinion nor recommendation as to your eventual choice of cloud provider.
A UK-based freelance developer using largely Microsoft technologies, Jim McG has been working with web and backend services since the late ‘90s. Today, he generally gravitates around cloud-based solutions using C#, .NET Core and Azure, with a particular interest in serverless technologies. Most recently, he's been transitioning across to Unity and the amazing tech that is Augmented Reality.