asio-grpc VS Restbed

Since I can never remember what arguments to pass to protobuf_generate to create Protobuf and gRPC source files, I wrote an article about it. It provides a copy-paste-able code snippet along with an explanation of all arguments that protobuf_generate accepts, how to format it nicely using cmake-format and how to make things easier with asio-grpc.

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.

It hasn't been without issue, however. Problems that may lie in official google-maintained libraries are of course present and required design changes, and I was even prompted to write my own bitset library that outperforms the C++ standard's by a factor of 60. Madness. Right?

Or check out the asio-grpc repository directly if you are looking to write asynchronous gRPC services with the features of Boost.Asio like C++20 coroutines, std::futures, stackless coroutines, callbacks and Boost.Coroutines.

Use a rest api library like https://github.com/corvusoft/restbed. You can use a json library with this to serialize/deserialize your data into json objects.

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

There are some C++ API frameworks like Pistache or Restbed (full list here) to get started. If I should be 100% honest, I don't think C++ is worth for APIs as we have easier solutions with the same performance nowadays (like Go and Rust), but I think we should try everything, right?

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