PublishablePublish in bulk after productCreate

[lvorraro]

HI everyone,

I use the GraphQL Admin API to send products and receive orders.

I create thousands of products at time via bulk operation "createProducts". 

My current problem is the field "published" has been remove from ProductInput

and now I need to call the mutation "publishablePublish" for each product.

This is ridiculous, I have a  cloud application with many sellers integrated with Shopify and every seller now need to call "publishablePublish" for every single product, the result will be billions of calls?

Please, does anyone have the same problem as me?

Help please

[batsandi]

Did you find a solution? I am integrating a legacy store and basically need to delete and create all products every day to reflect inventory...

1. I need to delete all products by product ID one by one

2. I bulk upload all products with bulkOperationRunMutation productCreate (which in it of itself is overly complex with its staging and multiple calls and polling to check the status etc.)

3. ImageSrc is now deprecated, so i need to run productCreateMedia for every single product to upload an image

4. And now... I need to run publishablePublish on all products???

I thought the idea of the GraphQL admin API was to limit the number of calls necessary to acheive certain tasks - doesn't seem to acheive that goal...

[guest4]

@lvorraro It's now available via bulk operations:

https://shopify.dev/docs/api/usage/bulk-operations/imports#limitations

@batsandi The thoughts and feelings that you're expressing are similar to the ones that we've had while trying to get things done with the API. We've had to build several new systems in response to changes with the API. That can take the wind out of our sails.

Here are a couple of reassuring ideas that we've had:

• We've seen that when there's an aspect of the API that seems inconsistent with how it should be used, it will eventually be resolved (like in this case). This tends to be little or no help at the time, but the prospects of it help set internal/external expectations.
  
  
• The documentation tends to lag behind the actual system, so it may be worth trying something, even if the documentation doesn't support the idea. This tends to be the case less and less (and that's probably a good thing). Example: https://community.shopify.com/c/graphql-basics-and/how-perform-bulk-publication-of-products-and-coll...
  
  
• The Shopify API team's understanding of information system architecture is mighty. It's impressive how the system components and their interactions are deconstructed.
  
  
• Finally, adapting to the change tends to result in systems that are better designed for us. The systems that we've built in response to the API changes aren't just band-aids; they're dynamic and resilient responses to the change.
  
  For example, we've built a "store tasks" system which takes a task type as input (bulk operation type or internally defined type), gets all of the data for the task group (from Shopify or from internal systems), segments it into tasks (to accommodate usage limitations), runs the bulk operations (or internal functions), and then polls for completion if a task is asynchronous.