Define service dependencies explicitly

[mnapoli]

I'm opening this issue to track this idea/have a place for discussion.

I got a second person asking for defining dependencies explicitly:

I would love to define dependencies between services explicitly. Sometimes a service depends on another service without sharing CFN outputs.

Let's keep this idea in mind when designing everything else. I think implementing it shouldn't be too hard, it could for example be:

billing:
  component: serverless-framework
  path: billing

subscriptions:
  component: serverless-framework
  path: subscriptions
  dependsOn:
    - billing

Then the graph can be built from variable references + dependsOn (shouldn't be a huge impact on the codebase).

One downside with this approach is: it means dependsOn becomes a global reserved input across all components. This raises the point that Components v1 had:

foo:
  component: ...
  inputs:
    ...

which left room for any general component option. It's still one extra sub-key, which I'd love to avoid. But let's keep all that in mind.

Since we are talking about this, here are some general reserved component options I could imagine in the very long term:

foo:
  component: ...
  dependsOn: ...
  if: ${sls:stage} == 'prod' # conditional deployment, it has always been a pain

[mnapoli]

Note: I get asked about this a lot (1/3 to 1/2 of discussions I have), we might need to consider prioritizing that during the public beta.

[pgrzesik]

I personally like the option with nesting the inputs - it gives you clear visibility into what is passed to component and what is component-specific configuration.

I can experiment with both approaches

[mnapoli]

Nesting with the inputs key gives us that with serverless-framework:

subscriptions:
  component: serverless-framework
  inputs:
    params:
      foo: bar

[pgrzesik]

That indeed looks quite verbose - let's maybe stick to the version without nesting and validate how much of a problem that is?

[mnapoli]

👍

[pgrzesik]

Btw - should we change the parameters to params in syntax? We're still using parameters at the moment in components

[mnapoli]

Oh good point, maybe we should 🤔 I don't like abbreviations personally, but we use params absolutely everywhere else, so that would make sense to me.

[pgrzesik]

I've pushed the changes for parameters -> params both in components and platform-core repos