5 ways to supercharge your Single Page Application
You’ve built a Single Page Application! Why? Because you are a master of your craft. Nobody is making a round trip to the server on your watch. Page refreshes are so 2008.
And how did you master said craft? With Angular of course. Or maybe it was React. Or Vue. Listen, I’m not here to argue with you about JavaScript. That’s what Hacker News is for.
What I’m here to do today is to suggest to you that while you may have achieved JavaScript nirvana and can wield a client-side router like this bear with a lightsaber, there are entire other levels of Jedi that you can take your SPA to, and it has nothing to do with your code.
1. Static files need static hosting
When you are done running npm build in your CLI of choice, you are going to get a bunch of static assets out the other end. Unless your build failed because you decided you were going to configure Webpack yourself. In which case, may god have mercy on your soul. Why did you do that? WHY DID YOU DO THAT?!
Those static assets need static hosting. They were literally born for it.
Not all hosting is created equal. You may be familiar with the term, “PaaS”. That’s “Pizza as a Service”. Just kidding. It’s not. That’s just “Pizza Hut”. Or the VS Pizza extension for VS Code.
“PaaS” is “Platform as a Service”. This is what you will get with most hosting providers. You send your application up with a web server of some sort (usually Express) and they provide the Node.js that runs your application. Popular “PaaS” services include Azure App Service, Heroku or Amazon Elastic Beanstalk.
There is nothing wrong with hosting your app in a PaaS, but it is not the best way to host a SPA.
When it comes to serving up static assets, there are specific services out there that are designed to just serve files as fast as possible. We call these “Static Hosting Providers”. These would include services like Azure Blob Storage or Amazon S3. We tend to think of these as serving only files — images of bears playing with lightsabers. But your SPA is really just a bunch of static files as well. That makes a static hosting provider a better option than a PaaS for serving up your application.
Why is static hosting better? 2 reasons — speed and scale.
Speed
Static hosting providers are fast. Crazy fast. Why? Because these services are architected to do one thing and one thing only, and that is serve up some static asset. Which is exactly what your app is. When you use a full PaaS, you are dealing with Node and some sort of web server, and frankly, most of that is overkill.
Here is a video of me deploying a Create React App application to Azure Blob Storage. Watch how fast this sucker deploys and loads. Azure is fast, but it’s the static nature of Azure Blob Storage that makes this magic happen. I did not speed up or alter this video in any way.
I’m doing this from VS Code with the Azure Storage extension. Yes. It is awesome. Yes. You can do it too. Here’s a great tutorial for how to deploy your site to Azure Storage with VS Code.
The other thing that static hosting like Azure Storage gives you is scale.
Scale
When your app goes to the front page of Hacker News, right above the latest argument about JavaScript frameworks, your traffic is going to spike. Which is great. This is your 15 minutes of fame. The question is, can your site spike with it?
With traditional PaaS hosting, your site can scale, but it takes time and it definitely ain't cheap. You pay for “compute” on these services, which is things like processor and memory. You have to pay for that in discrete chunks. Which means you have to scale in chunks too.
Static hosting doesn’t work that way. Remember, the whole point of it is to deliver static assets fast — no matter what the scale is. You are charged by the request, not by the amount of compute resources you use. That being the case, scaling is sort of a “solved problem”, because it’s baked into the core architecture of the product. It’s also a lot cheaper because it’s going to rapidly scale out and then back down. All without you having to shed a single tear for some poor soul’s denied request.
Once you put your SPA in a static provider, you are ready to take the next step. And the next step is to put your app where your users are with a CDN.
2. CDNify your app
I used to think that CDN’s were for serving up copies of jQuery. Turns out, you can serve other things up too.
A content delivery network copies your asset to locations all over the world and caches it. In the case of Azure, that's a lot of data centers. At the time of this writing, the map looks like this…
The CDN leverages all of these physical locations to get your site close to your users. We’ve solved a lot of problems in the past 100 years, but we’re still constrained by the laws of physics and the speed of light. If it’s speed we’re after, no amount of clever coding or architecture is going to beat just putting a server in someone’s backyard.
Most static hosting providers will offer a CDN option for your site as well. Some do it automatically. In the case of Azure, it’s a switch that you toggle on in the dashboard. Because that’s how everything in life should work. Need to find the perfect long-term relationship? Click this button. Parenting hard? Just move this slider! Maybe quantum computing will bring those features. Nobody knows what quantum computing is anyway.
CDN’s in Azure offer some additional features, like the ability to compress files on the fly, as well as block access to specific regions (if you wanna be a meanie) and controlling how the CDN caches content.
OK — so you’ve got static hosting, which is wicked fast, and your content is now physically as close as possible to your users thanks to Azure CDN. But your application isn’t JUST a static front-end. You’ve got an API as well and that API is just begging for some Serverless.
3. Serverless API’s
Contrary to popular belief, the best reason to use Serverless is not so that you can impress people with blog posts. It’s so that your service architecture can scale with your load.
Your SPA is most likely hitting some API that you created. Or perhaps someone else created it and some of the endpoints take nearly 10 seconds to return and the person who created it is no longer with the company. And why is there no documentation!?! THERE IS NO DOCUMENTATION, ALAN!
I apologize. That was oddly specific.
Similar to the static site hosting, Serverless scales up and down automatically. It can do this because you are charged per execution — not for a set amount of compute as with traditional hosting methods. As Troy Hunt so eloquently put it…
“it’s an endless stream of constant service that you consume at will”
Read that quote with a charming Aussie accent in your head and it sounds even more profound. No seriously. Try it. SEE?!?
We don’t normally think about our service layer affecting the performance of our front-end application, but of course it does. I use a common pharmacy app that I won’t specifically name beCause i’m a Very nice perSon. That app has a pretty nice front end, but it is almost unusable because the API’s that power it take so long to return my prescription for pills which are supposed to stop hair loss and are not working.
Don’t let your API be a bottleneck. There is just no reason for that, and Serverless will ensure that your API is always available. Whether or not your app has zero users (like all of mine) or ALL THE USERS IN THE WORLD, like Troy’s haveibeenpwned.com, Serverless will make sure that every request gets the respect it deserves
As an added bonus, Azure Functions lets you build, test and debug your Serverless Functions locally and even deploy directly to Azure. It’s almost enough to make me forgive Alan. ALMOST.
4. Automating workflow tasks
NO! I just used “workflow task” in a blog post. Your eyes are glazing over. You are losing consciousness. The boredom and apathy is swallowing you! DON’T YOU DIE ON ME.
Wait though. Before you close this tab and go back to reddit.com/r/bettereveryloop (if you’ve never heard of that, you’re welcome), consider this…
Sometimes you’ve got tasks that are part of your application that definitely belong on the server, but don’t necessarily belong in your API. Like me in high school, they don’t really belong anywhere and nobody is going to invite them to any parties. Ever. That got dark in a hurry.
This could be something like sending an email when a purchase happens, or maybe it’s adding integration to a service like Stripe. I don’t know. I didn’t build your app. The point is that these things definitely do not belong in your data access API but they definitely do belong on the server.
You could stand up yet another API, but what you really need here is some sort of automation framework. You might be familiar with services like IFTTT or Zapier. In Azure, there is something called Logic Apps.
Logic Apps let you build out workflow tasks using pre-built connectors that you can drag and drop to create these sort of one-off integration activities that otherwise don’t have a home. Or any friends. Or a date for prom.
The nice thing about Logic Apps in Azure, is that you can connect directly to any other services you are also hosting in Azure. Things like your database, your app or your API. In this example, I’m connecting to a SQL Server database, looking for any items that have been updated and then sending an email. I don’t have to write any code to do that, which means it’s actually going to work.
That last thing, and possibly the best thing, that you can do for your SPA, is to get it set up to build and deploy with some sort of Continuous Integration Tool.
5. Continuous Integration
Whoa! first “workflow automation” and then “continuous integration”. What is this? A Gartner symposium?
Listen — I get it. If you’re a developer, the idea of continuous integration might strike you as an awful boring subject. I’m with you. It’s not that I don’t care about how my app is deployed, it’s just that I’m entirely too busy getting the app to work to have that discussion right now. Or ever.
But let me tell you, once you have it set up, it will be one of the best things you can do for yourself and your application.
When we built vscodecandothat.com, we planned to add a new tip to the site each week. The tips on that site come from a static JSON file, so in order to update the site, you have to update the code and redeploy. That’s a huge design flaw on our part. When you code with Burke, you can be assured of two things 1) lots of depressing memories of my days in high school and 2) design flaws.
Since we had to modify the project to update the content, we set up a continuous build and deploy process using Azure DevOps.
Azure DevOps is a visual tool that allows you to specify a series of steps that pull your code from source, run any tests, perform any builds or really do anything at all. I flash my LIFX connected lightbulb green when the build and deployment succeeds. Because I can.
It’s like magic, and it has enabled us to iterate on that site incredibly quickly. The faster you can deploy, the faster you can improve and the more likely you will be to make needed changes.
Roll the video!
All of this comes from my interview with Asim Hussain on Five Things. He is a gentleman, a scholar, and his beard is on point in this video and I am jealous. Check out the video and make sure you follow Asim on Twitter. He’s a lot like me, only he actually knows what he’s talking about.
