At its core, accessing a single resource via either API is effectively the same. Typically this involves passing the ID of the resource to the API and getting back the data for that resource.
In a REST call, every field of that resource will be returned, allowing the usage of simple dot notation to utilize whichever fields are desired without first requesting them.
The equivalent query in GraphQL would need to be augmented to include the desired fields.
Occasionally, the REST and GraphQL APIs do not use the same field names. And in some cases, there are some fields with no counterpart between the APIs. Review the API docs in detail for the resource being queried to make sure the task code is using the correct field names.
This is a basic task to check a product's status, type, and tags, and then output a log entry if that product qualifies.
The preview block is only showing the fields from the REST product webhook that will be used in the task. In reality, there are about 150+ lines of detail from a product webhook which has only a single variant and image. This grows much larger as variants and images are added to the product.
The product id used in the GraphQL query below comes from the REST-like product webhook, which will still exist after the REST product endpoint deprecation.
The preview block simulates the relevant shape of the returned data, which typically matches exactly what was requested in the query. This could vary though based on the task logic following the preview block.
To assist with generating an object query block, you can use the "object_query" snippet in the Mechanic code editor, and it will prompt you to choose the object type to generate a query and preview block for (e.g. product).
To see a code diff from a Mechanic library task that was recently converted in this manner, click here, and review the code variations between the {% if event.topic == "shopify/orders/create" %} blocks.