@cadey in the post you mentioned:

> Be sure to avoid creating a "god context" across your entire app. This is a known anti-pattern and this pattern should only be used for small command line tools that have an expected run time in the minutes at worst, not hours like production bearing services.

i suppose i'm the newer crowd to the ecosystem but i'm missing the context (lol) on this, specifically "not hours..." — any pointers?

Follow

@wilson @cadey iirc (from my Go-writing times) conceptually, context is supposed to be "an operation" -- something with a well-defined start/stop (it may spawn off sub-tasks, etc, but in the grand scheme of things it's a single overarching "thing" that you track from beginning to end).

Contrast that with a production service, which is a long-running listener that may spawn operations, but isn't a well-defined operation itself. It's a kinda different-but-related thing that wants an integration with contexts but isn't a context itself, and it often grows to want extra/different features (e.g. managing running requests with their own, standard timeouts, independent background loops which start & stop over the lifetime of the service, blocking until graceful shutdown, etc).

I guess a litmus test would be "could you conceivably put a timeout on it and not be unhappy".

Alternatively, would you conceptually model the thing as (in rust notation) fn thing(in: Inputs) -> Outputs or fn thing(in: Inputs) -> !. The former wants a context I think, the latter does not. 🤷‍♀️

Sign in to participate in the conversation
Toot.Cat

On the internet, everyone knows you're a cat — and that's totally okay.