Plugin architecture is too rigid

[unclecheese]

The plugin API is filled with contracts that make it difficult to create flexible, reusable code. At the moment, we have:

• FieldPlugin
• TypePlugin
• QueryPlugin
• MutationPlugin
• ModelTypePlugin
• ModelQueryPlugin
• ModelMutationPlugin
• ModelFieldPlugin

While this is great for keeping the abstraction layer tight, it's less practical than a more loosely typed approach with imperative checks for typing.

Consider the sort or filter plugins. At the moment, these are specific to model-generated queries. But you may have a custom query that you want to add sort to that returns dataobjects. That should work, but due to the contract, you can't use the sort plugin. Ideally, the plugin should be able to adapt itself to model-generated queries, custom queries, or even just generic arrays (it may then ask you to provide a resolver, but at least you'd have 90% of the work done). This happens in pagination as well.

This isn't a great path to be on out of the gate, before we seal the API. It will lead to a lot of redundant plugins with similar names that no one will remember that will be easy to misplace in your schema. It requires the developer to know too much.

I propose we reduce all of this to:

• FieldPlugin
• TypePlugin
• ModelTypePlugin

After all, GraphQL schemas are just types and fields. The internals of our "models" system can be negotiated from with in the plugin with instanceof checks if need be. We'll keep ModelTypePlugin simply because the model (e.g. DataObjectModel) gets to assign these to each type it creates, and it's a very specific path that must be followed, so there is a good reason to maintain that contract.

[unclecheese]

Now that we're in alpha, this has been converted to an RFC: #364