Good question! There are a few benefits to doing it this way.
1. Backwards compatibility, as you mention. We do plan on re-evaluating and seeing what client changes would allow us to do this more efficiently, but there's a big time lag on rolling out a new npm and people actually adopting it. It's safe to say that someone out there will still be using the current release in 2 years or so, so if we can keep it working, then that's a friendly thing to do.
2. If the Skim Worker daemon falls over, the attachments are still going somewhere, and we can always have it catch up later. Apart from disasters, it also means we can treat this daemon a bit roughly. If we change a config or spin up a new one, or otherwise mess with it, no biggie.
3. In the race where you publish, and then someone fetches it right away, before the Skim Worker gets to it, the Fastly configs can detect the 404 and pull it out of the DB directly.
4. If Manta ever goes down, the skimworker will start failing (and pinging nagios, of course) and if need be, we can have the binary GETs go first to FullfatDB and subsequently to SkimDB. That Fastly config change takes about 30s to roll out, so we can mitigate downtime very quickly.
Eventually, we'll probably restructure the PUT endpoints so that it's a bit more clever, but still maintain backwards compatibility in our public API surface.
1. Backwards compatibility, as you mention. We do plan on re-evaluating and seeing what client changes would allow us to do this more efficiently, but there's a big time lag on rolling out a new npm and people actually adopting it. It's safe to say that someone out there will still be using the current release in 2 years or so, so if we can keep it working, then that's a friendly thing to do.
2. If the Skim Worker daemon falls over, the attachments are still going somewhere, and we can always have it catch up later. Apart from disasters, it also means we can treat this daemon a bit roughly. If we change a config or spin up a new one, or otherwise mess with it, no biggie.
3. In the race where you publish, and then someone fetches it right away, before the Skim Worker gets to it, the Fastly configs can detect the 404 and pull it out of the DB directly.
4. If Manta ever goes down, the skimworker will start failing (and pinging nagios, of course) and if need be, we can have the binary GETs go first to FullfatDB and subsequently to SkimDB. That Fastly config change takes about 30s to roll out, so we can mitigate downtime very quickly.
Eventually, we'll probably restructure the PUT endpoints so that it's a bit more clever, but still maintain backwards compatibility in our public API surface.