Refine Back-End Independence

[JanMiksovsky]

Breaking out this feedback from @arkihillel in #10:

Back-End Independence — Can the component retrieve its content from a variety of a back-end services?

This rule will be practically impossible to enforce in some cases. Take the <google-map> Polymer element for example. While, in theory, it could support other services, it just wouldn't make sense to bundle them all under the same component

Agreed. I think it's appropriate for a component to depend on a specific backend if that's the entire purpose of the component. The main concern here is to avoid components that depend on a specific service that's incidental to the component's stated purpose.

If the page were rewritten along the following lines, would that help?

✓ Back-End Independence

Does the component avoid unnecessary dependency on a specific back-end service?

Some components are designed to be used only with a specific company or organization's services. A case in point might be the google-map component which renders a map using Google Maps. Since the purpose of the component is to expose that specific back-end service, it's reasonable that the component only works with that service. The component's name clearly expresses that focus/limitation.

However, front-end components that solve more general-purpose problems should ideally support a range of back-end services. If you are creating a rich text editor component and want to offer a way to store and load editing preferences, it's probably best to avoid embedding a dependency on a specific back-end service like Dropbox into your otherwise general-purpose editor. A better solution might be to factor the preference storage aspect into something that permits storing preferences in a variety of services (both public and private), and offer a connector that saves preferences to Dropbox as a separable option.