Welcome! An introduction to Mechanic
I'm glad you're here. :) I'm Isaac, and I built Mechanic. My intent is to make automation better for everyone. We do this, here, in two parts: (1) by making it as easy and fast as possible for developers to create something that specifically addresses a merchant's need, and (2) by making the configuration/management piece as easy and fast as possible for merchants. Mechanic is very, very good at both parts.
From the ground up, Mechanic was built to be composable and reusable – and if we consider all that power to be "under the hood", the hood is extraordinarily thin.
What it does
- A developer writes a few lines of Liquid code. Or, a merchant installs a task from our library.
- The merchant configures the task using an auto-generated form – each element automatically feeding a data source in the task's code.
- The Mechanic platform handles responding to events coming from Shopify, from incoming email, from webhooks, etc. Scaling, uptime, monitoring, all sorted.
To get an idea of what Mechanic's been used for, have a look at our task library, at usemechanic.com. The code for each task is published, and each one can be modified. Mechanic is a highly versatile and incredibly powerful way to handle your process needs.
How it works
Mechanic has four core concepts: events, tasks, actions, and – beneath all of these – runs. In their natural order:
- An event occurs, usually triggered by something in Shopify.
- Mechanic renders whatever tasks apply to that event.
- Mechanic executes whatever actions those tasks define.
- Every event, task, and action has a run, representing the effort that Mechanic takes to do the work behind that event, task, or action.
(See the "Core concepts" section below for a more in-depth review.)
Importantly, we also have Liquid. You'll encounter this pretty much everywhere in Mechanic: it's a template language created by Shopify, and we use it heavily here, with a few extensions of our own. Read more about Liquid at Mechanic – strongly recommended reading. :)
Finally, if you're reading this, you're probably interested in reading from and writing to Shopify. Skipping ahead just a bit: you'll read data using Liquid (see Querying Shopify), and you'll write data using the "shopify" action.
How to learn
Mechanic has layers. :) If you're not looking to get into the code, then start by pulling tasks from our library, and experimenting with them. Mechanic is designed to be friendly, but if you've got questions, join our community Slack and ask away. If you know you want to find a developer to work with, then hop in the #jobs channel (more on that here: I need something custom – what next?).
If you are looking to get into the code, we have resources for you:
- For me, the best way to learn a tool is to solve a problem with it. If that's your style, start here: Practicing writing tasks.
- Or, if you enjoy following along with someone else's problem-solving, try our YouTube playlist of development videos.
- If you've already dipped your feet in and want to level up your game, we have some pointers: Writing a high-quality task.
And now, a more in-depth review of how this whole thing works. :)
Events can be triggered by nearly anything you like. All webhooks from Shopify are supported, in addition to scheduler events and events triggered by a user within Mechanic. We also have our own webhook system, allowing you to create custom events from your own applications, or in-browser from your Shopify store.
Mechanic responds to each event by running any tasks that are configured for that event topic.
A task is a Liquid template, which we refer to as a "script" (see Scripts). When an event comes in, Mechanic uses the event data to render that script. Each task script is responsible for rendering JSON definitions of actions, which will then be run.
An action is a discrete instruction to do something. This is frequently an API request to Shopify, or an email to be sent, or a file to be uploaded to FTP, or an HTTP request to a third-party API. And, the results of actions can be re-used, triggering a new event, which can then kick off the entire cycle again.
Whenever Mechanic does a piece of work (be it an event, a task, or an action), it does so using a run. A run can be delayed, or retried, and a run will usually be linked to other runs as well (since an event run results in a task run, which results in an action run).
This is a hugely important part of Mechanic's work model. If you're building things with Mechanic, make sure you understand these!