MVCS Best Practice - Provider Layer

Table of Contents

• Introduction
• Provider should be simple & dumb
• Don’t expose the http code using provider

Introduction

Provider interface with external services. They are used to map your request and response types to and from the external service format, including setting up the corresponding headers and request body. In short, you can see it as gateway to external services.

Provider should be simple & dumb

• Similarly to the repository where it comes to interfacing with data storages, the provider should not contain any business logic or complex validation logic.
• Provider can still be opinionated about whether what kind of response is acceptable to the application. For example, to validate if one of the response fields is not expected.

func (p *provider) SignMessage(ctx context.Context, req SignMessageRequest) (*SignMessageResponse, error) {
    iRes, err := p.signMessage(ctx, req)
    return iRes.SignMessageResponse, err
}

Don’t expose the http code using provider

• Unless in some very specific cases, the provider should not expose the http code to the service layer. The provider layer should be responsible for handling the http code and mapping it to the response.
• All http error code should already be encapsulated in the circle error, and you can use CircleErrorDetail for error handling.