Context of the problem (already solved)

Issue

We are providing some assets on our CMS, these assets change over time (we modify them) and makes it really hard to update considering these are stored on the DDBB and the client might have made changes to the CMS template and these changes depend on the version. Our best example is swagger-ui-rails which we are providing as a gem, so even making a rolling update is really hard to implement.

Solution

Best solution would be having a CDN where we provide the versions we are maintaining. Thus, when we are releasing a new update, the change on the template will be relatively easy, no rolling update, no gems in our codebase, we just provide a new version and the client decides to use it or not.

Implementation
Structure of files
Path
//[host]/[lib_name]/[version]/[file]

I.E:

//cdn.3scale.net/swagger-ui/2.2.10/swagger-ui.min.js

Tree
.
├── swagger-ui/ # Swagger UI lib
│ └── 2.2.10/

├── jquery/
│ ├── 3.2.1/
│ └── ...

Hosted version

We deploy the CDN from Git.

On Premise version

We either could copy the files to a System directory from our CDN or provide a separate component.

Uploading files

We will be maintaining the Git repo. We could automate the process providing a Makefile with tasks to update the desired libs (specific versions maybe) from other CDNs, download them and push them to our repo.

Libraries info

A index.json file will list the libraries, their versions and repos. It will also help to generate the tree when deploying or including it inside system for dev or on prem versions.
Further more, each library will have its own index.json defining the versions, licenses, files and repo.

The new problem

The assets we generated use a different Sprockets::Environment instead of the Rails one
This is intended to solve the first issue, as we wanted to separate developer portal assets and admin portal assets.

Though we probably do not want that anymore and serve those assets under a common CDN which cannot be achieved now.

The proposal is to namespace under dev-portal directory those assets and use the Rails default sprockets environment

RELEASE NOTES:

• ASSETS_CDN_HOST has been removed. It was being used only for the Developer Portal assets, but now those assets are compiled and loaded from a CDN using the Rails standard way. Use RAILS_ASSET_HOST instead.
•  RAILS_ASSET_HOST now accepts values with and without the http schema prefix: http:// or https://. If no schema is provided, it will default to the same schema porta is using.
• Assets loaded by the cdn_asset liquid tag have been moved from /cdn to /public/dev-portal-assets.
  • For clients not using ASSETS_CDN_HOST, the Developer Portal assets must be moved to this new folder.
  • For clients using ASSETS_CDN_HOST, the Developer Portal assets can be moved to the this new folder where the CDN will find them and cache them. Or they can be uploaded directly to the CDN.