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 firstname.lastname@example.org.
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 :)
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:
- 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.
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.
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!
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.
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.
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.
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!
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.
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.
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
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.
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!