-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(rest): introduce RequestContext #1316
Conversation
Few notes for reviewers: Let's work incrementally. This pull request is focused on changing everything Sequence related from @raymondfeng let me answer your concerns from #1292 (comment) here.
I agree. To address this problem, I am introducing two types:
I am worried about the performance impacts of running full context/binding resolution whenever we need to access the request or response object. For now, I am using a regular property and a locked binding to prevent people from overriding request/response bound in the context. Either way, the public API remains the same, therefore we can always easily change the implementation details if/when we have a use case requiring it. I am proposing to keep my current version for this initial pull request. |
I like the names |
@bajtos Please fix the code lint errors. |
Weird. @raymondfeng do you have any more feedback/review comments? |
c4b0f71
to
d1eb28e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a high level, this LGTM. Personally, I like the simplification of merging the IoC context and request/response into RequestContext
. I will do another round of review later for more thoughtful feedback.
The types defined in "internal-types.ts" are not internal at all, for example they include signatures of sequence actions. This commit renames the file to "types.ts", which is a file name already used in other packages (let's be consistent).
d1eb28e
to
e8f51e2
Compare
Rework all places where we were accepting a pair of `(ParsedRequest, ServerResponse)` to use an context object instead. Two context types are introduced: `HandlerContext` is an interface describing objects required to handle an incoming HTTP request. There are two properties for starter: - context.request - context.response Low-level entities like Sequence Actions should be using this interface to allow easy interoperability with potentially any HTTP framework and more importantly, to keep the code easy to test. `RequestContext` is a class extending our IoC `Context` and implementing `HandlerContext` interface. This object is used when invoking the sequence handler. By combining both IoC and HTTP contexts into a single object, there will be (hopefully) less confusion among LB4 users about what shape a "context" object has in different places. This is a breaking change affecting the following users: - Custom sequence classes - Custom sequence handlers registered via `app.handler` - Custom implementations of the built-in sequence action `Reject`
e8f51e2
to
c709571
Compare
Note: I haven't updated all documentation yet, I am waiting for the outcome of review discussion for the code and API design.
Rework all places where we were accepting a pair of
(ParsedRequest, ServerResponse)
to use an context object instead.Two context types are introduced:
HandlerContext
is an interface describing objects required to handle an incoming HTTP request. There are two properties for starter:Low-level entities like Sequence Actions should be using this interface to allow easy interoperability with potentially any HTTP framework and more importantly, to keep the code easy to test.
RequestContext
is a class extending our IoCContext
and implementingHandlerContext
interface. This object is used when invoking the sequence handler.By combining both IoC and HTTP contexts into a single object, there will be (hopefully) less confusion among LB4 users about what shape a "context" object has in different places.
This is a breaking change affecting the following users:
app.handler
Reject
This is a part of #1292, a follow up for #1082 which supersedes #1313.
Checklist
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated