Skip to content
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

Requests and responses should be stateless #12

Open
mstade opened this issue Sep 24, 2015 · 0 comments
Open

Requests and responses should be stateless #12

mstade opened this issue Sep 24, 2015 · 0 comments

Comments

@mstade
Copy link
Member

mstade commented Sep 24, 2015

Currently, when making a request or sending a response, the objects that represent them are just plain old javascript objects so any function that are given a reference to them will be able to modify their state. This can lead to subtle and difficult to catch foot/gun situations, such as rouge middleware modifying a request object after having called next, thereby bypassing the contract of middleware executing in a particular order. Another example might be a response handler mutating the body of a response long after the response has been sent.

To fix this, request and response objects should be immutable, in the sense that any change to them yields a new object with the changes. This will surely have some impact on memory, but can be made to be efficient. Crucially, it would be worth looking into using something like immutable-js or other space efficient immutable data structures.

More over, using such data structures will enable some improved debugging capabilities (see: #6,) such as inspecting request/response changes along the chain of events.

Immutable data structures alone are not enough however; indeed any value that can be set to such a structure must be immutable. Thus, a response body couldn't be a function, which by definition closes over its environment and therefor will have the ability to mutate state when and where it shouldn't. Somehow, requests and responses should be serialized in a way that such things aren't possible. Less rope to hang oneself with is always a good thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant