Boost.Beast VS RESTinio

There is at least one notable exception to this rule: https://github.com/boostorg/beast/issues/1445

I am using this example : https://github.com/boostorg/beast/blob/develop/example/websocket/client/async-ssl/websocket_client_async_ssl.cpp My application is listening to tick data streams of crypto exchanges over the websockets and processing and sending orders to the exchange.

We used beast to implement a market data server(and I think we also did a small client, to test it) which was sending protobuf messages, and it worked great(we also used boost adio, which made it very scalable). When we tested the server, we were generating around 100k messages per second(when there was the biggest activity on the market), I think I've posted here some stats: https://github.com/boostorg/beast/issues/2313.

Boost Beast?

And Chris wrote this example, which is faster than any of my other examples: https://github.com/boostorg/beast/tree/21cd552399aa8167ed53c21a74f3711c2c316d2f/example/http/server/fast

cmake -h. -Bbuild && cmake --build build

to work about 90% of the time. Far more luck than I've had with autotools.

> Its code is horrifying too, for example:

1) I'm sure I could find some horriffic code in meson too if I went digging. 2) The alternative to this is you having to write something equivalent in your own code, meaning that in my code I don't need to do stuff like [0] in my code to detect features; my build system handles it for me. 3) CMake supports more platforms and targets than I've ever seen in my life, and likely supports more compilers than are necessary. that's a blessing and a curse, but it means that if I write simple program to run on some crufty microcontroller with a bastardised gcc toolchain from the 90s, it's fairly likely that cmake supports it out of the box. Code like that is the price to pay for that level of support.

[0] https://github.com/boostorg/beast/blob/b7344b0d501f23f763a76...

If you need an embedded C++ HTTP server then there are plenty of libraries/frameworks (in random order): Crow, RESTinio, Boost.Beast, cpp-httplib, http_backend, Pistache, RestBed, served, proxygen, Simple-Web-Server, drogon, oat++.

In my past job, we used https://github.com/Stiffstream/restinio and absolutely loved it. It's not as active but it honestly didn't need much.

Here's a C++ REST framework for you to use too: https://github.com/Stiffstream/restinio

I had a good experience using restinio for a small ASIO HTTP server recently.

It uses restinio https://github.com/Stiffstream/restinio with great success ;)

For networking, pick a networking library. Restinio is a fair choice for HTTP. But, again, feel free to pick others.

You may find this worthwhile: https://github.com/Stiffstream/restinio/issues/101 FWIW, I used Restbed successfully for 3.5 years before switching personal projects to Restino. I've left the job that used Restbed, but I think they are still using it.

Contrary to the direction most people go, I've been writing REST APIs as C++ servers using two different fairly full featured C++ REST frameworks: first using https://github.com/Corvusoft/restbed and more lately using https://github.com/Stiffstream/restinio. These can be peers with any other server, while living on embedded and/or high compute devices for video encode/decode/analysis, deployed ML models, encryption for and remote process communications, model data collection and similar expensive or in-field processing. In both high compute and in-field-no-internet situations creating REST APIs in C++ enables speed and system controls not present in the majority of the mainstream REST frameworks. It's a big world, and here comes ubiquitous high compute...

If you need an embedded C++ HTTP server then there are plenty of libraries/frameworks (in random order): Crow, RESTinio, Boost.Beast, cpp-httplib, http_backend, Pistache, RestBed, served, proxygen, Simple-Web-Server, drogon, oat++.