Difference with async-local-storage

Can someone explain what is the difference between this library compared to https://github.com/vicanso/async-local-storage ? That library seems super simple.

I checked other solutions as we are having issues with destroying the namespace. Is destroying the namespace necessary on every request? Here is our middleware:

return async function(ctx, next) {
      const namespace = continuationLocalStorage.createNamespace('session');

      try{
        await new Promise(namespace.bind(function(resolve, reject) {
          namespace.set('request_id', ctx.request.header['x-request-id']);

          next().then(resolve).catch(reject);
        }));
      } catch(error) {
        throw error;
      } finally {
        continuationLocalStorage.destroyNamespace('session');
      }
    };

[Jeff-Lewis]

At first glance and without comparing in detail the async_hook event state management of async-local-storage, I assume for the latest node 8 versions, it and cls-hooked would behave the same.

One clear difference is cls-hooked provides backward compatibility with node 6 & 7 using AsyncWrap when running in those versions. It also provides the same interface as node-continuation-local-storage to make it easier for devs to try.

As for destroying namespaces, its not required but I guess it depends how you’re using it. I’m not sure what framework your middleware example is from, but usually namespaces are created sparingly, such as a “sessions” namespace, while contexts are created on that namespace for things like requests and sessions.

Btw, I love the simple and elegant code of async-local-storage… it makes me want to rewrite cls-hooked… when days start to have 36 hours in them…

[Jeff-Lewis]

@blacksonic Closing for now. Let me know if you have any issues.