Proposal for static analyzer and adding wrapper for asio.

[Assowavesss]

I was looking for a grpc library in c++ because the official one isn’t excellent and I found grpcxx via this blog https://u-a.medium.com/implementing-a-grpc-server-api-in-modern-c-devlog-2-3706ae91dbe6.

Maybe it was in the roadmap but I suggest it, adding clang-tidy, cppcheck and include what-you-use and to lint the project.

I also saw that you use libuv that is a very good library. I think adding a wrapper for asio would be and excellent choice, especially if the project is in c++20 with coroutines.

Finally, i looked the source code, I suggests you to move to header only library. You can do that because you are using many template and also, you are keeping small methods and to add grpcxx as library would be more easier.

I Hope my answer will help you and I am really excitting by this project 💪🏻💪🏻💪🏻.

[uatuko]

Hey @Assowavesss 👋, happy you've found this project and find it exciting! You've made some really good suggestions, thanks for that.

There's already a bit of linting with clang-format but definitely can be improved along with static checks.

When you mentioned asio, were you referring to https://github.com/chriskohlhoff/asio/? There's also https://github.com/netcan/asyncio which I came across when I started working on this project. Both of these async libs require to "wait" to read chunks of data and from my initial thinking I thought I'd end up having to create an event loop concept to handle requests anyway so preferred to use libuv. But it's definitely something to revisit when this project evolves.

Header only lib is a very interesting point. I've thought of it but debated whether grpcxx would be used as a purely header only lib, for example it's dependent on nghttp2 which isn't a header only lib itself. So it will require some sort of build system and at this point I feel the benefits of a header only lib disappears (i.e. it can't be just copy headers and ready to use). Do you have insights into how a header only lib would be more useful even with other compiled dependencies?

[Assowavesss]

I was referring to asio https://github.com/chriskohlhoff/asio or boost.asio https://github.com/boostorg/asio.
I'm not sure but I think you have to wait to read the Chunk only in asynchronous mode with asio. However asio is header only and has support for coroutines. I know that the project depends on nghttp2, however the goal is not in the future to make your own library to support http2 for better performance 😏. Even if you keep nghttp2 in the future, you can still make it header only, even if it increases the build time, you are not using techniques like Pimpl to separates definition from implementation(to hide the use of library) and therefore nghttp2 and libuv must be included as public target I guess. In addition, header only would considerably increase performance.

Maybe you can create a discord Channel for users of the library and we can discuss inside, keep in your mind that is just a proposal, maybe I am wrong.

[uatuko]

A discord channel is definitely a good shout and I'm keen to create one if there's more interest in the project 👍.

[RavikumarTulugu]

There is a new library which provides higher level coroutine abstractions similar to javascript. it is pretty interesting !! It would help , if the library is based on the primitives provided in boost cobalt. here is the link https://www.boost.org/doc/libs/1_84_0/libs/cobalt/doc/html/index.html
Also there is one more library which provides http2 using boost asio , i am sure you might have stumbled on this before.
https://github.com/nghttp2/nghttp2-asio
Lot of C++ ppl like me invested lot of time in boost C++. it would reduce learning time and ease adoption if you include boost in your library. Also , as assowavess mentioned, it would be great to design the library as a header only.

[uatuko]

@RavikumarTulugu good to see you again back here!

I'm looking into the header only option as well as other async I/O libs to consider but there's not much progress yet. I'll keep this issue updated on any progress I make.

[eladm-ultrawis]

@uatuko would like to second that making the library "asio compatible" would be great. Ideally, a user would be able to use the library by providing asio::io_context. The library could then be used with applications that already use asio for IO without creating extra threads, utilizing the existing event loop (io_context::run) for handling all completions.

Currently, we are using asio-grpc, which is nice, but it still uses the existing grpc implementation which is very limiting in terms of tight integration with existing event loops.

[uatuko]

Thanks for the feedback @eladm-ultrawis. I must admit, I overlooked the significance of Asio.

I'm happy to replace libuv with Asio but since there are two variants of Asio (boost and non-boost) it might make it a bit complicated to make it compatible with both. I'm doing some work to get a PoC up and running.

[uatuko]

Asio's Boost Software License might complicate things. Let's move the Asio conversation to #22.