README.md

Data Layer minor refactor

Problem

The existing data layer dataprovider.DataStorageProvider and store.Client has some unwanted complexity we can get rid of. This dates back to the original implementation, which was the result of Young Bu and I working in parallel.

There's a design question which was answered in two conflicting ways:

• Does a store.StorageClient work with a single resource type? OR
• Does a store.StorageClient work with multiple resource types?

---

Here's an example:

dsp := dataprovider.DataStorageProvider{} // Assume we have a storage provider

client1 := dsp.GetStorageClient(ctx, "Applications.Test/type1")
client2 := dsp.GetStorageClient(ctx, "Applications.Test/type2")

resourceID := "..." // Some resource ID

client1.Save(store.Object{ ID: resourceID, Data: ... })

// Does this work?
client2.Get(resourceID)

Does that work? Maybe ...

• CosmosDB: No
• In Memory: No
• ETCd: Yes
• API Server (default): Yes
• PostgreSQL: Yes

Simplification

Here's a short propoal:

• Remove the CosmosDB client. We're not using it. We can bring it back with git revert.
• Remove the "type" argument from GetStorageClient.
• Pick a noun (either storage or data) and stick with it.
• Make some other naming changes to be consistent with secretprovider.SecretProvider and queueprovider.QueueProvider.

Current API	Proposed Change	Comparisons
dataprovider.DataStorageProvider	databaseprovider.DatabaseProvider	queueprovider.QueueProvider
dataprovider.DataStorageProvider (interface)	databaseprovider.DatabaseProvider (struct)	queueprovider.QueueProvider (struct)
dp.GetStorageClient(ctx context.Context, name string)	dp.GetClient(ctx context.Context)	qp.GetClient(ctx context.Context)
store.StorageClient	database.Client	queue.Client
controller.DataProvider()	(removed)	n/a
controller.StorageClient()	controller.DatabaseClient()	n/a

Changes

old

type DataStorageProvider interface {
	// GetStorageClient creates or gets storage client.
	GetStorageClient(context.Context, string) (store.StorageClient, error)
}

new

type DatabaseProvider struct {
	// GetClient creates or gets database client.
	GetClient(context.Context) (database.Client, error)
}

Pick a noun (either storage or data) and stick with it.

I think "storage" is more specific than "data" so I prefer that term.

Can controller not use data.Client instead of controller.DataClient()?

Are we also removing the In-Memory implementation since it also requires type to get a resource (as it is said above)?

does the DataProvider naming potentially introduce ambiguity if in the future we support generic data providers (e.g. wikipedia, etc.) as a resource?