You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Been thinking a bit about this library, and have some questions.
Have you ever used smacker.stop() in a real project?
I can't think of when I'd want to programatically invoke a process stop and would not just do e.g. process.exit(1)? It seems that the purpose of smacker is handling signals and other unregulated behavior in a nice way, but stopping the process strikes me as out of scope.
Could service.start() be made optional?
What if a service is already "started"? It seems like needless boilerplate to have to provide an empty start method just so things don't break. In some projects, starting will be minimal --- and honestly, in others, the default smacker error handling is fine if something is critically wrong in very first startup...
Could we add support for both a Promise-based and callback-based interface for service.start and service.stop?
This would provide better support for the many legacy systems that do still use callbacks and would have to be promisified.
Given these two observations (if smacker.stop is not needed and service.start is optional, and callback based functions are supported), would you consider an interface like this: smacker(service) where service might just have a stop funtion:
Been thinking a bit about this library, and have some questions.
Have you ever used
smacker.stop()
in a real project?I can't think of when I'd want to programatically invoke a process stop and would not just do e.g.
process.exit(1)
? It seems that the purpose of smacker is handling signals and other unregulated behavior in a nice way, but stopping the process strikes me as out of scope.Could
service.start()
be made optional?What if a service is already "started"? It seems like needless boilerplate to have to provide an empty start method just so things don't break. In some projects, starting will be minimal --- and honestly, in others, the default
smacker
error handling is fine if something is critically wrong in very first startup...Could we add support for both a Promise-based and callback-based interface for
service.start
andservice.stop
?This would provide better support for the many legacy systems that do still use callbacks and would have to be promisified.
Given these two observations (if
smacker.stop
is not needed andservice.start
is optional, and callback based functions are supported), would you consider an interface like this:smacker(service)
where service might just have a stop funtion:I for one think that's a pretty neat minimal interface for e.g. express or fastify apps, if there is nothing else to wind down.
The text was updated successfully, but these errors were encountered: