Welcome! An introduction to Mechanic
I'm glad you're here. :) I'm Isaac, and I built Mechanic. My goal here 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 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.
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.
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". 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.
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!