Below is a brief outline of how this app is made and what technologies are used. If you'd like to dive straight in then full project is available on my GitHub.
+
-
-
Front-end
+
Below is an overview of how this simple app is made and what technologies are used. If you'd like to dive straight in, the full project is available on my GitHub.
-
I wanted to create a decent, modern client-side experience for this app and given my (very...) limited front-end expertise I decided to choose .NET Blazor Webassembly. Blazor is Microsoft's take on component-based SPAs (single page applications) and offers us back-end focussed devs a way of producing decent client experiences without needing to dive into another front-end specific technology.
+
I'm planning to integrate a simple blog as part of this app that will dive into more specific implementation details so check back soon for more!
-
Blazor traditionally came in two flavours, server and webassembly with an additional third option (Blazor Web App) recently released with .NET 8 which is an amalgamation of both. Blazor Server initially generates content on the server and utilises web-sockets to communicate dynamic UI updates with the client without requiring a page load, whereas Blazor Webassembly downloads the entire app to the client browser on first load alongside a light-weight .NET run-time to execute code directly on the browsers UI thread.
I wanted to create a decent, modern client-side experience for this app and given my (very...) limited front-end expertise I decided to choose .NET Blazor Webassembly. Blazor is Microsoft's take on component-based SPAs (single page applications) and offers us back-end focussed devs a way of producing decent client experiences without needing to dive into another front-end specific technology.
-
-
Back-end
-
As the
-
+
Blazor traditionally came in two flavours, server and webassembly with an additional third option (Blazor Web App) recently released with .NET 8 which can offer the functionality of both, alongside traditional SSR (server-side rendering). Blazor Server initially generates content on the server and utilises web-sockets to communicate dynamic UI updates with the client without requiring a page load, whereas Blazor Webassembly downloads the entire app to the client browser on first load alongside a light-weight .NET run-time to execute code directly on the browsers UI thread.
This app is styled using a cool CSS framework called TailwindCSS. PostCSS is used alongside Tailwind to generate a lightweight stylesheet based only on the parts of the framework that are used, as oppose to including a everything the framework offers.
+
+
+
+
Back-end: .NET Azure Functions API
+
+
There is a very minimal API used as the back-end of this app to allow users to contact me directly via the contact page. This will be expanded to serve the technical blog I'm building as a new feature that will be available soon.
+
+
The contact API endpoint currently:
+
+
Validates a Google Recaptcha token to protect against fraudulent submissions.
+
Builds a HTML email from the information provided in the form.
+
Sends an email directly to my inbox using the SendGrid API.
+
+
+
The API is written in .NET 8 using Azure Serverless Functions with HTTP triggers to act as API endpoints. For larger scale projects I would almost always opt for a fully-featured Web API, however Azure Functions provide automatic elastic scaling with consumption-based billing and a generous free-tier, making them perfect for smaller projects like this.
+
+
-
-
Hosting
-
-
-}
+
+
Hosting: Microsoft Azure Static Web App
+
+
The goal of this project was to learn some new technologies and host the app as cheaply as possible. With this in mind I decided to go with a Static Web App hosted on Microsoft Azure. Static Web Apps offer global distribution of static assets (the Blazor Webassembly app in this case) and offer integrated hosting for Azure Function App APIs.
+
+
Another cool feature of Static Web Apps is Azure's integration with GitHub actions to deploy both the client and server simultaneously and provide automatically deployed staging environments for pull-requests opened to the main branch. This made testing deployed changes much easier and cheaper than deploying an isolated testing/GA environment before releasing to the live version of the app.
+
+
Using Static Web Apps on Azure has meant that I have been able to build, deploy and serve this site and API completely free (with the exception of the domain name). The next thing on the roadmap is building a simple blog using an Azure SQL database where I'll document the full process of writing and deploying this app so check back again soon.