Problem/Motivation

For system-to-system APIs an external system will usually want to push some kind of update for data it knows has changed (e.g. perhaps it manages address information for users) without changing anything else.

These changes should happen as a single efficient transaction to ensure data doesn’t end up in an unknown state, this excludes splitting mutations on a per-field level, since they’re executed independently. Additionally it’s not feasible for external systems to first request existing data because this might cause race conditions (whether those race conditions are a problem for user-facing applications is feature/application specific but because it’s a user initiated action this is much less likely a problem because the user sees the info they intend to submit).

To meet these design criteria we introduce an Optional* input type that wraps another scalar type (e.g. String or PhoneNumber) which can be NULL. This custom input type can then be used in mutations intended for system-to-system interaction and distinguish between “I don’t care about this field” omitting the Optional* type or “I want to set this field to empty”: sending an Optional* type input containing NULL.

Steps to reproduce

Proposed resolution

These types can be used in system to system API design to distinguish between a field that a system doesn't want to change or a field that should be changed to the empty value (NULL).

For now we only need String and PhoneNumber, we don't have this need for other scalar or more complex types yet.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Kingdutch created an issue. See original summary.

ronaldtebrake’s picture

Status: Needs review » Reviewed & tested by the community

Will be in 12.1.0

ronaldtebrake’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.