RFC/1684 Context objects

[ahopkins]

Resolves #1684

The proposal is to add a request.ctx like API to Sanic applications, blueprints, and connection objects.

A common practice is to add arbitrary objects on the Sanic app instance. This introduces a __fake_slots__ that is meant to be replaced by a real __slots__ in the future. In the meantime, we will check and raise a warning to direct the developer to using app.ctx.

---

Perhaps the more exciting introduction is request.connection.ctx.

This object will remain alive so long as a single transport is kept open. Since the KEEP_ALIVE will not close a transport layer, we can leverage that to place a context object on it.

A practical benefit of this might be only needing to check authentication or perform some expensive operation once for several calls.

[codecov]

Codecov Report

Merging #2063 (208e2d4) into master (01f238d) will increase coverage by 0.018%.
The diff coverage is 97.872%.

@@              Coverage Diff              @@
##            master     #2063       +/-   ##
=============================================
+ Coverage   92.199%   92.217%   +0.018%     
=============================================
  Files           38        38               
  Lines         3461      3482       +21     
  Branches       581       583        +2     
=============================================
+ Hits          3191      3211       +20     
  Misses         184       184               
- Partials        86        87        +1     

Impacted Files	Coverage Δ
sanic/request.py	97.627% <83.333%> (-0.297%)	⬇️
sanic/app.py	92.276% <100.000%> (+0.047%)	⬆️
sanic/base.py	100.000% <100.000%> (ø)
sanic/blueprints.py	100.000% <100.000%> (ø)
sanic/server.py	88.021% <100.000%> (+0.063%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 01f238d...208e2d4. Read the comment docs.

[vltr]

Perhaps the more exciting introduction is request.connection.ctx.

This object will remain alive so long as a single transport is kept open. Since the KEEP_ALIVE will not close a transport layer, we can leverage that to place a context object on it.

A practical benefit of this might be only needing to check authentication or perform some expensive operation once for several calls.

This is awesome! More interestingly would be, in some cases (I can see myself doing that at least), making request.ctx to actually be request.connection.ctx ... I don't know if by some future option or even a custom implementation where needed. Either way, this is awesome.

[vltr]

I made some comments to some parts, nothing too fancy neither blocking, so I'll leave them there in case you want but approve the PR already, as this seems awesome 😎

[ahopkins]

The PR is ready, and we could potentially squeeze it in. My only concern is if there are any edge cases we are not considering where keep alive would apply, but that connection object is recreated. 🤔 Maybe we merge as "beta" feature and finalize it in 21.6?

[vltr]

awesome 😎