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

Question about using res.end() vs. returning response object #599

Closed
xia-stan opened this issue Mar 3, 2023 · 1 comment
Closed

Question about using res.end() vs. returning response object #599

xia-stan opened this issue Mar 3, 2023 · 1 comment
Labels
question Issue can be closed by providing information

Comments

@xia-stan
Copy link
Contributor

xia-stan commented Mar 3, 2023

In this comment on #497, @The-EDev states the following:

I can see a few issues with this implementation. For starters, if you're going to use a response it would be best to use ([](crow::response& res) { and res.end() rather than defining it later and then using return res.

I've seen some discussion around using res.end(), but nothing explicit around why this is preferred over returning a response object defined in the lambda. Could you provide some additional clarity around preferring res.end() over the returned object?

@The-EDev The-EDev added the question Issue can be closed by providing information label Jun 8, 2023
@The-EDev
Copy link
Member

The-EDev commented Jun 8, 2023

Hi, sorry for the late response. Ultimately the way Crow works is that res.end() triggers the data inside it to be sent to the client. when you return a response Crow is calling res.end() on it behind the scenes. The only reason to return a response is if you have some function that creates a response object. Otherwise it would save a few cpu cycles to just use the handler provided response object and call end() on that.

@The-EDev The-EDev closed this as completed Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Issue can be closed by providing information
Projects
None yet
Development

No branches or pull requests

2 participants