concerned about performance. Therefore, many may not like the std::function<> approach. It can imply some hidden allocation that you
Knowing this is Boost and Boost is about serious C++ users I know I must be pay
even if the handler is not going to give up on the route.
Negligible - you should create routing + callbacks at the application start so it does not matter how much std::function allocates as long as you don't copy it on each request.
For now I'm discussing the "chained style" and in this style the "next" argument will be passed around and around (it IS being to be copied). It's not like something that would be done at application startup and not modified again.
Anyway, I implemented the "next" more like a search index than a type erased generic functor.
I suggest start from requirement i.e. what is needed - some samples and see how it works. To be honest copying callback isn't something that should be done - may be pass a reference/iterator to a next callback - but copy? Also remember that usually stuff that is being executed is rarely simple function but has lots of relations so... simple lambda isn't enough.
Other APIs use a passive style and constantly check if there is network
activity and schedule new socket reads. Boost.Asio is more explicit and Boost.Http follows along. An active style is useful because it'll allow you to defer new operations to later when your server is under heavy load. Anyway, I felt that maybe I'll need a "done" function and I've added an empty one for now. I'll see if I'll really need it later when I integrate everything together. For now, just know that the "done" function does nothing.
See... it is nice to have defer functionality for stuff like server-sent-events or another hip called web sockets.
But vast majority of web api/web work need to do stuff synchronously...
In no way I'm gonna remove flexibility. It's easier for you to see me implementing two interfaces (a "lower-level" and a "higher-level") than you seeing me making the API less useful (i.e. usable in less situations).
I don't tell remove flexibility (for the record CppCMS has both synchronous applications that run in a thread pool and asynchronous that live in event loop for defer style of operations) But I'd suggest don't take it to extreme as node.js does - remember C++ isn't JavaScript and nested handlers JS style with lambdas isn't such a good idea Artyom