Re: [boost] [http] Design ideas for a request router

Subject: Re: [boost] [http] Design ideas for a request router
From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2016-03-15 07:04:00

>> Knowing this is Boost and Boost is about serious C++ users I know I must
>> be
>> > concerned about performance. Therefore, many may not like the
>> > std::function<> approach. It can imply some hidden allocation that you
>> 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