Do we need a plugins concept?

[austencollins]

Is there a plugin concept for V.2?

[austencollins]

In a recent feedback session, Maciej wanted to know how safeguards might work with this offering. I prototyped a version of Safeguards a while ago w/ an older V.2 version.

The way I made it work was I created some middleware that ran between receiving inputs and calling the Component with them, and between receiving outputs and passing them to the parent Component. This would allow a Safeguards offering to review and/or modify data before and after a Component interacts with it.

Perhaps these could be useful hooks for a plugin implementation. It would solve the safeguards problem for starters.

[austencollins]

Additional use-case: plan.

While it's difficult to create a plan feature (like terraform's) in our current set-up, there might be something we can do to get close.

It would use the middleware concept above and prompt the user each time a child component is about to be deployed, showing the inputs it's about to use and possibly doing a diff against previous inputs.

[eahefnawy]

I think it would be a nice addition if each component exposes a plan() method that describes the resources it'll create, might also expose the minimum required credentials (or maybe a separate method). This method would be optional but encouraged. That fits well with our plans with Certified Components.

With this in place, it would be easy for enterprises (ie. Cloud Applications Teams) to write their own components with safeguard scripts in place:

class SafeGuards extends Component {
    async default() {
        const chatApp = this.load('ChatApp')
        const resources = chatApp.plan(inputs)

        // safeguard script here based on resources...
        // throw errors...etc
    }
}

I'd really rather not introduce a new Plugins concept to keep things simple. Because we have a great programmatic support story, and a very simple component API, I think we should instead think around how to fit SafeGuards around components rather than plugins.

Also, since SafeGuard is an enterprise feature, it's safe to assume that they'll exclusively write components programmatically. The way I imagine it is that each enterprise would write their own component with SafeGuard features for their developers to consume.

[pmuens]

While I agree that a plugin system might be too much ATM I just want to call out that having a well designed plugin system greatly helps adopting the Framework later on.

Our v1 plugin system wasn't the best but at the end it enabled users to implement their own functionality when something essential for them was missing. Furthermore having such as system we could withstand merging external PRs which could be implemented via plugins instead. We should really nail down the goals for v2 and don't merge anything which doesn't align with this. I think this was one of the mistakes we made with v1.