If you haven’t read parts I and II of my JAMStack posts yet, make sure you read those first!

I want to dive into some of the more significant benefits I’ve seen working in JAMStack. I’ll be going over performance, low overhead costs, and security.

My current full time work focuses mainly on maximizing SEO for a large number of monetized websites. The majority of the work I’ve done so far in JAMStack has been converting these sites from WordPress over to JAMStack for performance gains (and subsequently gains in Google ranking). JAMStack is all about cutting the fat from a website. It let’s you completely cut out the major performance bottlenecks, like databases and backend logic, that plague other stacks. This also helps reduce the time I spend testing performance, as I can be more focused on front end performance tests. Every site I’ve converted so far has seen performance increases that would be impossible with any other stack. This report is an example of one site’s before and after:

Every metric of site performance improved substantially after conversion. Most importantly, it went from an unacceptable 12 second load time (read more about the 10 second threshold for websites) to a blazing 2.1 seconds. For this site, that directly correlates to higher search rankings and more conversions.

I briefly went into hosting costs for JAMStack sites in my last post. Because JAMStack sites ultimately compile down into static HTML files, they are incredibly easy to host compared to sites that need a backend language and databases. Using this blog site as an example, I have a free Algolia account that handles the search functionality, a free Webtask account that handles submissions to my freelance work form, and a free Forestry account that let’s me easily write content for this site. I could also easily host this site on Netlify for free (but I like having my own dedicated server for other projects I work on). The only things I have to pay for here are the jdillman.com domain name and email. The reason all of these services are free or very low cost is because JAMStack is all about each part of a site being as focused as possible. You’re never using resources or bandwidth you don’t need.

One last benefit to JAMStack that should be very apparent is its security. I’ve seen WordPress sites hacked or compromised hundreds of times, even when they are built by extremely diligent developers. And the target for hacks on these sites in every single instance I’ve seen is the database. So because there is no database in JAMStack, there’s almost nothing left to hack. There’s no SQL injection, very few access points to hosting vulnerabilities, and no CMS maintenance to always keep up with. In order to compromise a JAMStack site, a hacker would have to be able access something like GitHub or a server shell. I’m not saying it’s completely impossible for this to happen, but it’s undeniably safer than a typical WordPress setup.

And with that, I am wrapping up this series of posts on my experience with JAMStack. My bold prediction is JAMStack technology will outpace alternatives like WordPress for custom web development in the next decade. At the very least, I believe all web developers should be keeping their eyes on JAMStack and experimenting with its capabilities.

So in my last post (Part I below), I went over my experience researching and building JAMStack sites with Jekyll, Algolia, and Webtask. In this second part of my JAMStack posts, I want to go over what I do with a JAMStack project after I have it built and ready to deliver. I’ll be going over the services I use for hosting, deployments, and content management.

One of the biggest benefits of JAMStack sites is that, as static sites, they are incredibly simple and easy to host. There’s no database to run, no backend language to install or configure, and no logic that needs to run every time the site is accessed. It’s just plain HTML files to be delivered. Because of these benefits and the growing popularity of static sites, there are services popping up that are dedicated to hosting static sites at a fraction of the cost of traditional hosting. The one I use for all my JAMStack projects is Netlify. My personal Netlify account that I use to host a small number of sites is absolutely free, because of how little it costs them to host these sites. At a more enterprise level, it costs the same to host hundreds of static sites on Netlify as it does to host a single WordPress site on a traditional host in my experience. But for me, the savings aren’t even the best part of using Netlify.

Netlify offers a wide array of services specific to static sites in addition to hosting, like deployment previews, form submission handling, and A/B testing. In my case, I connect a Jekyll site’s GitHub repo to my Netlify account. Netlify will take that code, build out the static site from it, and deploy that static site to a server for me. The really cool part is that Netlify will run that deploy process for every git branch I have in that repo, and assign each branch a separate placeholder url for me to access. So I am automatically able to test new features that I have branched off the main site before I merge them back in. There’s no provisioning a separate staging environment to test and QA code, I create the branch and all of that is done for me. I cannot even describe how beneficial this feature has been for me coming from WordPress development. And that’s not all, Netlify can even use these separate branch deployments to create A/B tests.

So I’ve covered how JAMStack can be just as powerful as WordPress for building templates and functionality, but what about content? WordPress’ excellent admin interface is its main selling point for many people.

Because there’s no backend functionality on a JAMStack site, it will not have a CMS built in like WordPress. We again need to call on an external service to function as our CMS. Having tried several of these headless content management systems, the most WordPress-like one I’ve found is Forestry. Similar to Netlify, I can connect my GitHub repo of a JAMStack project to my Forestry account (also free). Forestry will then read the repo and create a model of the content in a user interface very similar to the WordPress admin. As content is created and changed through the Forestry interface, it will make git commits directly back to the repo. So the site’s content is versioned through an actual VCS, which I’ve found to be very helpful compared to WordPress’ revisions functionality.

Another very helpful feature unique to Forestry is Front Matter Templates (FMTs). I mentioned in my last post how front matter is Jekyll’s equivalent to post meta for storing data like titles, dates, templates, and any other custom values you add. Using FMTs, Forestry will create an intuitive user interface for controlling the values of each different front matter. So I can create a Forestry config file in the site code which specifies that a particular front matter should display as a checkmark in Forestry, or a dropdown list of options, a calendar date, a sortable list, a file upload, or many other options. This is where a static site can really become fully fleshed out with complex layouts and still have easy-to-manage content. Similar to Advanced Custom Fields in WordPress, this gives me a lot of control over how I want to control content editing.

Admittedly, Forestry’s interface isn’t always as straightforward or helpful as the WordPress admin, but it has already come a long way in the short amount of time I’ve been using it. And I know personally that there is a very dedicated and talented team behind its development.

With these last two posts, I covered pretty much everything at a high level that I wanted to say about how I work in JAMStack. In my next (and hopefully last) post on this topic, I want to dig deeper into the benefits of JAMStack, and go over what all this means for me as a developer.

The vast majority of my career in web development as revolved around WordPress. There’s been a relatively recent paradigm shift in web development called the JAMStack that more and more developers are embracing, including myself. I’ve been pretty deep in the JAMStack world now for close to a year, and so I want to share my thoughts and experience transitioning from WordPress. I have a lot on my mind regarding this topic, so I’m planning for this to be a series of upcoming posts. In this first post, I want to give a brief overview of what JAMStack is, and some of the tools I’ve used with it.

Unlike many other tech stacks, JAMStack doesn’t really define specific technologies to use. It’s more like a theory on how to maximize performance and organize the components of a website. JAM stands for JavaScript, APIs, and Markup. These three general components are used with a static site generator to create websites that can be just as functional as any WordPress site, without all the extra bulk.

There are many static site generators that can be used in a JAMStack build, like Hugo, Gatsby, and Jekyll. Jekyll is probably the most widely used of these, and the one I have the most experience with. With Jekyll, I build out HTML templates for a site using Liquid templating, and add the site’s content to simple plain text, html, or markdown files. Once a build is triggered for the site, Jekyll’s Ruby framework takes that content and applies it to the appropriate templates, creating a directory of completely static content that’s ready to serve.

With Liquid templating and simple Ruby extensions, Jekyll is capable of everything a WordPress theme can do. Jekyll’s collections function the same as WordPress’ custom post types, front matter functions the same as custom meta, Liquid blocks work like shortcodes, Ruby plugins work like filters, and yaml configs can function the same as PHP globals. Jekyll makes the markdown part of JAMStack extremely powerful, but its lack of an actively running backend means it can’t do some of the things that WordPress has built-in like search and form submissions. This is where the JavaScript and API parts of the JAMStack come in.

One of the major selling points of JAMStack for me was how well-organized it requires code. JAMStack requires a very clear separation of frontend assets and backend functionality. In most applications of JAMStack, the frontend and backend of a site rarely even exist on the same server. JAMStack relies on the fact that there are countless API services a site can call on to provide almost any kind of backend functionality it needs. One such service that I’ve used pretty extensively is Algolia. I use Algolia to create an external index of a site’s content, and sometimes other external data that is used in the site. I can use Algolia’s index as a kind of database for the site, which lets me easily implement search functionality to a site without having to write my own algorithms. This very blog uses an Algolia index for the search bar in the menu. In addition to a site’s own static content, I’ve also used it to index data in Google Sheets to be applied across many different JAMStack projects. From the Jekyll side, this all boils down to a basic AJAX http request, and parsing through the JSON Algolia gives back.

There’s an API service out there for just about anything you’d want your website to do. But relying on these external APIs can sacrifice some of your ownership of a site’s functionality. What if a project requires a highly custom way to handle form submissions, or needs a highly custom authentication process? This is where serverless functions come in.

Serverless functions is an even newer part of web development than static site generators. It’s a way to build out backend code in a static site without having a server for the code to run on. “Serverless” is kind of a misnomer because ultimately there is a server that the code runs on, but it removes all of the maintenance, scaling, security, and other sysadmin aspects of running a server. Put way too simply, it’s a service you use to host your own API code. The biggest example of one of these services is Amazon Lambda, but so far my need for serverless functions has been too sparse to justify that particular service. I’ve been using a similar but simpler service called Webtask. As an example of how I’ve used Webtask, one particular JAMStack project I worked on needed its own custom form submission and admin view to display those submissions. I wrote the form submission process and admin authentication process in Node and Express, and saved that code into a directory in the Jekyll project that was configured to not build out with the rest of the site templates and content. I then took the config file that Jekyll uses to build the static site, and added a property to the build process that pushes the Node directory up to my Webtask account. From there, anytime a site visitor accesses the form, the form will make a basic request to Webtask, which will then handle scaling up a server on the fly and running my code. It’s incredibly powerful, and incredibly liberating as a developer.

Hopefully it’s clear from this post how powerful JAMStack can be when applied with the right tools. There’s still a lot more I want to go over about JAMStack, like hosting, deployment, and content management systems, but this is already my longest post ever. I think those topics are better left for another post. I will be working on having a Part II in the coming days.

I recently helped to complete development work on a pretty unique web application. The organization had an idea to create a place for people find out about the accessibility of many different business locations. Their hope is help people with physical disabilities better plan out any business or errands they have ahead of time, so they can choose the most accessible locations. They also believe this will help push demand for businesses to become more handicap accessible.

The solution our team came up with was to create a site based around Google Maps API, and provide an interface for users to submit reviews for individual locations. Users can search for a location on the site using the same functionality as Google Maps. Once they’ve selected a location, they can see the average ratings for that location’s facilities (parking, access, bathrooms, tables, mobility, and an overall score). They can also see what other people have written about the business in terms of its accessibility.

My role in the project was to make sure the site and server could perform well under a large user load. The original version of the site quickly ran into problems hitting request limits on the Maps API, and general slowness from poor database design. My contribution was to cache the Maps data into the WordPress database, and integrate some other custom tables into WordPress.

I added logic to the site so that whenever a user selects a location that has never been clicked on before, WordPress creates a post in a ‘locations’ custom post type. The location name, map ID string, address, phone number, website, and images are all saved to the post’s meta. So whenever that location is selected in the future, the data can be pulled quickly from the local database rather than called from an external API. Each locations post also includes meta for when its data was last pulled from the API. If it has been two weeks since it was pulled from the API, the next time a user selects it, it will update its data from Google. I also added functionality for the comment ratings meta to be cached into the location post, so it no longer has to be calculated on each view.

This project stood out from my typical development work because of its unique challenges. You can see the current version of the site here.

Recently I’ve been working on some custom development work for a few Shopify eCommerce sites. My work so far has included plugin apps and theme development.

On the theme development side, Shopify only exposes the front-end view code (HTML, SCSS, and JS) in the theme templates, enhanced with a templating language they call Liquid. The Liquid templating language seems exactly like Twig, which I’ve used countless times in the WordPress theme MVC framework I use. So the transition to Shopify theme development was pretty smooth.

On the one hand, keeping theme development exclusive to front-end code makes a lot of sense from a programming standpoint. It keeps the views ignorant to back-end controller implementation, which is something I strive for in my WordPress theme MVC setup. On the other hand, it can make any extra functionality initially more difficult to implement. In WordPress theme development, it’s almost too easy to add things like content filters, meta fields, and new taxonomies. In Shopify, that sort of functionality is relegated to plugin app development, which can help organize code and pays off in the long-term. Overall I think Shopify takes the right approach to theme development.

On the plugin app development side, Shopify provides a robust API for any functionality additions or modifications you might want to make. A standard Shopify instance is locked down on the hosting they provide, so all apps have to run on your own external server. The app has to either provide its own UI on its own domain that the Shopify admin links out to, or hook into Shopify’s Embedded App SDK to display in a frame within the admin.

I’m wrapping up work on two embedded Shopify apps built in PHP. The first provides extra admin fields to products, so admins can control some custom functionality for product pages. The goal is to provide something like an Advanced Custom Field experience to the Shopify admin. For now, the fields are configured by a developer through a JSON file, so the client admin doesn’t have to bother with creating and implementing fields. I’m using it to create product fields for custom warning messages and minimum order quantities. The second app integrates Shopify orders with Amazon S3 storage. The use-case for the client is to have customers upload images with a customized order, and store those images in an S3 bucket. Right now the app uses Shopify’s CDN as temporary storage for the image as the customer completes the order, and then hooks into Amazon’s PHP SDK to upload the image to the S3 bucket.

I’ve really enjoyed working in Shopify so far. I like the strong separation between back-end functionality and templating. It’s been a nice refresher from the many WordPress projects I’ve had lately.