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!

Introduction

Tooling is a touchy subject for programmers - each and every one of us has his own permutation of programs, scripts, config files, keyboard shortcuts and whatnot that we use on a daily basis, and which we trust to the core. Even more specifically, each language has its own ecosystem of tools and best practices - and developers who are part of some ecosystem tend to gather around the same tooling.

While I do not subscribe to the dogma of "this tool is best since ever", I do strongly feel that if a tool is generally acceptable in the community you work in, you should at least consider using it. If possible, consult with a long-time developer in the same ecosystem and get his views on wha'ts good and what's not. They've most likely been at the same junction that you are now at an earlier time, and have insights you could use.

This also has the added benefit of exposing you to new paths of thinking that might've not been obvious before. An easy example is ngrok - a tool I will talk about soon. Unless you have experience port-forwarding to expose your local machine to the outside world, you might not fully appreciate this tool. But, I can assure you, it's a pretty awesome piece of software that deals with a tricky bit of networking that is not obvious from first sight. It also sent me down a rabbithole of networking that I'm glad I went down, since it made me a much better dev afterwards. This shows another benefit of learning new tools - the exploration of new thought directions the tools throw you in, that benefit you professionally.

I will caveat the preceding notion, however, by mentioning that tooling is just that - tooling. Don't let it overwhelm you or detract you from the nail in front of you - the problem might become easier to deal with using a great tool, but it will not solve itself. Lower your head over they keyboard and resume coding, please. :)

Anyways, back to business.

Code Editor - VSCode

I'm a big fan of Visual Studio Code for anything web-dev. I was a Sublime Text user for many years, and eventually got to work at a company that used VSCode and fell in love with it. If you're deep in the JavaScript ecosystem (and you soon will be, as Shopify apps are pretty much a full-stack JS endeavor), this editor is just feature-packed: Formatters, linters, syntax higlighters, smart snippets, auto-refactorings, test framework bindings and what have you.

The way I set it up usually is one workspace per "mental zone" - one for writing these tutorials, one for client applications, one for testing and learning, etc. Since it's pane-based, you also have a great separation of concerns and can edit server-side and front-end code side-by-side. You will see in the next videos that I try to first build the front-end component, and then iterate on back-end parts from that front-facing component (and dual-pane editors are a great asset in that approach).

Terminal Multiplexer - tmux

You don't really need tmux. Nobody really needs it if they're mostly working in the editor (as you guys will). But, whenever you do find yourself in need of a terminal, there's nothing quite like it. It lets you construct a set of multiple terminal windows in the same operating system window, arrange them however you see fit and switch between them with a key binding (as well as naming them, have more than one set of windows in the same window and much, much more).

In our flow, we will use 3-4 windows at any given time: One for ngrok, one for our dev server running with npm run dev (more about this later), one with the project's folder open to do git add . && git commit -m"some commit message" && git push -u origin master (again, more on this later) and (optinally) one with a test project to run test commands in. tmux is perfect for this - you can see all incoming requests in the ngrok window, any error messages in the server dev window, commit and push after every fix in the project/git window and run sample commands in the optional test window.

This is of course perfectly feasible with a regular terminal window (or a combination of a terminal window and the in-editor terminal), but to me the tmux approach is much cleaner and fits on a single monitor to my left (and not my main monitor in front of me that I use my editor on).

Note, however, that tmux is strictly a Linux tool at the time of writing this article. If you're on a Mac - use iTerm2. On Windows - ConEmu is a great choice.

Don't get hung up on terminal multiplexers too much for now, though - you already have enough tools to ramp up on, leave this one for the very last (if at all).

Node version management - nvm

NodeJS is at the core of most of what we will be building here. Your build tools run on it, you will be writing code in it and use its default package manager npm extensively. There is an inherent problem with Node, though - its developers tend to create breaking changes between versions.

This is not a problem per se - Node's developers chose to prioritize adding new features as the language progressed instead of maintaining backwards compatibility - i.e. making sure old code works with new versions. It becomes a problem once you rely (as we will) on multiple packages, created by different authors at different times using diffferent versions of node.

For the most part, let npm do its thing and set you up with the correct packages for your node version and whatever it is you're currently working on. But - what happens when you revisit an old project in a year from now, or want to use code from an older project written by someone else?

You'd need to have installed - on your machine - different versions of Node. Again, this in and of itself is not complicated - just download each version to a different folder, add the binary to the path and be done with it, right?

Wrong. It's a shitshow. You'll think you are using version A, when instead you'll be using version B and then committing code to your repositories that is designed to use with version C. Let's just... not.

Instead, you can use nvm for Mac / Linux (or nvm-windows for Windows). These are tools that download, switch and manage Node versions for you. You could easially install some version of node, then switch to it using nvm use 12.16.3 when you want to use Node 12.16.3.

This way you don't actually have to deal with configuring different Node installations - the manager does it all for you. While this value might still not be clear to you, wait until you have to work with other people's older code. Fun to be had by all! :)

Sidenote: This sounds scary, when I'm thinking about it a bit deeper. It's really not, though - this is a solved problem. Use the tools at hand, get used to them, and move on. Lots to do, lots to do!

Tunnels, oh tunnels - ngrok

A Shopify embedded app (like the one we are going to soon build) does not actually run on the Shopify servers. As such, it requires some place to be hosted in. We'll talk about deployments way, way later, but for now we'd like to have someplace to run our apps from, so they can be embedded in Shopify.

Traditionally, you'd need to throw your code up on a server for that to happen, or use tricky network hacks to get your local computer to act as a world-facing server. This whole endeavor is not really fun for anyone when all you want is a URL that leads to your computer, and to the directory that you run your code in. Well, that's what ngrok is for.

I could into the details of how ngrok works, and dive into what tunnels are, what the hell introspection is and why should you care, but the honest (and lazy) answer is that it's out of scope for this article. If you'd like a follow up on that, hit me up here or on Twitter and I'll write up a longer post.

For now, just know that whenever you'll run your code in one terminal window, you can also expose it to the world by running ngrok in another terminal window. This will allow us to "mimic" a hosted app on our machine, and have that code run inside the Shopify Admin panel. More about this - later.

Shopify official stuff

I go deeper into this in the video, but there's also a few pieces of tooling Shopify itself provides. I suggest you watch the video for the visual walkthrough I do there for the following items, but if you still want a readable version - here's a short one:

• Shopify App CLI - This is a Shopify project that is intended to be used as a supplement tool for developing apps. It scaffolds, serves, deploys and generally holds your hand when building Shopify apps. I would say that you should wait before using it. Instead, first learn on how an app is built, what is holds in it, where are all the important bits and pieces go - and then use the CLI to scaffold your projects.
• Shopify Partner Account - All Shopify app builders are considered Shopify Partners, and are entitled to some nice perks and a direct support line to Shopify, to solve any issues. After you sign up for the (free) account, you will get access to a nice dashboard to manage all your apps and stores. We will use it extensively in this tutorial, so stay tuned.
• Shopify Development Store - A Shopify Online Store costs 29 USD a month. Since we will be developing for Shopify, the platform offers us a way to skip that fee and have a live store at our disposal for testing purposes. We will use one of those extensively as well for testing our app with.

A note about operating systems

I am a Linux user. I have no bad things to say about Windows. I have no bad things to say about Mac OS. I have no bad things to say about BSD. I don't care what you use, as long as it fits you and works for you. Don't let anybody ever tell you that you would become a better dev by abandoning Windows for a unix-based operating system. It's bullshit. Some of the best devs I know are Microsoft hounds, slinging C# and .Net in a scale you would not believe. Dogma is for the weak - write code, be better, and discard all the noise.

Having said that, feel free tot talk to me about help in setting up stuff for your own operating system for the sake of this tutorial. If I can't solve it myself, I can most likely refer you to the correct resource. And if your problem is interesting, it might merit another DEV post! :)