bitdao-io / bitdao-governance

https://delegate.bitdaotools.io
2 stars 4 forks source link

[Feature] Place non-code digital assets in their own repo #48

Closed shahankhatch closed 2 years ago

shahankhatch commented 3 years ago

Feature Description

Currently, non-code assets (e.g., SVG files, logos, fonts) are sprinkled across projects. E.g., the landing page includes the digital assets, while the delegate page references an S3 bucket (managed by a different team).

In order to establish improved control over our digital assets, place all non-code digital assets in their own repo and version the repo.

This will allow more stable development, testing, and deployment as we produce releases. Products that rely on these assets can then be upgraded at their corresponding pace.

In addition to this repo, this issue also affects the landing page repo. https://github.com/bitdao-io/bitdao-interface

octavioamu commented 3 years ago

I was thinking on this and I believe will add a lot of friction for development, using tools like https://www.npmjs.com/package/s3-folder-upload to sync the new assets to s3 on deploy time seems a better approach, even we can have setup on env's for staging and production.

shahankhatch commented 3 years ago

The problem with deploying the assets directly to S3 is that the version of asset can change without the front end being ready for it (this happened during the landing page's development). Trying to version something on S3, such as by including version numbers in the naming conventions may require hardcoding that into front ends.

Essentially, by placing the asset into its own repo, then downstream consumers of the assets will obtain a specific version, will build their static page, and they themselves are deployed to S3 (and will carry the assets with them). Note that the S3 deployment of static websites is the standard approach we're taking.

Does that help to clarify?

shahankhatch commented 3 years ago

Relatedly, we don't benefit from deploying the svg assets to S3 as we shouldn't be serving them directly to consumers. They end up on S3 as part of the static page build and deploy pipeline.

octavioamu commented 3 years ago

Mmm not sure I get 100% but what I use to do have 2 node commands one for local that serves images from localhost, in that way I can change images and add remove them. Then the build command, that will do minification transform js and scss to css optimize images and hash all the files change the routes names of the files to mach the hashed ones and the upload all that files to a S3.

the hashing part and the build changes are handled in our case by react-scripts https://create-react-app.dev/docs/production-build so we don't need to manually change the hashes on each file.

shahankhatch commented 3 years ago

Sounds like a better approach. Thanks for explaining.

octavioamu commented 2 years ago

Closing as solved on #76