Extract Asset Plugin code to make it easy to upload assets from any plugin

[philnash]

This is a placeholder for a discussion about how to share asset uploading code between plugins like the Asset plugin and the Flex CLI.

[dkundel]

@ktalebian is the better expert here but from my understanding the Flex CLI essentially just uploads an Asset to an existing Service. In the past this wasn't compatible with the way the Serverless Toolkit works because we didn't support "additive" deployments.

The plugin-assets package essentially does that "additive" deployment. So we could take that same logic, add it to the serverless-api package instead and the Flex Plugin Builder could pull that one in.

@philnash you mentioned that plugin-assets is opinionated as it doesn't allow you to upload an Asset to a Service that already has a Function in it. Realistically we could move that check into a dedicated flag of the API or keep that logic solely in the plugin-assets. However, I could also see the benefit of customers wanting to add Assets to any service even if it has Functions. Specifically if they created the service through the UI or Quick Deploy but want to update an Asset programmatically.

[philnash]

Part of the reason for that opinion, and also that plugin-assets only uses a production (with name set to empty string) environment, was to avoid too many lookups or confusing things regarding environments and builds. This let the plugin create a service and environment that it could then refer to in its config.

We could make this work for all services by mandating the inclusion of a service sid and an environment sid. That way we can look up the latest build in an environment, add the asset and all the existing functions, assets and dependencies to a new build that is then deployed.

Since the service created in the first place stores its service sid and environment sid in plugin settings this doesn't change the behaviour for the default service. The plugin could then accept --service-sid and --environment-sid flags that allow it to upload to any service. Further you could twilio assets:init more service/environment pairs and give them names so that you could then run twilio assets:upload FILE --service NAME to pick the service from the config.

Pros and cons

I see the pros of being able to add an asset to something like a quick deploy function.

The main con I see here is that, since there is no way for plugin-serverless/twilio-run to pull content from assets, if you used this on a twilio-run deployed service you could potentially break things when you next deploy with twilio serverless:deploy as the asset would be left out of the build. Adding an assets:download command (as suggested here) could mitigate this somewhat.

[ktalebian]

@dkundel even though we do upload the bundle to Twilio Serverless, we need to do some checks prior to upload, and then perform some registrations after the upload.

So, we would never advertise customers to use the new CLI command themselves. We still want them to upload the plugin using our CLI.

However, if you could make this toolkit exportable, then we can use it as a dependency in our CLI.

[philnash]

Ok, I think I can do something here!

I think the best plan will be to move the functionality to serverless-api and have it work off the client object, like deployProject which performs a bunch of tasks and emits status update events.

Will try to get some time on this soon.