Deprecation Notice

Yeah, yeah, I know. I hate it too when people abandon tutorial series mid-way. But, due to (exciting!) circumstances, I'm calling it quits for now.

I'm thinking of just dropping a link to the full repo here - it's a mess, but it's something you guys can chew on instead of my empty promises.

If you'd like me to drop it here - let me know at hey@redcaptom.com.

And, just sayin', I had a BLAST doing this. If you know something - anything - about technology, take the time to write it down as a tutorial series. You will get SO, SO much value out of it, you can't even believe it.

Until we meet again - RCT :)

The Video (Scroll down for the article)

Coming soon!

A Primer on the Origin of Shopify's Tech Stack

Shopify, since its early days and still in essence (it appears), is a Ruby shop. If you're not from the RoR (Ruby on Rails) community, or have not been around for a long enough time, that might not be very obvious - but there are 3 main tells:

1. Tobi Lutcke's (Shopify's CEO and the dude who wrote the original Shopify code) GitHub page is almost entirely Ruby:

He was actually a RoR core team member, and a lot of the Shopify stuff used to revolve around that ecosystem.

1. The official Shopify App tutorials come in two main flavors - JavaScript and Ruby.

2. It used to be that you could only deploy from the Shopify App CLI to Heroku - which is a big company today, but originated as a Ruby projects deployment tool. It seems that they have removed the option to deploy with the Shopify App CLI from the documentation since I wrote the article, however, which is a shame.

Why does this matter to you in 2020 (or maybe 2030? hopeful little me) reading this article? It goes to show that what we will be building in - JavaScript - only came into the game a bit later. This is indicative by some "rough edges" that remain in the development process for apps at the time of writing for the JS crowd. I do not think that the JS dev process is harder than the Ruby dev process, but it's important to say the above out loud for when you get discouraged. There's constant movement by Shopify in this space - things that are hard today might be made obsolete tomorrow! Keep on pushing. :)

Note: The aforementioned was added for the article and does not show up in the video. See? It's worth following the articles instead of the videos too!

The App We Will Be Building

Moving on - if you follow the video, you notice that I make a small tangent around here to talk about the app we will be building from scratch - Countries We Ship To Button. Take a look at the video from the beginning and up until 2:10 to get an idea of what the application looks like in practice.

I'm also namedropping quite a lot in the video, and doing so on purpose - the stack, when disassembled into its separate pieces, contains quite a few moving parts. But, in fact, what Shopify did was make a bunch of smart, sensible technological decisions for you. This might seem like a constraint on a first look, but it's really not - they're basically spilling the beans on what they use, and urge you to do the same.

The next is simply a list of all those technologies, some links, and where they fit in our stack.

React - The front-end framework

React is one of the three major front-end JavaScript libraries (along with Vue and Angular). It is considered the largest player in this space today, and for good reason - while a bit complicated to grasp at first, it steps up your front-end game quite a bit.

It takes a somewhat different approach to interface building than what you're probably used to from PHP or any server-rendered language: Instead of populating a of some source with information, it constructs the page piece-by-piece and reacts (get it?) to actions taken on the page to change the interface dynamically. That's weird if you're not used to it, but makes a lot of sense from the user's perspective - I click here, this loads in this part of the page, this is populated etc.

It's like jQuery on steroids and without $s all over the place.

We will be using it to create this beautiful interface:

I will make a few videos detailing this part of the stack in detail, which should at least give you the ability to read React code. If you don't have any React experience that's fine - you can fill the gaps as you go along - but I do recommend at least reading some information about it, like the official docs or Dave Ceddia's Pure React (this is not an affiliate link, just a way for me and Dave to see who's coming from where).

However, if you're already a JS person, spend very little time on catching up - I got you covered with some basics in the React sidestep. Stay tuned.

Next.js - The React Framework

React, in and of itself, is lacking some basic utilities that can help you write code that is more performant (and, actually, help speed up the coding process itself). For this purpose, Vercel (formerly Zeit) came up with Next.js - the de-facto standard React framework.

If you're not really into React it's kind of hard to understand how Next stacks up next to it, and what does it even offer. In our application, the main place you will encounter Next is in the custom server it creates at the start of server.js. We will not really be using it all that much in our code, just reaping the general benefits it produces on the side. I will elaborate more about that in the Next.js sidestep in this tutorial.

Polaris - The Shopify Design System

Keep in mind that you will be building inside the Shopify admin, meaning that your app should mimic the look and feel of the Shopify admin as much as possible. Knowing that this is not an easy fit, the Shopify people released Polaris - a design system that's intended to allow developers to get Shopify look and feel with little to no effort.

Design systems, in most cases, are carefully-calculated interface languages, that are tuned to get a feel across a screen. You can read about it some more here, but for now it's enough to say that Shopify provides React components that we can use in our apps. They have the same color, animations and general feel as the Shopify admin's interface, which makes it relatively easy to create - inside your embedded apps - a familiar feeling for your merchants. I have a full side-step on this as well - stay tuned!

Node.js - JavaScript, Everywhere!

Up until now, we talked about the front-end part of things - but there's a lot going on in the back-end as well! While we will code the front-end of the application first, the back-end is the real heavy lifter, and it's written entirely in Node.js.

Saying that you write node code is a bit terminologically incorrect - it's like saying you're writing CLR instead of saying you're writing C# (which is not a great analogy, but the only one I could think of that is well-known enough to make sense). Node is a runtime - it is a way of running JavaScript on the server. What you're actually writing is JavaScript - much like you do on the front-end - except you do it on the backend, with the help of various tools and libraries that are designed for backend apps (like filesystem access, for example).

The interesting bit about Node.js is that it's basically built around providing code as a service. What I mean by that is that it was originally built heavily around the concept of requests and responses, and propping up servers - see this example - as a main "course of action". This is a bit different than other backend programming languages that are more "general" in nature, and do not basically require you to prop up some server somewhere in your application.

This is not true universally today, and Node is used everywhere in many different configurations, but for our purposes it's best to consider it as an API writing language. We will be building a set of endpoints to be used by our front-end application, and those endpoints will perform various tasks that receive, modify and fetch information across our application and the Shopify servers. More about that in a future sidestep, though - for now, treat Node as JS on the server.

Koa - A Node.js Web Framework

While you can totally write your servers in pure Node (and many do), it actually makes much more sense to use a proper web frameworks to run production-grade code. Those type of frameworks provide lots of utilities for you to perform common activities without having to re-write code from scratch - stuff like looking at the body of HTTP requests, handle specific types of HTTP headers, etc.

Shopify recommends the use of Koa, which is a slimmer, more modern alternative to the "standard" Node.js web framework - Experss. The beauty about Koa is that it comes "without batteries" - meaning that you only get the base functionality out of the box, and then need to append more and more layers as you see fit. This makes your code a bit more understandable (but also a bit longer), since all the components of the framework are explicitly mentioned in your server.js file.

GraphQL - Query Language For Rest APIs

GraphQL is a rather new, very cool runtime (and associated query language and conceptualization) that seems like a really weird idea at first glance. What it's basically saying is - let's make a new query language, that's not really like SQL (so is a bit harder to learn), and use that to query our APIs.

A keen observer will note that most APIs wrap database / ORM calls anyways, right? An API is just a fancy way to prevent your users from performing SQL queries on your database themselves, isn't it? Why do we need all of this fancy, shiny new stuff?

Well, letting your users run raw SQL queries on your database is a very bad idea. Let's get that out of the way first. Do. Not. Do it.

Having said that, have a way to query, rather than just call, your APIs is kinda awesome. Imagine you have a need to get some data in your application, that requires information from two different API endpoints. Usually this means two API calls - one for the first resource, and another one for the second resource. Then, you'd have to parse the information from both of those endpoints and return that data to the main application.

With GraphQL, you can instead perform a single query, that gets you the information that both API endpoints provide in a single API call (to the GraphQL query root). In this query, you can also query only the relevant data you need - mostly removing the need to do data massaging later in the process!

We will not be using GraphQL in our specific application , but I will be making a sidestep for it anyways since it's really important.

Apollo - GraphQL Client

The foremost implementation of GraphQL for JavaScript is Apollo, which is simply a GraphQL client you can use from inside React. I will talk more about it later. For now - just think of it as a component you can drop into your app, and perform queries with.

Shopify Liquid

While used very sparsely in this app (it's glory moment is integrating the button into the merchant's store, and that's about it), Liquid is the way one write Shopify sites. I will not be doing a full sidestep on it, because it's really out of scope for this series (that is already looking like it's going to be super long anyways).

That about sums it up for the tool stack. Let's start planning our app!