bucketeer-io/go-server-sdk

Bucketeer Server-side SDK for Go

Bucketeer Server-side SDK for Go

Bucketeer is an open-source platform created by CyberAgent to help teams make better decisions, reduce deployment lead time and release risk through feature flags. Bucketeer offers advanced features like dark launches and staged rollouts that perform limited releases based on user attributes, devices, and other segments.

Getting started using Bucketeer SDK.

Installation

See our documentation to install the SDK.

Contributing

We would ❤️ for you to contribute to Bucketeer and help improve it! Anyone can use and enjoy it!

Please follow our contribution guide here.

Setup

Install the prerequisite tools

• Go 1.15.X
• mockgen
• goimports
• golangci-lint

Install the dependencies

make deps

Development

SDK

Generate mocks

make mockgen

Format

make fmt

Lint

make lint

Build

make build

Run unit tests

make test

Run unit tests to get coverage

make coverage

Run e2e tests

make e2e API_KEY=<API_KEY> HOST=<HOST> PORT=<PORT>

# e.g.
make e2e API_KEY="xxxxxxxx" HOST="api-dev.bucketeer.jp" PORT=443

Example

Go to the example directory.

cd example

Build

make build

Start the example server

make start TAG=<TAG> API_KEY=<API_KEY> HOST=<HOST> PORT=<PORT> \
    ENABLE_DEBUG_LOG=<ENABLE_DEBUG_LOG> FEATURE_ID=<FEATURE_ID> GOAL_ID=<GOAL_ID>

# e.g.
make start TAG="go-server" API_KEY="xxxxxxxx" HOST="api.example.com" PORT="443" \
    ENABLE_DEBUG_LOG="false" FEATURE_ID="go-example-1" GOAL_ID="go-example-goal-1"

Send requests to the example server

# variation
# e.g.
curl --cookie "user_id=user-1" http://localhost:8080/variation

# track
# e.g.
curl -X POST --cookie "user_id=user-1" http://localhost:8080/track

If you want to use a published SDK instead of a local one, you can change the go.mod in the example directory.

Please check the SDK releases

go-server-sdk's Issues

test: add for cases for e2e test

To ensure the stability of the SDK, we must add more cases for e2e tests like in the other client SDKs.
We must test all the interfaces using different flags and conditions.

Proposal for Interface

import "context"

type Tracker interface {
	Track(goalID string, value float64)
}

type Client interface {
	BoolVariation(ctx context.Context, tag string, def bool) (bool, Tracker)
	Int64Variation(ctx context.Context, tag string, def int64) (int64, Tracker)
	Float64Variation(ctx context.Context, tag string, def float64) (float64, Tracker)
	StringVariation(ctx context.Context, tag string, def string) (string, Tracker)
	JSONVariation(ctx context.Context, tag string, dst interface{}) Tracker
}

type key int

const (
	keyUserID key = iota
	keyAttribute
)

func NewContext(ctx context.Context, userID string, attr map[string]string) context.Context {
	ctx = context.WithValue(ctx, keyUserID, userID)
	return context.WithValue(ctx, keyAttribute, attr)
}

feat: evaluate the user in the sdk instead of the backend

The current architecture when the get variation interface is called. It requests the evaluation directly from the server.
This approach is more straightforward but may introduce latency. Also, this could lead to infra-cost issues because it could evaluate the same user many times in a short time, even if the flag didn't change.

We should consider implementing the evaluation logic in the SDK to implement a cache similar to the client SDK.
This would improve the latency issues and reduce the requests to the server drastically, reducing the infra-cost.