I have been working on a simple responsive website that would serve as an online address for my dog-walking/boarding service. This being my first ever official side-hustle as a registered company, it took pretty long to even get here. Registering a private limited company was also an adventure. But I wanted to experience. This isn’t like a full blown venture intended to become the leader in pet services or anything. We just love dogs and would love to do something that would be different from software. Something that would encourage us to get out of the house and teach us empathy and have some fun with dogs.
Anyway, the point of this post is not to talk about business or running a dog walking company. The point was to share how I went about creating a website and hosting it on Azure. I can guarantee that if you know how to build a static responsive website, then the hosting on Azure part is very easy.
Microsoft has made it very easy to deploy a and manage a whole suite of services from VSCode itself! I only had to open the portal to do custom domain mapping. That’s it. That’s how I created WaggyFloof.
I have always wondered how people create pages that look beautiful on desktops, mobile phones and tablets. This has often made me really envious of their skills. As a software engineer, who has predominantly worked on back-end technologies, front-end development doesn’t come naturally for me, despite having mostly managed and maintained web applications for the past 6 years. By managed, I meant, managed a team that maintained them. So my hands-on interaction with the code wasn’t that significant.
The key to building a responsive website is to understand that you have to provide some metadata to the browser that’s rendering the page.
Viewport meta tag
In a browser, a viewport is the area of the window in which web content can be viewed. Any content outside this, is not visible on the screen, until you scroll to it. Apparently portables, render pages in a virtual window or viewport which is generally wider than their screens and then shrink the rendered result down so it can all be seen at once. Sounds like quite a lot of work to me. I think you can get to see this, if you tried ot load the desktop version of a website on a mobile. The whole thing is shrunk and poorly rendered and barely usable but still viewable.
To mitigate this problem, Apple introduced this viewport meta tag, in Safari iOS to let web developers control the viewport’s size and scale. I only just learned this today. And this is now supported by most mobile browsers, despite not being part of any web standard in particular. Apple has a pretty detailed documentation on Viewport and differences between the iOS and the desktop viewport.
Learn more about viewports in different mobile browsers in A Tale of Two Viewports at quirksmode.org
<meta name="viewport" content="width=device-width, initial-scale=1">
This magical meta tag is what the mobile browser uses to understand what the site’s
width and the
initial-scale is. The first being the width of the screen in css pixels. The second letting the zoom level when the page is first loaded. The second param is particularly useful when the portable device shifts from portrait to landscape mode. There are additional properties too but I am not going to cover it here. If you want to learn about this in full detail, you might as well read the viewport meta tag documentation on MDN.
Flexbox Layout is a W3C recommendation at providing an efficient way to layout, align and distribute spacing among items in a container, even when their size is unknown or dynamic, which is why it is aptly named Flex. The concept is that items in a container element can be spaced or scaled based on the free space available to fill on the screen preventing overflow.
You must be wondering why Flexbox when Grids exist. Apparently Flexbox is most appropriate for components of an application, and small-scale layouts, while Grid on the other hand, is intended for larger scale layouts.
A beautiful cheatsheet is available here on CSSTricks.
Responsive Website done, now how do I get it to Azure
I decided to make my single page application an app service and not just a set of files accessible via a blog storage, which is an alternate method to achieving similar outcome. The choice is yours. I decided to go the AppService way because in the future, I wish to make this a full fledged app and not just a static website. Keeping that in mind, I thought starting with some basic foundation for that would be good.
Now that wasn’t helpful. I told you that there were two ways of doing it, but I didn’t even explain how. I will give you a link straight to the documentation for that. Instead of me trying to explain both the ways.
I followed the second option and the video that walks you through the steps. This was priceless! VSCode extensions for Azure development has greatly simplified the number of things you have to setup manually.
Ideally if I were to do this from Azure, I would have to configure a resource group, an app service plan etc. But because the vscode extension is smart enough to do all the prerequisites for me, I just had to press a button and choose the linux platform to deploy! It even configures an AppInsights instance for the app, which currently I am not really using at all. This saved me a lot of time! Although, you must know that the app is by default hosted somewhere in central US region, which may not be ideal for you, based on your geographical location. But to get things up an running quickly, this was a great way!
By the end of the deployment, VSCode will pop up a message asking if you’d like to browse to your app service which is hosted at
https://yourappservice.azurewebsites.net/. You just have to click and get there!
I know that hosting your app at a default azure web address was not the point of the exercise. The whole point was to get your app hosted a custom domain! This is not difficult either. Although this part of the work requires you to use the Azure web portal.
To do this, you need to be on a paid subscription and not on the basic free subscription. You can switch to a pay-as-you-go subscription and choose the cheapest hardware if you are not hosting a full fledged production application and you don’t have much traffic either. That is exactly what I did. Then follow the instruction on the docs here. This didn’t take more than 5 minutes.
As soon as I mapped the custom domain, the next thing on my list was to do the TLS configuration. This can also be done within the portal! As you have scaled up your service plan, you can do this too on Azure Portal. Follow the instructions about creating a free certificate and then go ahead and create the binding.
That’s it. You must now have an Azure App Service hosted on Azure that is also on SSL.
I appreciate that this blog post doesn’t detail the steps. I would rather give credit to those who created the original docs than me copying and pasting the same information here. I just wanted to compile it all in one place and hence this post. I hope you find it useful.