Closed zoe-1 closed 7 years ago
Some initial feedback!
onPreStart
, onPostStop
, etc.) and "request extensions" (e.g. onRequest
, onPreHandler
, etc.), so we probably wouldn't want to overload the term "server" here. At the same time, I think we also need to be careful with "application." The implication is that an "application extension" would apply to every request on the entire server. But really these extensions are added to whatever connections are selected by your server
. To be explicit we might call these things "connection-level request extensions". Luckily server extensions don't have the same issue ;D👏 thank you for working on this!!
Sorry. did not realize github tracks all amended commit references to issue too.
@devinivy re-wrote the two documents to reflect the terms you recommended. Documents listed below.
In respect to the three levels of request lifecycle extensions, used:
https://github.com/hapijs/university/pull/254 This PR contains assignment9 written according to @devinivy recommendations in this issue.
Currently, writing a lesson for hapi university.
The lesson is about the request lifecycle, hooks, and events. We are changing an extension that was "application level extension" to be a "request level" extension.
There are three types of request lifecycle extensions:
When extensions apply to all requests received by the server should we call them "application level" or "server level". Matt Harrison used the term "request level extension" so I want to call them "server level extensions" or "application level extensions". However, I think "server level extensions" is to close to server extension points:
function(server, next)
.So, I am going to call them "application level extensions"
Is everyone ok with that?