Re: [boost] [Beast] Questions Before Review

Subject: Re: [boost] [Beast] Questions Before Review
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-06-25 21:32:57

On Sun, Jun 25, 2017 at 2:02 PM, Artyom Beilis via Boost
<boost_at_[hidden]> wrote:
> It may seems like it can be in some competition with
> Beast but I don't see it this way as Beast is too low level library that
> does not addresses typical problems of developers needing Web API/Site
> running using C++.

Beast is not a competitor to CppCMS, as the former is a simple
protocol layering on top of Asio while the latter is a Web Development
Framework. Beast does not intend to be a web framework now or ever.

> I understand that you work on base of Boost.Asio - which itself has
> unacceptable compilation times but having for web
> application development may be serious deal breaker for big projects.

I'll note that the very first complaint during the Boost.Http review
(2015) was that the library is not header-only. If Asio compilation
times are unacceptable then you will find Beast compilation times
unacceptable as well, since Beast is very much tied to Boost.Asio as a
base layer.

> I see that almost every object there is some kind of template object.
>
> It almost mimics the API of Boost.Asio which on its way has its limitations.

Very astute of you to notice! In fact, an overarching design goal of
Beast is "emulate Asio in all possible ways." If you feel that
Boost.Asio has limitations, you find similar or identical limitations
in Beast. Conversely, those who feel that Boost.Asio has tremendous
flexibility and expressive power, will also find similar in Beast. I
find myself in the latter camp, but your mileage may vary.

> I have strong feeling that lots of stuff can actually be done using classic OOP.

There is no question that it would be possible to create non-template
classes for every conceivable choice of template parameters but I'm
not sure that's a productive use of time and while it might satisfy
most users to have explicit instantiations for
boost::asio::ip::tcp::socket and
boost::asio::ssl::stream<boost::asio::ip::tcp::socket> it is certain
to leave at least a few people in the lurch. For example, "that guy"
who wants to write an AsyncStream wrapper for his libuv socket so it
can work with Beast.

>> Can I implement same server code for both SSL and non SSL HTTP protocol
>> without use of templates in the class itself?

If you can do it with Asio then you can do it with Beast. Typically
this is done with type erasure for the main template parameters which
are 1. the stream object, 2. the buffer sequence, and 3. the
completion handler. You can do the same with Beast, except that you
will also need to make a commitment to one type for requests and one
type for responses. This makes some of Beast's cool template driven
features not work but it seems like you're okay with that tradeoff.

> Who are the potential users of the library?

Beast is primarily aimed at library writers, although it frequently
satisfies high level application developers even with its verbose
interfaces since the alternatives are objectively worse.

> If I need to send a simple http request to server it does not seem
> to do simple enough job (see your FAQ) so I'll probably be better
> with feature rich libcurl.

Beast is definitely not a replacement for libcurl, and likely will
never be. Libcurl is a full featured HTTP client, while Beast is
merely an HTTP protocol layering on top of TCP/IP using Boost.Asio's
asynchronous model.

However, someone eventually is going to make a better libcurl by
writing it on top of Beast, and then we'll see some nice things like
C++ native interfaces, with lambdas, type safety, perhaps template
arugments defining HTTP client specific concepts such as
BasicAuthenticator or MultiPartConsumer (I made those up but the names
allude to their usage). Most importantly, someone who writes a C++
libcurl on top of Beast will be able to present complete, type-safe,
fully-intact message objects to the caller when asked, and then that
message object can be passed to other libraries or algorithms built
with Beast.

There's a network effect when you have a good set of vocabulary types
and algorithms, and Beast aims to provide that for HTTP (and
WebSocket!). Just like how the standard library gives us a common
voice with which to explain solutions to general computer science
problems, Beast provides the pieces for building solutions to HTTP and
networking problems. My goal is to guide Beast through Boost
acceptance, widespread adoption, and then a proposal for the C++
Standard Library.

> If I need to implement complex web server/service I don't have
> cookies, sessions, forms, html?
> ...
> If I need to implement RESTful API do I have all stuff like URL mapping of
> different paths to callbacks, protocol abstraction http/https
> (basic stuff - I don't see it there correct me if I wrong)

Everything you described is out of scope for Beast. I'm hopeful that
the existence of Beast will inspire programmers to create new higher
level libraries to solve the problems you listed in a composable and
interoperable way.

> Is it for web server developers?

You can build a web server with Beast. But as you pointed out, you
will have to either write for yourself or find in other libraries some
important pieces like a URI parser, cookies, authentication, codecs
for the various Content-Encoding, a multi-part/mime library, and so on
and so forth.

Obviously we would all be happy if these things existed already with
perfect C++ friendly interfaces and with composability and
interoperability in mind but they don't. Beast is the first down
payment on that dream.

> Maybe I'd be happier with simple
> HTTP protocol parser that I can integrate to any socket API?

And you can do that with Beast, the beast::http::basic_parser is
designed for users to derive from if they want to take advantage of
the parser implementation. You can derive your own parser and feed the
buffers from wherever you want. Or if you like Beast's message model
(I happen to think its rather well designed but that's just my
opinion) you can use the beast::http::parser by feeding in buffers to
produce messages which you can do whatever you want with. This is
covered in the documentation, with examples:
http://vinniefalco.github.io/beast/beast/using_http/buffer_oriented_parsing.html

If you want to serialize HTTP messages to buffers without using Asio
and sockets you can do that too, using beast::http::serializer, also
covered in the documentation, with examples:
http://vinniefalco.github.io/beast/beast/using_http/buffer_oriented_serializing.html

> Can you please give more accurate description of who is this
> library intended for?

Its a fair question although I thought the Introduction in the
documentation gave a pretty good idea. Its sort of a hard question to
answer because really we have never seen a library like this before
which is so low level so I think people just don't know what to think
of it especially when they start comparing it to other libraries or
applications whose descriptions include the word "HTTP"

The library is intended for anyone who wants to build something
resembling a high level library that exists today, such as Boost.Http,
cpprestsdk, cppnetlib, CppCMS, or any of those libraries which
implement either an HTTP client or an HTTP server. Instead of
reinventing the HTTP protocol code from scratch Beast gives you a
running start. It takes care of all the boring details of reading and
writing HTTP messages so that you can write your library at a higher
level.

Any library that is refactored to use Beast will immediately see
benefits. It will result in less code in the target library. That
library's interfaces will become more composable. You can take message
objects produced by one library written with Beast and pass them into
algorithms which take message objects that reside in other libraries
written with Beast.

So to answer your question, Beast is aimed at anyone who is writing
software that wants to speak the HTTP (or WebSocket!) protocols using
Boost.Asio and eventually the Networking-TS
(http://cplusplus.github.io/networking-ts/draft.pdf), which is a
polished version of Boost.Asio that will certainly become part of the
C++ standard library.

I will conclude by saying that eventually, only networking libraries
which are coded against Boost.Asio, the Networking-TS, or ultimately
the C++ Standard Library version on or after which the Networking-TS
has been integrated, can possibly be taken seriously. After all, who
would want to use a library that doesn't use the "standard"
implementation of networking?