Vix.cpp v2.0.0

Vix.cpp v2.0.0 marks the beginning of the V2 series. This release is not a cosmetic version bump. It is the architectural reset that moves Vix away from the limitations of the V1 runtime and establishes a cleaner foundation for the future of the project. The most important change is the removal of the old Boost.Beast-based HTTP layer and the introduction of a native vix::http stack built around the Vix async execution model.

Why V2 was necessary

Vix.cpp V1 was originally built around Boost.Beast. At the beginning, that was useful because Beast provided a mature HTTP foundation. It made it possible to move fast and build the first version of the runtime. But as Vix grew, the architecture started to expose a serious problem: the runtime was becoming too dependent on Beast’s internal model. HTTP headers, sessions, request handling, middleware, WebSocket integration, and even parts of the application lifecycle started to feel like they were shaped by Beast instead of by Vix. That made the project harder to control. Vix was supposed to become a native C++ runtime with its own execution model, its own developer experience, and its own module boundaries. But with Beast deeply present across the codebase, Vix was slowly becoming a Beast-based application instead of an independent runtime. This created several issues:

  • the HTTP layer was difficult to control deeply
  • Boost headers leaked too far into the architecture
  • installation and packaging became harder
  • module boundaries were less clean
  • WebSocket and middleware behavior depended too much on the old HTTP layer
  • runtime shutdown was harder to reason about
  • cross-platform builds were more fragile
  • future runtime features were blocked by external architectural constraints

Vix.cpp v2.0.0 exists because those problems could not be solved cleanly with small patches. The runtime needed a new foundation.

Release focus

The main focus of Vix.cpp v2.0.0 is architectural independence. The old Boost.Beast-based HTTP layer has been removed and replaced with a native vix::http stack. This gives Vix direct ownership over request parsing, response handling, listener behavior, routing integration, middleware flow, shutdown logic, and runtime execution. This change matters because Vix can now evolve around its own architecture instead of adapting every internal decision to Beast. The goal is not only to remove Boost.Beast as a dependency. The goal is to make HTTP, WebSocket, middleware, and application runtime behavior share one coherent foundation.

From Beast-driven to Vix-driven

In V1, too many parts of the runtime were coupled to the Beast model. That made the code harder to extend because changes in the HTTP layer could affect unrelated systems. Middleware, WebSocket, and server lifecycle behavior had to follow the old transport assumptions. This reduced flexibility and made it harder to design Vix as a general runtime. Vix.cpp v2.0.0 changes that direction. The runtime is now Vix-driven. The HTTP stack is native. The async model is central. The runtime executor owns the execution flow. Modules can integrate through Vix abstractions instead of depending on Beast-specific details. This is the real reason V2 matters. It gives Vix control over its own future.

Native HTTP stack

Vix.cpp v2.0.0 introduces the native vix::http stack. This new stack replaces the old Boost.Beast-based implementation and becomes the foundation for HTTP server behavior in Vix. The native stack makes the runtime easier to reason about because the core HTTP flow is now designed for Vix directly. Listener startup, accept loop behavior, request handling, response generation, and shutdown can now follow the same internal model as the rest of the runtime. This is especially important for future work around performance, diagnostics, middleware, WebSocket behavior, documentation generation, and runtime tooling. A runtime cannot stay clean if its most central layer is controlled by an external abstraction that leaks everywhere.

Async-first runtime architecture

Vix.cpp v2.0.0 moves the runtime toward an async-first model. The listener lifecycle is more deterministic, the accept loop shutdown is cleaner, and runtime execution is safer during application shutdown. This release also improves shutdown behavior around App::close, worker cleanup, normal EOF handling, and unsafe runtime termination paths. These details matter because server shutdown is one of the hardest parts of runtime design. A backend runtime must handle active connections, stopped listeners, pending tasks, worker threads, and cleanup order without leaving the system in an unsafe state. The V2 architecture gives Vix a better foundation for that.

RuntimeExecutor

Vix.cpp v2.0.0 replaces legacy executor behavior with RuntimeExecutor. This is part of the broader move toward a clearer runtime execution model. Instead of letting execution behavior remain scattered across older internal patterns, Vix now starts consolidating runtime lifecycle and execution responsibilities into a more explicit foundation. This makes the runtime easier to extend and easier to debug.

WebSocket and middleware migration

The WebSocket and middleware layers were migrated to the new native HTTP stack. This is a major internal change because WebSocket and middleware should not behave like separate systems with separate lifecycle rules. They need to share the same server foundation, the same runtime execution model, and the same shutdown behavior. In V1, the old Boost.Beast-based layer made that harder. Vix had to adapt WebSocket and middleware behavior around Beast-driven internals. In V2, these modules are aligned with the native Vix HTTP stack. That creates a cleaner path for future improvements in real-time applications, middleware pipelines, routing, API documentation, and runtime diagnostics.

Packaging and installation motivation

One of the biggest motivations behind Vix.cpp v2.0.0 is installation simplicity. The V1 architecture made packaging harder because Boost.Beast and related Boost dependencies were deeply connected to the runtime. This created friction for users who wanted to install Vix, build examples, or consume it as a reusable C++ toolchain. Vix.cpp v2.0.0 removes that pressure by moving toward a Boost-free runtime foundation. This does not only make the dependency graph cleaner. It also makes the project easier to distribute, easier to build, easier to debug, and easier to evolve. For a C++ runtime, installation is part of the product. If the dependency model is too heavy or too fragile, adoption becomes harder. V2 fixes the foundation.

Examples and ecosystem cleanup

Vix.cpp v2.0.0 also reorganizes examples across HTTP, cache, P2P, sync, templates, database, ORM, and middleware. Older CRUD-style examples and deprecated demo layouts were removed or replaced with cleaner, more progressive examples. This cleanup matters because examples should teach the current architecture, not preserve old design assumptions. The objective is to make the ecosystem easier to learn while keeping examples close to real usage patterns.

Cross-platform stability

This release improves Windows and MSVC compatibility across CLI, core, and middleware. It also reduces MSVC-specific portability issues, improves environment variable handling, adds fallback behavior for Unicode rendering in terminal output on Windows, and improves formatting stability in the format module. These changes are part of making Vix more serious as a cross-platform runtime. A runtime architecture is not complete if it only works well on one platform.

Highlights

  • Introduced the native vix::http stack.
  • Removed the old Boost.Beast-based HTTP layer.
  • Removed related Boost compatibility paths.
  • Started the Boost-free runtime foundation.
  • Replaced legacy executor behavior with RuntimeExecutor.
  • Improved async HTTP listener startup.
  • Improved runtime executor and shutdown safety.
  • Improved App::close shutdown behavior.
  • Improved worker cleanup and normal EOF handling.
  • Migrated WebSocket to the native HTTP layer.
  • Migrated middleware to the native HTTP layer.
  • Reorganized examples across HTTP, cache, P2P, sync, templates, database, ORM, and middleware.
  • Removed older deprecated demo layouts.
  • Improved Windows and MSVC compatibility.
  • Improved internal consistency across modules.

Breaking changes

Vix.cpp v2.0.0 introduces breaking architectural changes. The old Boost.Beast-based HTTP stack has been removed. Related Boost compatibility paths have also been removed. Legacy executor behavior has been replaced with RuntimeExecutor. Listener startup behavior now follows the new async-first runtime model. Projects depending directly on old Beast-based internals must migrate to the new Vix-native HTTP and runtime APIs.

Compatibility

Vix.cpp v2.0.0 is the first official V2 baseline. It is designed as a clean foundation for future V2 releases, not as a small compatibility patch for V1 internals. Existing projects using high-level Vix APIs should migrate toward the new native runtime model. Projects that depended on Boost.Beast-specific behavior or headers should update their integration to use Vix-owned abstractions instead.

Stability

This release fixes Windows build blockers across CLI, core, and middleware. It reduces MSVC-specific portability issues. It fixes ambiguous std::to_string usage in the template module. It improves environment variable handling for cross-platform support. It adds fallback behavior for Unicode rendering in terminal output on Windows. It improves formatting stability and safety in the format module.

Notes

Vix.cpp v2.0.0 is the real foundation of the V2 series. This release exists because V1 reached the architectural limit of the Boost.Beast-based design. Beast helped Vix start, but it also made the runtime harder to control, harder to package, and harder to evolve as an independent system. V2 resets that foundation. Vix now has a native HTTP stack, a cleaner async-first architecture, better runtime ownership, cleaner module boundaries, and a stronger path toward becoming a complete C++ application runtime. This was not a change for the sake of changing. It was the necessary step to make Vix independent, installable, maintainable, and ready for the next stage of the ecosystem.