3 ms·
Yeah, but it doesn't spin up a thousand for every request. And it doesn't require you to start them. It starts them under the covers as part of the API.
by asdfasgasdgasdg 7y ago
Yeah, but it doesn't spin up a thousand for every request. And it doesn't require you to start them. It starts them under the covers as part of the API.
- jjbiotech 7y agoRight. So: * Don't require users of your API to start [additional] goroutines to use your API correctly.
- asdfasgasdgasdg 7y agoI guess what I mean to say is: don't make your users write go yourpackage.YourApiCall() in order to use the API correctly. That's just a guess, though.
- sagichmal 7y agoThe article says almost exactly the opposite, and I agree. Your API should present all of the things it does as synchronous functions/methods. If callers want to run them asynchronously, they can easily provide their own goroutine to do so, including whatever lifecycle management makes sense for them. The concrete example was // Do this func (t *type) Run(ctx context.Context) { ... } // Not this func (t *type) Start() { ... } func (t *type) Cancel() { ... } This is generally good advice which stops a whole class of extremely common and very tricky to debug orchestration bugs outright.