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

Subject: Re: [boost] [http] Design ideas for a request router
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2016-03-14 18:42:32

2016-03-14 17:10 GMT-03:00 Artyom Beilis <artyom.beilis_at_[hidden]>:

> Take a look what I do in CppCMS with URL mapping.
>

I will. Thanks for the advice.

> I thought I could combine and allow both styles. Actually, Boost.Http
> don't
> > force you to use any style and both could be used.
>
> I suggest do ONE thing but do it well.
>

I'm not building a megazord application. There will be many of them and the
user will choose what it thinks it fits better.

It's not like other frameworks that create a megazord class that will be
its own executor containing its own thread pool being its own request
provider and request router and so on and so on.

> 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.

> Another approach would be to turn the handlers into template functors.
> > However, this would be too much burden on the user.
>
> Please don't... Think about end users and compilation times.
>

I don't like this approach either. I'm just mentioning it.

> 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).

>    - The router doesn't take the rule, only the handler. Later, I'll make
> >    algorithms that adapts rules and conditionally call your handler or
> pass
> >    the route to the next handler. This design is more flexible and I
> wish I
> >    could also use it in "tree style too".
>
> I don't understand but sounds like bad idea - when you build routing tables
> it should be clear what path is mapped to what if you separate it in the
> code
> it would be messy
>

It is more like:

static_router::make<message_t>()
    .append_handler(regex_rule("regex", handler1))
    .append_handler(authenticaed_rule(handler2))
    .append_handler(not_found_handler);

I mean, algorithm rules and handlers would be decoupled!!! You could add
rule algorithms as you go on.

------------------------------
>
> DISCLAIMER : I'm THE author of CppCMS [1] high performance C++ web
> framework
>

And I'm glad I caught your attention.

I may add that I'm a fan of the work done with the benchmarks of CppCMS:

   - http://cppcms.com/wikipp/en/page/benchmarks_php
   - http://cppcms.com/wikipp/en/page/benchmarks_all

I also remember seeing other nice things like "taking cache to its limits",
but it has been so much time since the last time I took a look.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/