Discussion: Content Organization Best Practice

support
9

@jgreely Yes, externally hosting binary assets is a valid case that I have also been thinking about using for some of my larger projects. Like you said, let’s call this Strucutre C:

Structure C

Keeping most binary assets in external storage (like S3, Cloudinary, .etc.) instead of keeping them inside the Hugo folder structure.

Pros

  • Keep Git repo small: Most Hugo projects are stored in a Git repo. Even if Git is not ideal for storing binary assets this is no problem for smaller projects. But if a project gets larger (let’s say over ~600MB) keeping everything in a Git repo might slow down everything.
  • Very fast build process (especially helpful for things like continuous deployment - Netlify and the like).
  • Asset pipeline (like resizing images) can be handled by scripts or completely outsorced to platforms like Cloudinary or imgix.

Cons

  • Setup is complicated. Instead of one place for the entire site, content it is spread out over two platforms.
  • Managing assets in an external storage can be a pain (same with static folder in Structure A): If we put all images in one storage it is difficult to tell which images are still in use and which images
    could be deleted. We could replicate the entire structure of the content for images but this is also a lot of work to maintain.
  • References to images are long and may lead to mistakes
    (for example https://my-external-storage.on-amazon-s3.com/my-bucket/12341232344234.jpg).

CONTENT

No assets in the content folder.

├── content/
    └── _index.md
    └── about/
    │   └── _index.md
    └── blog/
        ├── _index.md
        ├── firstpost.md
        └── secondpost.md

STATIC

Static folder is almost empty. Most assets are stored in an external storage.