drogon VS libunifex

You also have https://github.com/an-tao/drogon

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

You can use Drogon, which is currently the fastets framework in the TechEmpower benchmark.

FYI: I posted to the top contenders GitHub issues - https://github.com/an-tao/drogon/issues/760 - https://github.com/matt-42/lithium/issues/63 - https://github.com/rbock/sqlpp11/issues/361 - https://github.com/oatpp/oatpp/issues/401

For example, Drogon is said to be the fastest http server: https://github.com/an-tao/drogon.

I like this one Drogon.

I'm curious what led you to this conclusion. If you ran into scalability issues with its static_thread_pool, then that's a known issue. If it's something else, the authors (of which I'm one) would love to know.

Instead of calling add_executable you will call add_library. Here is a (only moderately complicated) production example of a library that can be built standalone (along with tests and example executables), or as a subproject, where it builds only the library

My original thought was to build my DDS implementation on top of libunifex in anticipation for standardization: https://github.com/facebookexperimental/libunifex

I'm trying to understand how to work with the proposed executors in a project, but after watching Eric Niebler's cppcon talks (https://youtu.be/xLboNIf7BTg) and looking at the libunifex examples (https://github.com/facebookexperimental/libunifex/tree/main/examples) I still have a hard time wrapping my head around how to employ the sender/receiver pattern in a larger project.

You have coroutines in C++20 but there is also the executives proposal that's making it's way into C++23 that is available as a library under the name unifex that only requires C++14

Asio-grpc makes exactly that possible by providing an Asio execution_context compatible interface to the CompletionQueue. It supports all types of RPCs (including generic ones), completion tokens, cancellation, as well as libunifex sender/receiver (if you want to try out what might become std::execution). The latest release (v1.7.0) also introduced a GrpcStream class for writing Rust/Golang select-style code.

P2300: they are trying to standardize facebookexperimental/libunifex

All the network handling for Instagram and all other Meta apps on all platforms is handled by their own C++ library https://github.com/facebookexperimental/libunifex.

This. I'd also like to mention libunifex. It's entirely based on tag_invoke and is a testament as to how much power it actually provides. On the other hand, it also proves how cumbersome it is to define CPOs with tag_invoke. But IMO it's a lot better than anything else anyone has ever created, and users usually don't need to define new CPOs, only library writers do, so there's that.

A work in progress implementation of the library: https://github.com/facebookexperimental/libunifex