Hi @stlbucket It’s a common pattern to have a value that needs to be calculated by a mutation callback. Depending on your use case there are two approaches you can take. The simplest is to make the field optional and then let a mutation callback fill it in after the fact. If having the field optional is not acceptable you can have an input model without the field and a separate “real” model that is being populated by the mutation callback including the calculated field

yeah that’s what i thought is there a future feature that will allow for a mutation to wait on the result of one or more mutation callbacks as it executes?

We have a really exciting concept coming up that will make this much easier to deal with. I can’t give an exact timeframe, but I would deffinitely try to make your current workaround as low overhead as possible with the understanding that you can replace it in a couple months or so.

maybe a change of subject, but at this point is there really any difference between a mutation callback and a subscription if there aren’t lambdas involved? if i have a server that exposes an endpoint, then access that via mutation callback, would the overall behavior of my architecture be any different if instead my server just used subscriptions?

We have reached the same conclusion internally. It’s basically two transports for the same mechanism. Currently Subscriptions has a more expressive api than mutation callbacks, and we are looking to unify this.

but if mutation callback return values could be used and/or returned during a mutation… which might speak to your ‘really exciting concept’?

@stlbucket Would you have time to jump on a skype call early next week? I would love get your feedback on a couple of new features we are designing.

sure - dm me anytime