Make "instance" a core SDK idea

[ryantxu]

on the frontend, a plugin instance is managed independently -- on the backend each request needs to sort out which instance it is and does not have a clear place to initalize/destroy config changes

Perhaps something like:

type InstanceRecycler interface {
	Recycle() error
}

type PluginInstance struct {
	CheckHealthHandler  CheckHealthHandler
	CallResourceHandler CallResourceHandler
	QueryDataHandler    QueryDataHandler
	Recycler            InstanceRecycler
}

type PluginHandler interface {
	CreateAppPluginInstance(ctx context.Context, config PluginConfig) (*PluginInstance, error)
	CreateDataSourceInstance(ctx context.Context, config PluginConfig) (*PluginInstance, error)
}

The SDK would then manage calls so that:

• Create{DataSource|AppPlugin}Instance was called when appropriate
• the correct instance is called for each health|query|resource|... request
• when the configs change (based on the time parameter) the Recycle function is called

Thoughts? This is related to #99 -- and hopefully explains why I think this solves @bergquist's issue with the healthcheck clarity

[marefr]

I'm not sure this makes things easier since the handlers are still of the same contract. Regarding CreateAppPluginInstance/CreateDataSourceInstance, either you would have an app plugin or a data source plugin. Also in the frontend you have constructors so I don't think doing a 1-1 mapping is optimal. But good input and gives me some ideas.

[kylebrandt]

So thinking about this, I think some practical plugin building problem something like this should help with:

An instance of something, often, will have its own API client to something else in the backend - amc azuremagic/client ... client := amc.NewClient(stuff from plugin/datasource config). We would want to reuse that API client between requests, on a per instance basis.

So for example, a SQL backend plugin might have multiple instances configured in Grafana. Each instance probably holds something like a connection string. So a client gets created from the connection string, and it is far more efficient to reuse that client and underlying connections when possible.

Also caching would be a per instance thing.

[marefr]

I'm not saying no the concept of caching http clients/connections. But I think I prefer a solution similar to what we have in Grafana backend.

[bergquist]

Frontend plugins can assume that all datasources talk over HTTP so it's a little bit easier to construct instances. For backend plugins, the plugin author would have to implement a constructor function to create the instance since we don't know what kind of client is returning data filereader/db client/http client. Clients will behave differently.

As I see it we either create helpers that can help with cache/client management or we require the plugin author to pass a constructor function at serve. I think the helper route is simpler to reason about and debug. Passing a ctor function at serve sounds like fun code to write and could be quite elegant in some cases.

My issue with health check is that its that we use the same endpoint for health checking the entire plugin and health checking a configured datasource.