Hi! It’s Jacob from Vistaprint.
Is there a way to perform updates (patch, put) that allows bulk operations? At the moment you can only update one entry ID at a time. Am I wrong?
Any suggestion will be welcomed!
Thanks in advance.
Regards.
Hi! It’s Jacob from Vistaprint.
Is there a way to perform updates (patch, put) that allows bulk operations? At the moment you can only update one entry ID at a time. Am I wrong?
Any suggestion will be welcomed!
Thanks in advance.
Regards.
Hey @JacobGP, welcome to the forum!
You are correct, currently our write APIs don’t have support for batching updates and you have to send updates one entry at a time.
That said, our APIs don’t any rate limits, so you can make as many updates in parallel as you want as fast as you need. e.g.
for (let update of updates) {
post('.../api/v1/write', update)
}
That said, a batch update API sounds like a great feature request for our roadmap.
For our assessment, can you give us an example use case that this would benefit you?
And also I’m trying to think of an API I’ve used that has a good batch updating system worth using as design inspiration - can you think of any good examples you’ve used or seen that we should possibly model ours after?
Or perhaps adding mutation
support to our GraphQL API could be a good solution as well
Anyway, curious your thoughts and thanks for the feedback @JacobGP!
Hey @steve!
Thanks so much for your quick response.
Our use case is related to the memsource plugin we are developing now. We will receive a bunch of translated fields (each one with its corresponding id) and ideally we would like to update all of them in a single REST call.
Given that this update can take longer perhaps you can considering returning 202 and then use builder hooks to notify changes in the page.
Another option is to allow callers to pass a callback url that will get notified once the batch job is finished, including the results of the operation. We could pass the callback url in the payload OR in a header metadata field - however I’d rather use a builder.io webhook to notify page content changes.
However if this operation is quick enough then a simple synchronous 200 will suffice. Acceptable timings would be around 100 ms. I guess?
If a good example hits my mind I will let you know, can’t think of any at the moment Your graphQL suggestions sounds like a good approach as well!
In our case we will be using parallel calls most likely (axios.all or promise.all). If the number of fields is large then we will batch this parallel update into chunks.
Keep us posted when this batch update is available to change our code accordingly.
Regards.
Thanks for the feedback @JacobGP, makes perfect sense and will keep you up to date with updates here as we have them!