posts-go/posts/2022-07-31-experiment-go.md

Experiment Go

There come a time when you need to experiment new things, new style, new approach. So this post serves as it is named.

Design API by trimming down the interface/struct or whatever

Instead of:

type Client interface {
    GetUser()
    AddUser()
    GetAccount()
    RemoveAccount()
}

// c is Client
c.GetUser()
c.RemoveAccount()

Try:

type Client struct {
    User ClientUser
    Account ClientAccount
}

type ClientUser interface {
    Get()
    Add()
}

type ClientAccount interface {
    Get()
    Remove()
}

// c is Client
c.User.Get()
c.Account.Remove()

The difference is c.GetUser() -> c.User.Get().

For example we have client which connect to bank. There are many functions like GetUser, GetTransaction, VerifyAccount, ... So split big client to many children, each child handle single aspect, like user or transaction.

My concert is we replace an interface with a struct which contains multiple interfaces aka children. I don't know if this is the right call.

This pattern is used by google/go-github.

Find alternative to grpc/grpc-go

Why? See for yourself.

Also read:

• A new Go API for Protocol Buffers to know why v1.20.0 is v2.
• Go Protobuf Plugin Versioning.

Currently there are some:

• bufbuild/connect-go. Comming from buf, trust worthy but need time to make it match feature parity with grpc-go.
• twitchtv/twirp
• storj/drpc

Thanks

• API Clients for Humans