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:
smacker({
stop: (callback) => server.close(callback),
});
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.
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
smackererror 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.startandservice.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.stopis not needed andservice.startis 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.