Setting context value and using context as

Hi,

As you can see below I am creating a context, setting a key/value pair (never mind the key type, I know it shouldn’t be defined like that) and using the context as Server BaseContext so that I can fetch it anywhere I need which works fine so far. However, what I want to know is:

  1. Am I violating anything as far as Go goes?
  2. If the answer above is no then can I also use anything as value? e.g. a multidinetional struct, logrus as logger so on.

Thanks

ctx := context.Background()
ctx = context.WithValue(ctx, "some-key", "some-value")

srv := &http.Server{
	Addr: address,
	Handler: handler,
	BaseContext: func(listener net.Listener) context.Context {
		return ctx
	},
}

you are violating context values only for request-scoped rule.

Any answer with a bit of context and justification is much appreciated. However, not to be rude, this is just like a drop in comment while passing by.

1 Like

So then don’t be rude.

Am I violating anything as far as Go goes?

and my answer seems clear and direct to your question. More then this sentence context values only for request-scoped is an iteration of its semantic. I tried to give you the rule that you violate above, if you don’t understand, please ask, if you don’t think you are violating the rule, please explain why. I commented it while I was having bus, it is true. But you got what you ask for, right?

Anyway, I drop a couple links here.
https://golang.org/pkg/context/
https://www.ardanlabs.com/blog/2019/09/context-package-semantics-in-go.html

Actually, my message was nowhere near a “rude” one at all. You just got the wrong end of the stick.

There are developers who are at very different levels here. For instance, your “direct” answers can easily be considered as non “clear” ones for beginners. Hence reason, it is always better to expand on answers and justify a bit. It helps a lot. You might have dropped your very first message “while you were on the bus” but I neither think it is my fault nor a reasonable justification.

Anyway look, let’s not dwell on this and remain chilled. Why don’t you restart by enlighten me on setting a context key/value pair within a “middleware” is valid case but how I did in my example is a violation? The reason why I am asking is, I’ve seen many examples (e.g.) and suggestions on setting context key/value pair in parent context (even if application boot via server setup) in order to carry it over the wire so that it is available in “request scope” throughout the application.

Thanks

1 Like

Let’s say you are using a third library key in the context to the handlers.

ctx = context.WithValue(ctx, "some-key", "some-value")

In a handler if I see this

ctx.Value(“some-key”)

It will be ambiguous. I would think this key comes from client. Even I wouldn’t know this rule, I can’t know whether it is sent by client or it is a server configuration. This is why I think http context values should be used for request-scoped values.

If Go is providing us a feature where we are allowed to set context keys that go with their associated values then I believe there is nothing wrong with that as long as we use the keys properly. I also pointed out in my very first post by going “never mind the key type, I know it shouldn’t be defined like that”.

I still don’t see any violation in context usage here.

it is not a bulletproof rule, violation might be wrong word here but it is clear in my mind to not use a dependency variable in a context. I would inject the key in your example directly into the service/library/dependency.

Compare this two:

stripe.Charge(context.Value("key"), email string) and stripe.Charge(server.StripeKey, email string)

second one is quite clear than the first one. It says here is a constant stripe key injected into the server.
first one says it is in the context, but doesn’t say more than this. is it passed by a middleware? is it provided by server base context, is it coming from an API Gateway, is it coming from the request?

If you are using many stripe key and deciding which one to use for a user/request it makes sense to use the key in context. you would probably have a middleware, it will find out which key stripe needs to use based on the request/client and you can pass this key via context value. As you see here it is request scoped.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.