Vladislav

> The idea (at least in my head) was to use some form of coroutine to get back to where the function left off Sure, but that requires your end-user...

> Just to throw it in there: What about [std::promise](https://en.cppreference.com/w/cpp/thread/promise)? std::promise is just the sender side of a future. > One thread would be needed to check on the futures...

> Well, how about returning a specialized value like crow::response::async analogous to std::nullopt? That'll work. This ensures: A. Nobody makes a handler asynchronous by mistake B. Calls crow::finish on a...

The actual response logic is already contained in `res.end()`. Actually, you can make Crow asynchronous now, but very easily shoot youself in the foot. Like this, for example 😅 >...

@joelguittet Hi. There are! As for now, [Session middleware](https://crowcpp.org/master/guides/included-middleware/#sessions) is implemented as planned. It allows you to associate data with clients via cookies (securely). This way you can store whether...

@joelguittet Replace the constructor to be the following: (remove the secret key) ```c++ // Init the app crow::App app {Session{ crow::FileStore{"./sessions"} // make sure this folder exists!! }}; ``` I've...

> Feel free to close this issue right now if you want I'll close it then. You can open new issues if you notice something with the new sessions feature...

Such a module has to be carefully planned ahead. Many of them end up inflexible or difficuly to use (even in big frameworks). I'm still not sure to what extend...

Great 👍🏻 I'm in for Blueprints as well. I'm currently working on middleware for them to lay the basis for this feature.

Lets close this issue in favour of https://github.com/CrowCpp/Crow/issues/376#issuecomment-1213539833