This post explains how to create a GitHub workflow, which builds, tests and deploys a Unity project to Azure Static Web Apps (SWA) instance. Due to foundations on which SWA was built upon, it represents a perfect way to develop and test any game built on Unity WebGL platform.
The title might be a bit misleading. If you assumed this post would be yet another Unity tutorial, it is not quite the case. Teaching you complex framework, such as Unity, in just about three weeks, is something I could never promise. It is more of a story of how I rewrote my high school project, written in Turbo Pascal, without having any real experience with Unity. Because, why not. And I have been postponing learning a thing or two about Unity for quite some time.
Configuring service container and setting up request pipeline in ASP.NET Core can eat up a lot of lines of code, especially for more complex projects. A well-established way of doing this is using Startup.cs and its ConfigureServices() and Configure() methods. Although complete application setup can be packed into a single type, we must not forget about Single-responsibility principle. I wanted to show you a way to prevent startup from growing uncontrollably, by keeping different concerns separate from each other.
One disclaimer though. ASP.NET Core 6 has rolled in and removed the need of having Startup.cs altogether. Despite that fact, I am sure the ideas presented in this post will be relevant, even in the new era.
Let me present a pattern we used to solve a problem haunting our enterprise application for ages. It was initially designed to handle long running operations, using RESTful approach, but we soon realized it could be used in many other ways. As it generalizes the system of submitting requests and obtaining responses, it can easily be adapted to different business processes, while keeping unified client interface.
Update your browser to view this website correctly. Update my browser now