There is no escaping the amount of traction that static site generators and JAMStack are getting these days. As a traditional .NET developer, you may feel that your skillset doesn’t contain the things you need to jump on this bandwagon and make the most of the benefits available. But is it really that difficult to get up and running with a new stack?
At the beginning of this year, I decided to make some changes to my own site to add a few small improvements for SEO purposes. What I quickly discovered was that I didn’t have all of the correct versions of the .NET framework installed as I’d moved machines. Simply updating the framework seems to give me more errors than I’d anticipated and it felt like I was just fighting against NuGet to even get the development version of my site working. One thing on my mind while I was doing all of this is that I don’t update my site too frequently, so there isn’t much call for it being dynamic. As it turns out, I’d actually buffered everything through Cloudflare, so effectively I was running a static site of sorts. This got me to thinking that maybe this was an opportunity to try something new.
There has been a lot of conversation within Kentico Kontent, the Kentico MVP team, and the community in general about Gatsby so it was kind of at the forefront of my mind. There were some alternatives to think of (WYAM and nuxt.js for example), but I decided to give Gatsby.js a try.
The first thing to note here about the whole experiment is that I changed nothing in my Kentico Kontent project the first time around. I was able to reproduce a good 90% of my ASP.NET Core application. This for me really stacks up with some of the key principals of CaaS in that the implementation of the head is entirely independent.
The challenges for a .NET developer
Back in the early '00s, I was pretty hot on the JavaScript/UI side of things - we had to be as web developers, I don’t recall ‘full-stack’ being a thing, you just did a little of everything in order to get the job done. Years of financial services and deck-end integration work have degraded the skill set that I picked up in my earlier web developer days a fair bit, so the plan is to work hard to get back up to speed with the core of JavaScript, HTML, and CSS while also getting a good foundation in React, Vue, and other useful technologies from the JAM stack. I very much class myself as a .NET beck-end guy when it comes to development, so this was perhaps the most difficult thing in picking up Gatsby for this project; determining where the boundaries were between React, JavaScript, and Gatsby.
If you’re picking up these technologies for the first time (or perhaps after being on a break), the tutorials can sometimes be a little confusing and they make some assumptions based on an implied prerequisite knowledge. Sometimes you find yourself looking at some code and wondering which file or function it actually needs to be in. There is a certain amount of tacit knowledge of the underlying technologies that are beneficial before you start, but it’s not going to stop you if you’re not there already. There are plenty of resources out there for picking things up as you go. I found some great sources on Pluralsight for refreshers in JavaScript and also some great introductions and overviews of React that I worked through before setting off on this journey.
Once you get into the habit of when you need to break out of gatsby develop and restart everything the development process is pretty easy. The errors you get when your GraphQL isn’t quite right, or you’ve missed a bit of syntax take a little getting used too compared to what you’ve had with .NET, but on the whole, they’re pretty simple to follow. I don’t think anyone issue really cost me more than about 10 or 20 minutes.
I’m fairly certain that anyone working in the web and keeping on top of technologies is going to have [node.js] installed and will be familiar with npm. I think a few .NET developers are a little cautious of npm, you need to be at least familiar with npm and how it works to get going with Gatsby. If you want to add plugins (such as the Kentico Kontent source plugin or a sitemap generator), you’ll need to modify certain configuration files and run commands in npm. As an example, adding the Kentico Kontent source plugin can be done using the following at the command line:
npm install --save gatsby-source-kentico-cloud
This the modified you packages.json file to ensure that node is aware of it a build/runtime. It’s not complicated, but just something that you should be aware of.
Another of the new technologies at play in this project was GraphQL. Graph QL took a little getting used to, but once you figured it out, you find yourself wishing that other platforms used it natively. GraphQL lets us query the content from Kontent (or any other registered source) based upon the relationships between the data, rather than constraining our operations to simple RESTful methods. This eventually gives a lot more flexibility in approach when building queries that can provide content for our pages. The explorer that comes with Gatsby (graphiql) is awesome for looking at the data available and figuring out what we need in order to build our content.
Moving into production
Before this project, my setup was pretty well established. I used the web-hook in Kentico Kontent to trigger a building Azure DevOps, which would then update my Azure AppService and obliterate the cache for my site in Cloudflare. All in all, I was paying less than £ 10.00 a month to host the site and was reasonably happy with the result. When I first went down the Gatsby route, I reused this process, changing the build YAML to run gatsby develop for me.
Before I finally put the site live, I watched the twitch video with Ondrej Polesny and Jason Lengstorf about how to use Kentico Cloud and Gatsby together (obviously back then it was Kentico Cloud). What was at the tail-end caught my attention. I’d heard of Netlify before, but not really paid it much attention.
It turns out that Netlify is a really simple, fast and (depending on your use case) free solution to hosting. The solution I’ve gone for performs a full gatsby build for me every time I either push some changes to GitHub or publish content in Kentico Kontent. This is made possible by a really simple webhook trigger in Netlify that I’ve linked up to the web-hooks in Kentico Kontent. Total time to get Netlify configured was about 10 minutes, what wasn’t quick was the amount of time it took to get the DNS to propagate the changes from Cloudflare and Azure to Netlify - that took long enough for me to be without a functioning site for about half a day which was frustrating, but it’s not business-critical or high traffic, so I could live with that.
The end result
You can see the result of this build on my live blog. It’s quick and I’m getting reasonable results out of lighthouse in relation to performance and SEO etc. Given this was the aim, I’m reasonably satisfied with the results I have. I have a site that performs well and is simple and quick for me to update.
An additional point that I noticed is that the build time in Netlify takes less time that the build does in Azure DevOps, so if you were working on a more commercial level than a personal blog, you’re getting a reduced lag between content being publishing in Kentico Kontent and that content is available on the live site.
I’m really happy with what I’ve managed to put together with Gatsby in what was a fairly short amount of time and think that, if I reassess my content structures I can probably achieve more. What I do want to do is take a look at some other options too. There are two good examples out there from Ondrey Polesny using Vue and Nuxt, and also a slightly older implementation using WYAM from Kristian Bortnik that I’d like to take a look at in order to compare the outputs. Static sites are not always the right choice, but when they are, it’s good to have different options available.
The key takeaway points of this project were:
- Moving to Gatsby from .NET core was a smooth experience
- The performance of Gatsby on Netlify is great
- The Kentico Kontent source plug-in was really easy to use
- GraphQL is basically awesome
Cover photo by Marc-Olivier Jodoin on Unsplash