Initial implementation #1

bajtos · 2016-07-28T13:46:53Z

Based on our discussions, I think we should remove getCurrentContext from LoopBack 3.0. In order to simplify upgrade path and allow community to take over maintenance of CLS-based current context, I want to follow the same process we did with loopback-boot and that is to extract the functionality into a standalone module that can be versioned independently.

In this patch, I moved most of the context-related code from LoopBack to a new repository.

What was not moved: ChainedContext and the code setting up strongRemoting.getCurrentContext and juggler.getCurrentContext. AFAICT, these two methods were not used anywhere in strong-remoting/juggler.

What's next:

in LoopBack 2.0, rework the implementation of context-related API to use this new module and print a deprecation warning - see Deprecate current-context API [2.x] loopback#2559
in LoopBack 3.0, remove all context-related API altogether - see [SEMVER-MAJOR] Remove current-context API loopback#2564
update loopback-workspace to disable context middleware in remoting options - see Disable current-context in new projects loopback-workspace#308
update documentation page

@raymondfeng @ritch please review
cc @strongloop/loopback-dev FYI

raymondfeng · 2016-07-28T15:32:32Z

Do we want to name the module as loopback-context? I'm seeing some hope in Node 6.x:

The current implementation of getCurrentContext() is NOT reliable due to flaws in othiym23/node-continuation-local-storage#59 and other issues. If the customer is open to latest version of Node (6.x), maybe we can try an enhanced module at https://github.com/Jeff-Lewis/cls-hooked which leverages Node async-wrap (https://github.com/nodejs/node-eps/blob/async-wrap-ep/XXX-asyncwrap-api.md).

seriousben · 2016-07-28T16:45:59Z

server/current-context.js

+
+'use strict';
+
+var cls = require('continuation-local-storage');


It would be nice if this require was only done when using CLS. As soon as this require is done, all the instrumentation/patching of async-listener is fired which is not ideal.

We've seen stack overflows due to promise instrumentation and other people have seen similar things othiym23/async-listener#57 which goes away when instrumentation is disabled.

I guess this could be done either in loopback or here.

I'll do the change here.

ritch · 2016-07-28T17:15:29Z

Do we want to name the module as loopback-context

yes

ritch · 2016-07-28T17:16:34Z

README.md

+2) Then you can access the context from your code:
+
+```js
+var ClsContext = require('loopback-context-cls');


Why ClsContext? To differentiate between a HTTPContext ?

I am going to rename this to LoopBackContext.

ritch · 2016-07-28T17:18:05Z

I like this idea! This will allow us to iterate at a faster pace on this module. Eg. opt into [email protected] support of CLS (or whatever that ends up being) without having to require 6.x for LoopBack.

As soon as CLS module is loaded, the instrumentation/patching of async-listener is fired. This may cause stack overflows due to promise instrumentation. By loading CLS module lazily (only when used for real), we avoid this kind of problems in applications that are not using current-context at all.

bajtos · 2016-07-29T07:37:18Z

Changes made:

renamed the module to loopback-context (867a7c3)
renamed ClsContext to LoopBackContext in the code (867a7c3)
implemented lazy-loading of CLS as suggested by @seriousben (1f214bf)

@raymondfeng @ritch @seriousben LGTY now?

raymondfeng · 2016-07-29T14:35:12Z

LGTM

@raymondfeng