Current implementation

Right now there is no concept of providers in the codebase, it's only in configuration API. Calling AWS Lambda or HTTP endpoint is implemented in Function struct (https://github.com/serverless/event-gateway/blob/master/function/function.go) as callAWSLambda or callHTTP private functions. Depending on provider type defined in a function configuration adequate function is called.

Downsides of that approach:

• no way to unit test provider implementation (e.g. AWS SDK in not injected dependency, it's created inside callAWSLambda method)
• one huge Config struct containing all possible fields (https://github.com/serverless/event-gateway/blob/master/function/function.go#L48-L67) for different providers

Proposed solution

function package defines Provider interface that provider need to implement

// Provider is an interface for function provider.
type Provider interface {
        // Call function based on provider configuration
	Call(payload []byte) ([]byte, error) 
        // MarshalLogObject is required for uber/zap logger so we can control how configuration is printed in logs (we need this for hiding sensitive information like AWS keys)
	MarshalLogObject(enc zapcore.ObjectEncoder) error
}

function package defines ProviderLoader interface that returns Provider instance configured based on JSON blob (configuration)

// Provider is an interface for function provider.
type ProviderLoader interface {
	Load(config []byte) (Provider, error)
}

function package exposes RegisterProvider function that expects provider type and provider loader. During function create (unmarshaling) adequate loader is fetched and based on JSON config it returns Provider instance which is attached to function instance.

Each provider needs to register itself in init() function.

Thanks to that

• each provider can be implemented as a separate struct in separate package
• we can easily inject dependencies to Provider
• each provider has separate config object that is validated by provider during loading phase