Posts in JAVASCRIPT

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.

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.

I’ve had some time to reflect on my work from the past few months, so I’d like to write about a couple of projects and some insights I’ve gained from them.

One of the organizations I work for is going through a major overhaul on its eCommerce platform. We are moving inventory to a new warehouse, changing shipping policies, adding new products, and working towards simplifying our customers’ experience. My role so far has been to rework our SQL databases to conform to our new data structures, rewrite the back-end (PHP) logic associated with those tables, and rework our store website’s custom admin panel. It’s been a lot of work, but I’ve really enjoyed the chance to stretch out my SQL knowledge.

I also started a just-for-fun personal project of developing a web-based computer game. The idea for the game is in the same vein as old text-based adventure games like Zork or Colossal Cave Adventure. I’m working to include multiplayer capabilities as well, similar to games like MUD1. My reason for starting this project is to familiarize myself with a more Javascript-centric stack. I’m exclusively using JSON data structures to store and pass data between the web app and the server, no databases included. The current prototype does have a PHP back-end, but my goal is to transition to Node. It’s been a fun and very unique project so far.

Data structures seem to be a common thread between my work projects lately. My work involves different ways of organizing data, like JSON, SQL, and associative arrays, and how to communicate that data around different programming frameworks. It’s always satisfying when all the different parts of a system fit together nicely and churn out exactly what you expect.

If there’s two things every developer loves talking about, it’s tooling and build processes. I’ll start by talking about the build process I’m currently using for my web projects.

Every website and application I develop is versioned in Git, and hosted on either BitBucket or GitHub (though not always on my own personal account). I take advantage of the processing hooks that come with Git as the hub of my build process. I start by setting up a bare headless Git repo on the development server, and adding that repo as a remote on the project’s repo. That way I can quickly, easily, and safely push code up to the server. Then I set up Git’s built-in post-receive hook, where all the magic happens.

In the post-receive hook, I run a shell script to set the work tree of the development server (wherever the live directory is). Then the script does a `git checkout` to pull the actual project files into the live directory. So in short, I can use a single Git command to push code to a secure headless repo on the development server, which then runs a script to pass the project files into the live directory. This is a fairly standard setup, but usually there’s a lot more work to do with compiling and compressing. Work that can be automated on the server.

If I have my way on a project, I’m always using Sass and jQuery for styling and scripting. Those two file types both need to be compiled and minified to run and deliver quickly on the web. I use the same post-receive hook to run a `sass` command that compiles and minifies my .scss files into pure .css all in one go. Easy enough, but the javascript takes a bit more effort. For that, I use the Node module Gulp. Gulp is simply a javascript file that is meant to run on the server, similar to a shell script, rather than in a client. It’s used to do tons of really amazing work, but for my purposes it’s great for simply minifying javascript and other assets.

With Gulp, I start by writing the gulpfile.js that will hold the minifying script. I use the Gulp Uglify plugin to do this as simply as possible. Part of the reason I use Gulp is because it can handle image compression as well as javascript, so I also use the ImageMin plugin. Once the script is in place for the Uglify and ImageMin processes, I push the Gulp file up to the development server. On the server, I install Node, npm, Gulp, and the two plugins, so that I can start actually running the Gulp file. Then I can simply add the `gulp` command to that same post-receive hook, and everything will be up and running smoothly.

The advantage of this build process is that I don’t have to do any manual compiling or minifying, and more importantly, I don’t have to version or push around any compiled or minified files. It keeps my local project repos and my GitHub repos nice and clean. I do usually version the Gulp file, but I think it’s a small price to pay. It takes some initial setup time, but over the course of a project, the overall time saved is well worth it.