> First of all, when introducing a new resource type, you'd have to change the main config.js file as well

Introducing a new resource type would only require this if you need to make changes to the schema, which may not be all that common. If you simply want to add new properties to be stored and not indexed, schema extension is not necessary. If you simply want to add new properties to be indexed and not stored, you can simply add the property to the document (ElasticSearch's schemaless nature lets you do this). I think it covers 99% of the cases.

When you'll want to extend the schema is if you want more advanced configuration such as a property that has custom analysis, or something that is indexed **and** stored (though theoretically you could use a combination of the `_extra` and schemaless property for that case too).

> and requires maintenance of a patch to the main codebase

Every single deployer will need to have customizations in config.js. We shouldn't think of any changes here as a "patch to the main codebase". It's why I didn't want us to be doing `require('../../../config')` everywhere to get the config. For example, we can allow a command-line argument to point to where the config.js file is on the filesystem on startup. In our puppet env. we don't maintain a patch, we simply overwrite the whole thing with the system config.

> Also, there's a risk here that developers working on a new resource type would have it all working locally, as they'd be starting from a new > index. When it is then brought into a live environment, it wouldn't actually be picked up as the index would already exist. Not sure if there's > anything we can do about that one though.

While we can deploy new schema properties on the fly, we can't guarantee that updates to existing properties are compatible with the existing data in the index, so in general it would be flukey.