Add support for enabling nested mutation from CLI

[ayush3797]

This issue tracks the efforts needed for exposing the feature flag options through CLI commands and subsequently, serializing the same in the config file.

[severussundar]

Proposal:

Property Name: nested-inserts-enabled
Position in the config file: This will be a property within runtime.graphql. Placing the element here implies that when the field is set to true/false, the nested inserts feature is enabled/disabled for all the entities.

Deafult behavior: Nested Inserts will be enabled be default.

One more thing to note: When the property is updated to true/false to enable/disable the feature, the engine will have to be restarted for the change to take effect.

In the first iteration, hot reloading of this flag will not be supported. This can be added iteratively in the subsequent versions (if needed).

@JerryNixon @Aniruddh25 @seantleonard @ayush3797 Please kindly share your thoughts.

[ayush3797]

In future, we might also add support for nested updates. Having a stand-alone property directly in the config for nested inserts won't scale well. Instead, we should add an object (something like nested-mutations) and then inside that object we can have objects storing properties for inserts/updates.

Also we should be creating objects for inserts/updates because we don't know what all inputs we might need from the user. In future, we might also allow them to specify the nesting limit (due to obvious payload size considerations). Then such a property can also go in the already existing json object. This is just one use case I can think of right now but more can come up as we move forward.

"nested-mutations":{
    "inserts":{
        "enabled": true,
        "nesting-limit": 10
    },
    "updates":{
        "enabled": false,
        "nesting-limit": 10
    },
}

Obviously, to start with, we would not add the section for updates.

[JerryNixon]

Would this also be a possibility to reduce syntax?

"nested-mutations":{
    "*":{
        "enabled": true,
        "nesting-limit": 10
    },
    "inserts":{
        "enabled": true,
        "nesting-limit": 10
    },
    "updates":{
        "enabled": false,
        "nesting-limit": 10
    },
}

[severussundar]

Yes, * would help eliminate redundant entries when the same settings are to be applied for all the operations.

I am inclined to start off with just the insert section. The reason being that, nested update operation is still under evaluation.
When adding the support for update operation, the logic for interpreting * as insert + update can be introduced.

Adding it now is pre-mature for the following reasons:

1. * would expand to only insert
2. When adding support for update, a logic change would definitely be required in both CLI and engine to interpret * to be insert, update. So, we can introduce * when implementing the update operation.

Also, I want to call out nesting-limit will not be added right now (In the first version, there will be no restrictions on the depth of operations) . In the example, the field nesting-limit was added to emphasize that creating an object type will make it easier to add more fields in the future.

For the first version, the exact format of the feature flag would be

"runtime":{
      ...
      "graphql": {
           ...
           "nested-mutations": {
               "insert": {
                     "enabled": true/false
               }
           }
      } 
}

[JerryNixon]

100% agree.