In setup stage, my app is fetching the shop's orders from the graphql API for x time back. then I set webooks for reading new orders.
The object received in the webhook request is as if I queried the REST API, so at the beginning I tried to convert it to the graphql object format - not safe and not a good solution.
so now i'm forced to query the grpahql API with the order id, and get the graphql object, so It can be true to the other graphql orders objects.
the main problem with that (except the unnecessary query for the graphql) is that I get a lot of throttles from the graphql API (max 2 reqs per sec), so I had to build some delayed fetch mechanism which make thing even more unnecessary complicated.
- Is there a way to get the order (or any other resource) grpahql obj in the webhook request payload, so I will not need to do another fetch to the graphql API?
- If not, Is there a better, simpler solution for that (except of routinely query orders for each shop).
I have the exact same problem. any solution for this? the webhook payload is different from the graphQL payload. what i mean by that is that you get the "edges" collection when retrieving a sub object like order line_items from the graphQL while you get a direct collection/array of "line_items" under the order directly in the webhook.
Are you saying that because when you get an order by calling the end point for a GQL object, you process it one way, and when you receive an order from a webhook you have to process it another way, and you are not comfortable having to do that?
Why are you downloading orders you receive as a webhook? Because your internal App parsing is so far only good for a query to the GQL and you have not coded up one for webhooks?
Whether you receive an order from GQL or a Webhook, they contain the same information. What is missing from the webhook reprensentation? Nothing AFAIK.
Would be nice to know if your actual issue here is truly technical (ie) I cannot do something because the technology does not exist, or if this is just "I want to avoid coding my App to handle two different ways of looking at the same thing".
It is true that in some cases you do not get nice GQL indentifiers, just RestAPI ones, and in other cases when you need a RestAPI identifier you only have a GQL one, but for the most part it is not too hard to handle that. Has nothing to do with API limits, but does pop up with Webhooks as they are not parity with GQL.
Yeah, you are right. I'm just trying to have 2 different implementations for the same thing. No limitations i'm facing.
However, from consistency perspective, It would be really nice to be able to get the webhooks response in graphQL format. Especially when it comes to connections. I think this can be done as a future api update by passing a graphQL query in the "includeFields" of "WebhookSubscriptionInput" object. wouldn't this be nice?
you can already create a webhook subscription via graphQL mutations: https://shopify.dev/docs/admin-api/graphql/reference/mutation/input-object/webhooksubscriptioninput
A webhook delivers to you a resource in JSON. I think the only thing missing is the occassional GQL reference ID but they are trying to include those.
I can't see them delivering anything different. You have to consume JSON that is all. If you can consume GQL, clearly you can consume JSON. But they are not the same thing, and a webhook response will never be a GQL response, as those are different.
Both GQL object and REST Object are JSON.
When Receiving an order from the webhook it is in the JSON REST format, and when receiving it from the GQL it is in the GQL JSON format. that leads to having to different methods (functions/code/etc) to process an order. that will lead to inconsistency and there by it is not a good solution.the better but not idle solution I implemented is getting the order ID from the webhook, then fetching it later from the GQL API. that might sound simple but it is a complex solution. tnx to throttling and other things.
First of all, it is funny that when I set orders webhook in the GQL API, I receive the order in the REST format. If I started to develop my app using only the GQL API, I wouldn't know what the hack to do with the JSON REST object I received in the webhook. I would expect getting the object in the GQL JSON format of course! (maybe by providing a GQL query when setting the webhook). that change is a must for Shopify moving from the REST API to the GQL API. (what code will generate the REST format if there is no REST API?)
Believe me that I'm no lazy to code different methods, In fact, I have coded at least 8 different methods to fetch orders consistently from the REST/GQL API with only the last one somehow do the job (no ideally at all).
Even though it is true that you can indeed code up a Webhook create with GQL, it is also true that Shopify will send the data as JSON to an endpoint of your choice. Since you control the code at that endpoint, you get to ensure a function capable of digesting the JSON is reliable and available. Yes, it is currently not the GQL JSON format, but the fact that it is data, in JSON, is helpful. The fact it is not parity with the GQL version is not good.
It seems clear SHOPIFY understands how screwed up this situation is, but to date, the investment in parity between RestAPI and GQL is not happening. Hopefully soon there will be parity!