Drogon 2.0

[rbugajewski]

This is the place for general discussion regarding the development of Drogon 2.0. The upcoming version will introduce breaking changes, but there’s also the opportunity to improve on existing APIs.

Until development of version 2.0 reaches a more mature state, all feature requests and discussions should be part of this issue.

[marty1885]

Just want to share some frustrations I have.

• Please switch to a faster JSON library (nlohmann/json, rapidJSON, etc..) JsonCpp in kinda slow. I often wrap around Drogon's methods for performance.
  • nlohmann/json is 4x faster and rapidJSON is 40x
  • Both tries to be type safe. But raiidjson doesn't do graceful handling
• Use string or string_view for content type. And allow user defined ones. Submitting a PR just to add a new file is unnecessary.
• Exceptions can escape the event loop (#600) then crash the entire app. And we might have to deal with exceptions when introducing coroutines anyway.

And my wish-list:

• C++ modules support
• Switch to Botan to make cryptography easier
• Switch to a response object instead of using callbacks. This should make HTTP/2 easier to implement. And more intuitive

I'm looking into getting HTTP/2 and coroutines support. But not sure if I can make it happen (coro shouldn't be an issue). I'll try to contribute as much as I can.

Thanks.

[sardar01]

nlohmann/json definately. Query- cannot brotli complelely replace zlib?

[marty1885]

@sardar01 Brotli doesn't work under all conditions. Ex: most browsers won't accept brotli over plan HTTP. And gz is good fallback for old browsers.

[seiichi-yoshimune]

On a side note according to 'caniuse' : brotli has as this writing 94.34% of Global coverage. tls1.2 has as this writing 98.24% of Global coverage. tls1.3 has as this writing 90.98% of Global coverage.

ideally you'd want to serve modern client with static brotli with a tls1.3 0RTT resumable session, and as fallback for older clients use static/dynamic gzip with at minimum tls1.2

but this depends mostly on your desired level of security / performace and if for you that small % of old clients is your main target audience or your so big that even a small percentage means loads of clients...

[ivanka2012]

A good testing framework and suite would be great. If you want to catch the big fish, you might as well advertise it as safe and reliable too. About @marty1885's answer

Switch to Botan to make cryptography easier

Why not use Crypto++? It's a much more popular choice when it comes to C++ crypto

[mkrupcale]

I don't know exactly what drogon needs in a JSON library, but if switching default JSON libraries and performance is a primary concern, simdjson[1] is probably the best.

Another interesting thing to explore performance wise is using io_uring rather than epoll on Linux[2-4].

As far as crypto libraries go, I don't really see much reason to switch from OpenSSL. It is likely one of the most tested and proven crypto libraries in the world, and I'm not sure the drogon user needs to be concerned with the crypto API anyways (it looks to be used only in trantor/trantor/net/inner/TcpConnectionImpl.cc as an implementation detail). So you might as well pick the fastest and most secure/tested crypto library.

[1] https://github.com/simdjson/simdjson [2] https://unixism.net/2020/04/io-uring-by-example-part-3-a-web-server-with-io-uring/ [3] https://ndportmann.com/io_uring-preview-release/ [4] https://github.com/frevib/io_uring-echo-server/blob/io-uring-feat-fast-poll/benchmarks/benchmarks.md

[danwt]

Another interesting thing to explore performance wise is using io_uring rather than epoll on Linux[2-4].

Would a change to uring be made in Trantor rather than Drogon?

[mkrupcale]

Would a change to uring be made in Trantor rather than Drogon?

Yes, I believe so, although I don't know all the technical details of the relationship between them to say it's exclusively a change in trantor.

[rbugajewski]

We should also discuss about API changes before the first public release of the next major version, because we will be able to introduce API-breaking changes. I created a placeholder ticket for now.

[rajhlinux]

Add real security, I have plans to use dragon for it's speed for a start up company but it doesn't have good security.

Would be nice if "Baton" can be added since it is the best Cipher Suite library in C++ and Dragon will benefit from this. This will be perfect for the Dragon project and almost any enterprise can use it if they are determined enough.

Thanks.

[rbugajewski]

We won’t add our own security implementation as we don’t have the possibility of audits, but better integration of a third-party dependency is a good idea, thanks.

[rajhlinux]

We won’t add our own security implementation as we don’t have the possibility of audits, but better integration of a third-party dependency is a good idea, thanks.

That is what I really intended to say, you are right that it doesn't make sense to actually implement security from scratch.

Dragon is really interesting, I see it's future as an enterprise ready web server. It's benchmarks is always on the top.

[justghostof]

请问是否可以在app().run();时就创建controller对象而不是在收到第一个请求时,这样方便将初始化代码直接放在控制器类的构造函数中

[an-tao]

请问是否可以在app().run();时就创建controller对象而不是在收到第一个请求时,这样方便将初始化代码直接放在控制器类的构造函数中

@mwx2006 , the PR #888 is for this requirement, please check it. thanks. @marty1885 should we add a option to enable this feature? or just create all controllers in beginning?

[marty1885]

For others, translation: Could we have very controller spawn upon app.run()instead upon first request.

Are there down sides of eagerly creating controllers instead of lazily? If you can, add a test to make sure controllers won't get added automatically if auto registering is disabled.

[rbugajewski]

I’m for creating all controllers in the beginning, and adding a lazy controllers option to get back the previous behavior if desired.

[rbugajewski]

Are there down sides of eagerly creating controllers instead of lazily?

1. Startup times are longer
2. Memory footprint is slightly larger

I can’t think of any other downsides, and I think these are perfectly fine compromises for server-side applications.

[omar-mohamed-khallaf]

Should hiredis be replaced with redis-plus-plus?

[kassane]

@an-tao , Drogon v2 will add asio's support only the boost libraries version or also support the standalone version?

[an-tao]

@an-tao , Drogon v2 will add asio's support only the boost libraries version or also support the standalone version?

It uses the standalone version as the networking library.

[papel]

I think it should escape HTML from parameters (#1793).

[AmdRyZen]

2.0 名字也建议换成 2024 官方的 Loong drogon 之前的翻译有问题 类似于会飞的蜥蜴

[an-tao]

2.0 名字也建议换成 2024 官方的 Loong drogon 之前的翻译有问题 类似于会飞的蜥蜴

谢谢你的建议，不过Drogon是角色名字不是物种名字（dragon），请参考readme的说明。