New FAQ entries

[peterbourgon]

• Introduction — Understanding Go kit key concepts
  • Transport, Endpoint, Service
  • Middlewares in general
  • Endpoint Middleware, Service Middleware
• Dependency Injection — How do I wire up my Component Graph?
• Configuration — How should Go kit services be configured?
• Persistence — How should Go kit services manage persistence?
  • Repository pattern
  • e.g. In-Memory & PostgreSQL
• Caching — How should Go kit services interface with cache systems?
• Logging — How should Go kit services manage logs?
• Metrics — How should Go kit services be instrumented?
• Service Discovery — How should Go kit services interact with service discovery systems?
• Templating — What if Go kit services want to render web pages?
• How do I decide where to place a bit of functionality?

[andreaslacza]

Lets say you want to create a CRUD app like gokit example service profilesvc

In Go kit, services are typically modeled as interfaces, and implementations of those interfaces contain the business logic.

type Service interface {
PostProfile(p Profile) error
GetProfile(id string) (Profile, error)
DeleteProfile(id string) error
}

Persistence — How should I work with databases and data stores? Even better: consider defining an interface to model your persistence operations. The interface will deal in business domain objects, and have an implementation that wraps the database handle.

type Store interface {
    Insert(p Profile) error
    Select(id string) (Profile, error)
    Delete(id string) error
}

type databaseStore struct{ db *sql.DB }

func (s *databaseStore) Insert(p Profile) error            { /* ... */ }
func (s *databaseStore) Select(id string) (Profile, error) { /* ... */ }
func (s *databaseStore) Delete(id string) error            { /* ... */ }

type Service interface {
    PostProfile(p Profile) error
    GetProfile(id string) (Profile, error)
    DeleteProfile(id string) error
}

type MyService struct {
    store  Store
    value  string
    logger *log.Logger
}

func NewService(store Store, value string, logger log.Logger) *MyService {
    return &MyService{
        store:  store,
        value:  value,
        logger: logger,
    }
}

func (s *MyService) PostProfile(p Profile) error           { /* ... */ }
func (s *MyService) GetProfile(id string) (Profile, error) { /* ... */ }
func (s *MyService) DeleteProfile(id string) error         { /* ... */ }

both interfaces share the same methods.

why not?

type Service interface {
    PostProfile(p Profile) error
    GetProfile(id string) (Profile, error)
    DeleteProfile(id string) error
}

type databaseStore struct{ db *sql.DB }

func (s *databaseStore) PostProfile(p Profile) error           { /* ... */ }
func (s *databaseStore) GetProfile(id string) (Profile, error) { /* ... */ }
func (s *databaseStore) DeleteProfile(id string) error         { /* ... */ }

type MyService struct {
    databaseStore  Service
    value          string
    logger         log.Logger
}

func NewService(databaseStore Service, value string, logger log.Logger) *MyService {
    return &MyService{
        databaseStore:  databaseStore,
        value:          value,
        logger:         logger,
    }
}

func (s *MyService) PostProfile(p Profile) error           { /* ... */ }
func (s *MyService) GetProfile(id string) (Profile, error) { /* ... */ }
func (s *MyService) DeleteProfile(id string) error         { /* ... */ }

[peterbourgon]

Because although they may have a similar method set, a Repository layer is, importantly, conceptually distinct from a Service layer.