BrilliantNetwork VS rotor

Hi all, I am looking for a code review of my repo here https://github.com/dvd0bvb/BrilliantNetwork. It is a header only library wrapping asio sockets in easy to use client and server classes using (asio's abstractions of) c++ coroutines for async operations. It currently only builds on Linux as asio::experimental::coroutine is broken on windows last I checked. The library can detect if you are using standalone or boost.asio and I've added http/s classes using boost.beast if available and enabled.

Here you go https://github.com/dvd0bvb/BrilliantNetwork

And here's a link to the full project if it's helpful https://github.com/dvd0bvb/BrilliantClientServer

If your architecture fits into inter-process messaging, i.e. spawn threads which do similar or different tasks and inform each other via messages, try to use actor framework, i.e. rotor (disclaimer: I'm the author). If there is a need to expand messaging even more, i.e. across the network, you can try to use caf, which provides that facility out of the box.

What you achieved, is handlers decoupling, i.e. when one handler knows nothing about other handler, which leads to good application testability. However, with standard promise/future bases messaging, if performance matters (and it usually does, otherwise why use C++?), i doubt that your implementation overwhelms the performance of specialized actor libraries, like sobjectizer ("batteries included" actors toolbox) or rotor (DIY-like actor constructor set; disclaimer: I'm the author of it).

I have been reading the documents from Boost.fibre and Boost.Signals2 which I could use, maybe ASIO for async. I also checked ZeroMQ (this seems to be more or less "only" for networking), Copper and Rotor. If this were just a simple MCU project I would just take the FreeRTOS and would have everything I need. Now I'm just lost how to structure my code / how to realize my main loop.

I would like to present my project rotor, which is event loop friendly C++ actor micro framework with Erlang-like microframework with supervising capabilities.

rotor actor library (I'm the author) was designed to solve similar problem, which I named "actor intrusiveness", when almost every piece of code should be written in form of actor, and, the working threads, which spin actors, are out of your control.

PS. I'm the author of rotor framework )

May be actor frameworks like caf, sobjectizer or rotor is something, that you are looking for.