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.
Additionally, we 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.
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.
Mechanic comes with 200+ tasks, already in our library. The Liquid code for each one is available online (see usemechanic.com). To create a custom task script, work with a developer (see I need a task that doesn't exist yet – what next?).
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!