remove domains? about kraken-js

[aheckmann]

Here is the NodeJS domains post-mortem. After reading, I'm in favor of sacrificing the rare debugging assistance domains provide and removing them from kraken.

[aheckmann]

Hapi has removed domains too: hapijs/hapi#3573

[aheckmann]

NodeJS discussion of using async_hooks and documentation / best practices plans. It's still the early days for a full replacement.

[shaunwarman]

Right, core seems to be in the move to async_hooks, but it doesn't seem like there is a concrete direction, especially with async_hooks still in experimental phase.

[aheckmann]

Correct, a solid alternative is not there yet. However, domains don't even work properly as is. The more I research them and the related problems they are giving the app I'm analyzing, the more I never ever want to use them anywhere again. If I were starting a new NodeJS project, I would not use Kraken because it, by default, enables the use of the broken domain design. Nor can I confidently recommend using Kraken to anyone for the same reason. The kraken docs don't warn about their use AFAIK. I therefore don't trust the project.

With alternative solutions available which support async/await style + try/catch error handling models, it's a no brainier for me.

[aheckmann]

Restify deprecated functionality utilizing domains.

[shaunwarman]

Ya, I wouldn't mind a deprecation warning now and a major bump for 3 with removal and some thought out upgrades.

Also, does it even make sense to sprinkle upgrades within the current setup or to move the underlying framework from express to something like koa? Which brings a lot of work in another direction to get the error handling benefits and a potential solution.

I mainly bring this up as there does seem to be a window right now where error handling is a problem with no concrete solution in current setup with domain deprecation and async hooks in an experimental stage.

[aheckmann]

Deprecation sounds good to me too. The best path forward IMO is using an async/await + promises + try/catch approach because it's easy to reason about. A few years ago we built all our services at another company using koa with that model and were very pleased. There is a small curve for people coming from express but the team adjusted quickly. I'm not saying koa is better than anything else (there are probably other good/better frameworks around now too), I'm saying the error handling and middleware model is easy to reason about. In JS, error handling is likely to remain a bit of a mess forever but try/await/catch makes for improved comprehension. I probably won't have more feedback on that bigger topic of swapping cores out until sometime in January.

…

On Thu, Dec 14, 2017, 3:32 PM Shaun Warman ***@***.***> wrote: Ya, I wouldn't mind a deprecation warning now and a major bump for 3 with removal and some thought out upgrades. Also, does it even make sense to sprinkle upgrades within the current setup or to move the underlying framework from express to something like koa <http://koajs.com/>? Which brings a lot of work in another direction to get the error handling benefits and a potential solution. I mainly bring this up as there does seem to be a window right now where error handling is a problem with no concrete solution in current setup with domain deprecation and async hooks in an experimental stage. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKLstofjUFaZxHUrw_oNp-qX6XIADfrks5tAbACgaJpZM4Q221U> .

[tlivings]

Given that deprecation warning was merged, assuming this is safe to close.

[aheckmann]

I'd prefer to leave it open until we remove domains.

[tlivings]

I don’t think domains deal with a “rare” use case. Until they are replaced with something of equivalent functionality, or express wraps the entire request chain in a promise, there will be a need for this.

[aheckmann]

wraps the entire request chain in a promise

Async/Await. These days, enterprise quality frameworks should be built on async/await. I think we need a new version a Kraken, maybe rewritten on top of Koa.

…

On Tue, Feb 27, 2018, 5:37 AM Trevor Livingston ***@***.***> wrote: I don’t think domains deal with a “rare” use case. Until they are replaced with something of equivalent functionality, or express wraps the entire request chain in a promise, there will be a need for this. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKLsv20v5p75dVmqi3aP2LS-sLxVtSHks5tZAUQgaJpZM4Q221U> .

[tlivings]

I’d be surprised if express didn’t have some plan for async/await support. Hapi 17 went this direction and it seems natural for this to be the next evolution of express.

[aheckmann]

Express authors went that direction years ago with Koa. But yeah, if express wants to survive IMO, it needs a major breaking change. May as well use Koa now.

…

On Thu, Mar 8, 2018, 6:24 AM Trevor Livingston ***@***.***> wrote: I’d be surprised if express didn’t have some plan for async/await support. Hapi 17 went this direction and it seems natural for this to be the next evolution of express. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKLsu1KHS6ASJf0qONxgNrUfGddSsY8ks5tcT8PgaJpZM4Q221U> .

[tlivings]

Koa is a different framework TJ Holowaychuk build that would not be compatible with kraken without a major rewrite.

Express is still maintained and being developed.

[aheckmann]

That's what I've been trying to say. Async await changes things for the better.

…

On Thu, Mar 8, 2018 at 5:02 PM Trevor Livingston ***@***.***> wrote: Koa is a different framework TJ Holowaychuk build that would not be compatible with kraken without a major rewrite. Express is still maintained and being developed. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKLst0Gd-Q9Og1mmTq44hFKWGOk2TQVks5tcdSNgaJpZM4Q221U> .