When you need to share media assets across multiple sites, you can take advantage of tools you’re already using to make that process simple and convenient.
While I love using file-based content (Markdown, JSON, etc.) as the source for web properties, I find committing assets to those same repos to be problematic.
Generally, I avoid committing assets to code repositories for three reasons:
There are two solutions I see most frequently used to curb these problems:
If you're already using Netlify to deploy and host web projects, you can take advantage of the service and use it to host shared assets for your projects.
Then you push these to a new Netlify site. There's no build involved, so assets pushed to your main Git branch are typically available within seconds.
You can even choose to tie a custom domain to your project — e.g. assets.example.com.
If you combine this solution with Netlify's Large Media feature (which uses Git LFS), Netlify also provides the ability to transform images on the fly, making this solution competitive with other CDN asset providers.
Wait. Isn't this what I said not to do? Yes, sort of.
This repository can get bloated. It requires Git LFS to optimize, and that can get expensive. But, the repo is one in which developers aren't trying to do anything else, which lessens the frustration with bloat.
Because of that, this may not be the answer for all of your assets. But it's a very quick and convenient way to share assets across projects using the tools and services you're already familiar with.
A super simple example of building a static API that walks through the deploy process using Netlify. Part of a series of tutorials on building and deploying static APIs.
An introduction on how to approach building a static API, which serves as the background for several specific tutorials on the topic.