Component Diff'ing about components

[austencollins]

This idea was proposed by a few stakeholders in another forum. Moving it here for the OS community:

A. The component author is expected to export two functions when he wants to handle the diffing by himself (that’s what we currently have in place):

• deploy - this function creates and updates the required infra based on the state. The component author writes the diffing logic himself
• remove - this function removes the entire infra, based on the state

B. When the component author wants to let the framework handle input diffing, he is expected to export three alternative functions:

• create - this function creates the required infra from scratch
• update - this function updates the required infra without teardown
• delete - this function deletes the entire infra

Then in his serverless.yml, the component author specifies which inputs trigger a teardown when changed, and which just runs an update. Something like this:

  name:
    teardown: true # changing the lambda name for example requires deleting + creating from scratch
  memory:
    teardown: false # changing the memory should just update

The framework then checks what inputs have changed by comparing to the saved inputs from the previous state, and can determine the right action based on this teardown property (update or delete + create). Although this is now harder to do since the introduction of saveState(), because we can’t guarantee that the previous inputs have been saved to state. So the component author either needs to save the inputs to state himself, or the framework could automatically do that.

That’s basically it at a high level! I noticed that most providers/infra can follow this pattern. With this implementation, component authors don’t need to have all those state specific if statements in the deploy function in most cases. When this is not flexible enough for them, they can revert to the deploy + remove pair instead.

[austencollins]

Interesting idea. Here is my feedback:

I don't see how the Create, Update, Delete (CUD) would work for my main use-case. I am building higher-order components that dynamically set up specific children components (e.g. the Function or Subscription component) based on config given, and the Framework cannot make CUD decisions for the higher-order component because it uses dynamic infra components as children, which all need to be treated differently. This leads me to believe many component implementations cannot use the CUD approach.

How would this work for components that manage multiple resources? For example, AWS API Gateway creates many resources when you create your API. However, component authors aren't going to want to create tons of separate Components for all of the resources API Gateway needs. At the same time, when building it as one large Component, the REST API should not be torn down if an endpoint is changed, so the Component author will end up writing removal syntax in the update method anyway.

Also, all of my components have object type configuration syntax. I would not be able to use this until it supports deeply nested configuration.

How would this work with configuration arrays? When implementing diff logic in POC #242, arrays turned out to be quite tricky.

Offering duplicate ways to do something so fundamental (both deploy + remove AND create + update + delete) will create a ton of complexity, IMO. Architecture + docs + examples + tutorials + extensibility will all echo this added complexity and it will cause a general decline in DX.

I believe we should wait and learn more before considering the above suggestion. Overall, my components' logic is growing in sophistication as I optimize for speed and reliability. Yet, the above proposal seems like an oversimplification of how to handle resources. I don't think I'd use it 95% of the time. Code is the best way to handle sophistication. The un-opinionated deploy method allows the component author freedom to do what they feel needs to be done. Offering simple diff info would aides that freedom. Forcing them to handle resources a specific way limits that freedom.

[austencollins]

Created a POC for diff'ing functionality which can be found here: #242