Example StringSvc3 Has Endpoint Code Mismatch

[mattc41190]

In the third section of the example stringsvc application the guide tells the user that the following snippet is the correct definition for a proxied version of the Uppercase service:

func (mw proxymw) Uppercase(s string) (string, error) {
	response, err := mw.uppercase(uppercaseRequest{S: s})
	if err != nil {
		return "", err
	}
	resp := response.(uppercaseResponse)
	if resp.Err != "" {
		return resp.V, errors.New(resp.Err)
	}
	return resp.V, nil
}

Since mw.uppercase returns an Endpoint and Endpoints must recieve two args this cannot be correct.

Meanwhile, the code in GitHub has this definition:

func (mw proxymw) Uppercase(s string) (string, error) {
	response, err := mw.uppercase(mw.ctx, uppercaseRequest{S: s})
	if err != nil {
		return "", err
	}

	resp := response.(uppercaseResponse)
	if resp.Err != "" {
		return resp.V, errors.New(resp.Err)
	}
	return resp.V, nil
}

The example code in the guide should likely include ctx as part of the struct and ctx should be included in the response variable creation.

There was recently some work done to remove ctx from the earlier examples in stringsvc1. Perhaps there is already work being done in this area?

Sources:

http://gokit.io/examples/stringsvc.html#calling-other-services
https://github.com/go-kit/kit/blob/master/examples/stringsvc3/proxying.go#L69-L90

[jstoja]

I think that the rationnale is that, context is not needed in these examples, and it has been removed from the StringSvc1 example to avoid clutter and make it easier to understand.
I guess we could just remove either context from the StringSvcvX examples or, actually add the context bit on the website to explain why it could be used and how to pass it.

I'd be in favor of removing it in all the StringSvc since it's covered in the "Advanced topics" area on the same page.

[peterbourgon]

#1197