OperationContext

Any lifecycle method has access to the operation's context that holds all data for the operation's mutation resolve. You can read or write its content in your lifecycle implementations.

Operation Lifecycle Methods

onContextCreate

{ onContextCreate: undefined | (ctx:OperationContext) => void|Promise<void> }

In this example we use the onContextCreate callback to set a value in the data object of the OperationContext. This data can be evaluated e.g. in FEEL-expressions.

operation:
  RentCar: 
    input: 
      Car: 
        attributes:   
          brand: 
            type: String!
            validation: 
              expression: notIncludes( @brand, @blacklist ) 

  operation: {
    RentCar: {
      onContextCreate: ctx => {
        _.set( ctx.data, 'blacklist', ['Tesla', 'BYD'] )
      }
    }
  }
}

mutation { RentCar( Car: { brand: "Tesla" } ) { validationViolations } }

[{
  path: 'Car.brand',
  message: `did not satisfy expression: notIncludes( @brand, @blacklist )`
}]

dispositions

{ dispositions: undefined | (ctx:OperationContext) => void|Promise<void> }

There is usually no need to change the default implementation. When you provide a custom implementation, you have to create all input dispositions in the OperationContext for this operation in regards to its input.

beforeValidation

{ beforeValidation: undefined | OperationCallback<boolean> }

In the beforeValidation callback you would typically complete all data necessary to validate the operation's input and execute any business logic.

If this method returns anything else but true the following lifecycle methods are not executed. The values in the operation context (data, input, dispositions, validationViolations) are returned to the client.

You can either provide an implementation for this callback or use one of the following shortcuts for typical use cases.

OperationCallbackEntity

{ entity:string, id:string, path?:string }

In this example the operation input has a carId but we want the Car entity item with this id in the data e.g. for further validation.

entity: 
  Car: 
    attributes: 
      brand: String!
    seeds: 10
operation: 
  RentCar:
    input: 
      Rental: 
        attributes: 
          carId: String!
    beforeValidation: 
      - entity: Car
        id: Rental.carId

Assuming there is a car entity with the id "0102030405" we could call the mutation like so:

mutation { RentCar( Rental: { carId: "0102030405" } ) { result { data } } }  

When we see the data after this we see the car item in there, we could use in further business logic.

{
  Rental: { carId: '0102030405' },
  car: {
    brand: 'Porsche',
    __typename: 'Car',
    indication: 'Porsche',
    id: '0102030405'
  }
}

OperationCallbackRestCall

{ restCall: string }

You can execute rest calls to load additional data that you can use in further business logic.

In this example we want to determine the vehicle brand or manufacturer for a given VIN. For that we use a public API https://api-ninjas.com (opens in a new tab) We can use this API call https://api.api-ninjas.com/v1/vinlookup?vin=XXXXXXX

restCall: 
  CarAPI: 
    endpoint: https://api.api-ninjas.com/v1/vinlookup
    params: 
      vin: "@vin!"
    headers:
      X-Api-Key: YOUR_API_KEY
    result:
      from: manufacturer
      to: Rental.brand
operation: 
  RentCar:
    input: 
      Rental: 
        attributes: 
          vin: String
    beforeValidation: 
      - restCall: CarAPI

mutation { RentCar( Rental: { vin: "5UXCR6C01N9K17074" } ) { result { data } } }

{
  Rental: { vin: '5UXCR6C01N9K17074', brand: 'BMW'  }
}

validation

{ validation: undefined | (ctx:OperationContext) => void|Promise<void> }

There is usually no need to change the default implementation. When you provide a custom implementation, you have to validate all operation inputs in the OperationContext for this operation in regards to the input dispositions.

If the context validationViolations are not empty after this method, the following lifecycle methods are not executed. The values in the operation context (data, input, dispositions, validationViolations) are returned to the client.

beforeSave

{ beforeSave: OperationCallback<boolean> }

In the beforeSave callback you would typically check / manipulate validated data from the operation before they are saved or stop the following execution (by returning false).

If this method returns anything else but true the following lifecycle methods are not executed. The values in the operation context (data, input, dispositions, validationViolations) are returned to the client.

You can either provide an implementation for this callback or use one of the following shortcuts for typical use cases (for details see beforeValidation).

save

{ save: undefined | true | false | (ctx:OperationContext) => boolean|Promise<boolean> }

You can either rely on the saving of entity items from the input or implement any business logic in this method, whether it actually includes saving of entities or calling 3rd party APIs or anytime else.

If this method returns anything else but true the following lifecycle methods are not executed. The values in the operation context (data, input, dispositions, validationViolations) are returned to the client.

afterSave

{ afterSave: undefined | (ctx:OperationContext) => boolean|Promise<boolean> }

If this method returns anything else but true the following lifecycle methods are not executed. The values in the operation context (data, input, dispositions, validationViolations) are returned to the client.

You can either provide an implementation for this callback or use one of the following shortcuts for typical use cases.

buildResult

buildResult: undefined | (ctx:OperationContext) => boolean|Promise<boolean>

afterBuildResult

{ afterBuildResult: undefined | (ctx:OperationContext) => void|Promise<void> }

You can either provide an implementation for this callback or use one of the following shortcuts for typical use cases.