This issue is a placeholder for a potential Tech Review post.
I've been considering the possibility of standing up a new service, potentially as a serverless node app (Express.js?) running in AWS Lambda that can talk to S3. The service would provide a simple API by which an app could be migrated from v1 -> v2. Input might potentially be a reference to a v1 app upload in S3, output could be a reference to a new app upload in S3. If not input/output as just described, the service could accept a zip (v1), and return a new zip (v2).
Other thoughts:
The service would be accessible within our network only
The service could potentially be stateless
Access to the service would be provided via Cactus, the App Developer Console. This would mean we could proactively message developers with v1 Public apps, and motivate them to upgrade to v2
Potential challenges:
The migrator output will likely never be 100% production-ready, i.e. developers would need to do some manual migration before updating via Cactus.
The number of Public v1 apps might not warrant standing up a completely new service.
Once Public apps were migrated to v2, the service might no longer be useful.
The cost in AWS could be prohibitive.
There may be some infrastructure-related constraints with using AWS in this way
@danielbreves @pmgrove appreciate your input on this idea
This issue is a placeholder for a potential Tech Review post.
I've been considering the possibility of standing up a new service, potentially as a serverless node app (Express.js?) running in AWS Lambda that can talk to S3. The service would provide a simple API by which an app could be migrated from v1 -> v2. Input might potentially be a reference to a v1 app upload in S3, output could be a reference to a new app upload in S3. If not input/output as just described, the service could accept a zip (v1), and return a new zip (v2).
Other thoughts:
Potential challenges:
@danielbreves @pmgrove appreciate your input on this idea