Telegram-канал r_cpp - C++ - Reddit: Unsorted - каталог телеграмм

C++ - Reddit

30 June 2026 22:23

Vix.cpp vs. Drogon/Crow: Is a "Node.js-like" workflow the future for modern C++ backend development? Looking for expert feedback!

Hi everyone,

I’ve been deeply exploring modern C++ (C++20/23) for backend architecture, looking at how we can make high-performance systems more accessible to developers coming from ecosystems like Node.js, Go, or Rust without losing raw native performance or explicit control.

We all know the established giants: Drogon is incredibly fast and feature-rich (but relies heavily on its own CMake setups, complex configuration files, and drogon_ctl), and Crow is fantastic for small, microservice-like Express-style APIs, but can feel limited when scaling full production runtimes.

Recently, I’ve been looking into Vix.cpp, and I feel it approaches the problem from a completely different angle that benefits both beginners and modern backend design. I’d love to get the community's expert thoughts on its architecture and ergonomics.

Why Vix.cpp caught my attention (especially compared to Drogon/Crow):

It’s a Runtime, not just an HTTP Library: While Crow and Drogon focus heavily on routing and HTTP, Vix.cpp acts more like a native application runtime (akin to a native alternative to Node/Bun, but without a GC or engine overhead). It bundles out-of-the-box non-blocking asynchronous modules (async, fs, crypto, db, p2p_http, webrpc) designed to work together coherently.

The Developer Workflow (UX/DX): For beginners or developers migrating to C++, managing CMakeLists.txt pipelines, linking dependencies, and configuring build environments is usually a massive friction point. Vix provides a unified CLI toolchain:

Bash

vix new api vix install vix run main.cpp vix build vix tests

It doesn't replace CMake underneath (you can keep your custom setups), but it abstracts the lifecycle smoothly.

Ergonomic Middleware and State Management: Unlike older frameworks where middleware composition can accidentally introduce blocking calls or obscure types, Vix utilizes a modern context-based layout (MiddlewareFn) with safe, explicit type-based request storage (similar to std::any via state injections).

The Trade-offs & Questions for the Experts:

As much as I like the ergonomics and the data-oriented feel of Vix, I want to spark an honest discussion:

Performance at Scale: Drogon is consistently at the top of TechEmpower benchmarks. Vix uses a modern Asio-based async core and boasts great local release metrics, but how does its runtime abstraction handle raw throughput under extreme hardware utilization compared to Drogon’s thread-pool model?

Ecosystem Isolation: Does building an integrated module ecosystem (vix::db, vix::net, vix::json) run the risk of alienating developers who prefer to manually stitch together standalone libraries (like nlohmann/json or fmt) via vcpkg/Conan?

Is this the right path for beginners? Do you think providing an "all-in-one" workflow layer lowers the barrier to entry for C++ backend engineering, or does it abstract too much of the underlying native toolchain mechanics?

I’d highly appreciate it if the veterans here could take a look at the architecture, tell me where this approach might fall short, or share your experiences if you've integrated Vix into your production stack.

https://redd.it/1ujzlmn
@r_cpp