Add context to Signer interface

[kchiranjewee63]

This PR adds context.Context to the Sign method of the Signer interface to support timeout and cancellation for signing operations, useful for HSM or network-based signing implementations.

[richardxgao]

While the context.Background() can be used, it's typically used for initialization since it doesn't have a deadline and is never cancelled. Instead, we should use context.WithDeadline() or context.WithTimeout() with (for-now) a hard-coded timeout which we can later refactor to be an env variable.

[kchiranjewee63]

While the context.Background() can be used, it's typically used for initialization since it doesn't have a deadline and is never cancelled. Instead, we should use context.WithDeadline() or context.WithTimeout() with (for-now) a hard-coded timeout which we can later refactor to be an env variable.

These are example codes demonstrating how to use the library. I'm not sure if adding a timeout here provides any additional value. Using context.Background() seems simpler and more straightforward.

[richardxgao]

While the context.Background() can be used, it's typically used for initialization since it doesn't have a deadline and is never cancelled. Instead, we should use context.WithDeadline() or context.WithTimeout() with (for-now) a hard-coded timeout which we can later refactor to be an env variable.

These are example codes demonstrating how to use the library. I'm not sure if adding a timeout here provides any additional value. Using context.Background() seems simpler and more straightforward.

I believe it does add value in the sense that we're demonstrating best practices in our examples. See the sgnl repo for examples on context.WithTimeout().

[kchiranjewee63]

While the context.Background() can be used, it's typically used for initialization since it doesn't have a deadline and is never cancelled. Instead, we should use context.WithDeadline() or context.WithTimeout() with (for-now) a hard-coded timeout which we can later refactor to be an env variable.

These are example codes demonstrating how to use the library. I'm not sure if adding a timeout here provides any additional value. Using context.Background() seems simpler and more straightforward.

I believe it does add value in the sense that we're demonstrating best practices in our examples. See the sgnl repo for examples on context.WithTimeout().

I agree. It would show good practice, but adding a specific timeout value in the documentation feels odd. What timeout value should I add? Timeout value depends on application-specific implementation and is application-specific decision. Examples here do not make any network call for signing the token. It just usages a dummy, in-memory key. So a really small timeout value would be appropriate here. But in real code, which most likely makes a network call, this timeout value would not be right.

Also, I kind of feel adding a specific timeout in the documentation distracts from showing the main functionality of the library.

Let me know your thoughts.

[richardxgao]

Timeout value depends on application-specific implementation and is application-specific decision

Yes, that's correct hence why it ultimately should be a configurable env variable and not a hard-coded timeout value. But for the sake of this example code, I think a hard-coded timeout value is good enough as it reminds the user to set a timeout and avoid using the context.Background().

I don't believe we should be concerned with the specific timeout value we choose to use in this example. We should be concerned with demonstrating/reminding that a timeout should be configured. In fact, let's add a comment above the timeout code reminding the user to set their own appropriate timeout.

Also, I kind of feel adding a specific timeout in the documentation distracts from showing the main functionality of the library.

I don't believe this should be case -- a context timeout is almost always seen in any networked/unbound calls in Go clients, so it really shouldn't add much mental overhead.