💡C# REST API vs. Boost C++ Microservices: A Developer's Perspective

As a C# developer, you're likely familiar with the ease and speed of building web APIs and microservices using frameworks like ASP.NET Core. It's a highly productive environment. Having worked with C++ for some time and recently came across Boost, I tried to write simple APIs using it. In a previous blog, I shared the challenges I encountered while installing Boost. In this article, I want to share my experience working with microservices in both C# and C++. This post compares the process of building microservices using C# (with ASP.NET Core) and C++ (with Boost.Asio and Boost.Beast), highlighting how they differ in structure, abstraction, and developer experience — purely from a practical, developer’s perspective.

I genuinely enjoyed working with both, and each brings its own strengths to the table. This write-up is a reflection of that journey — and I hope it helps someone exploring similar paths.

🚄 C# Microservices (ASP.NET Core): The Express Lane

When building a REST API in C#, especially with ASP.NET Core, the framework manages a significant amount of underlying complexity. This allows developers to focus primarily on their business logic.

How it's built (the C# way):

1. Project Setup: A simple dotnet new webapi command provides a fully functional starter project, ready for immediate development.

2. Controllers & Routing: C# classes marked with attributes like [ApiController] contain methods ([HttpGet], [HttpPost]) that directly map to API endpoints. The framework intelligently routes incoming HTTP requests to the appropriate method.

3. HTTP Abstraction: Developers interact with high-level objects such as HttpRequest, HttpResponse, and custom C# models. The framework handles intricacies like parsing JSON/XML payloads, validating inputs, and serializing outputs.

4. Middleware: Integrating functionalities like authentication, logging, or error handling is typically streamlined, often requiring minimal code to include pre-built middleware components in Program.cs.

5. Memory Management: Object allocation uses the new keyword, and the .NET Runtime's Garbage Collector (GC) automatically reclaims memory from unreferenced objects. Explicit memory deallocation (delete) is rarely a concern.

Example (C# ASP.NET Core Controller):

using Microsoft.AspNetCore.Mvc;
using System.Collections.Generic;
using System;

[ApiController]
[Route("[controller]")]
public class HelloController : ControllerBase
{
    [HttpGet("/hello")]
    public string GetHello()
    {
        Console.WriteLine("Handling /hello request (C#)");
        return "Hello from C# server!";
    }

    [HttpGet("/users")]
    public ActionResult<IEnumerable<string>> GetUsers()
    {
        Console.WriteLine("Handling /users request (C#)");
        var users = new List<string> { "UserA", "UserB", "UserC" };
        return Ok(users);
    }
}

This approach leads to concise, readable, and rapidly developed code.

⚙️ C++ Microservices (Boost.Asio/Beast): The Precision Engine

In the C++ environment, using libraries like Boost.Asio for asynchronous I/O and Boost.Beast for HTTP parsing offers extensive control over system resources and networking details. This approach is akin to building a specialized engine from its foundational components.

How it's built (the C++ Boost way):

1. Manual Setup: Unlike C#, there's no single cpp new webapi command. Developers begin from a blank slate, manually configuring compiler flags, include paths, and explicitly linking required libraries (as demonstrated with g++ and Vcpkg setup).

2. Low-Level Networking: Instead of abstract controllers, interaction occurs directly with network sockets (tcp::socket), asynchronous I/O contexts (asio::io_context), and event loops, providing granular control over network operations.

3. Explicit HTTP Parsing: Boost.Beast provides http::request and http::response objects. Developers explicitly call functions like http::async_read to parse incoming raw bytes into a structured request object, and http::async_write to serialize a response object back into bytes for transmission.

4. Asynchronous Callbacks: The fundamental programming paradigm involves asynchronous operations managed through callbacks (also known as handlers). Specific functions (on_accept, on_read, on_write) are invoked upon the completion of an asynchronous event, such as a connection being accepted, a request being fully read, or a response being sent.

5. Manual Resource Management (with Smart Pointers): The C++ runtime does not include a garbage collector. Developers are responsible for managing object lifetimes using RAII (Resource Acquisition Is Initialization) principles and smart pointers (e.g., std::shared_ptr, std::unique_ptr). Explicit use of std::make_shared and inheritance from std::enable_shared_from_this is crucial to ensure that objects, such as an http_session, remain alive as long as asynchronous operations associated with them are pending, preventing resource leaks and ensuring stability.

🧠 Core C++ Components and C# Analogies

To further understand the C++ approach, let's break down its key components and draw parallels to concepts familiar to a C# developer:

• asio::io_context:

  • C++ Role: This is the central hub for all asynchronous I/O operations. It manages a queue of "work" (asynchronous operations) and dispatches "completion handlers" (callbacks) when those operations finish. It typically runs on one or more threads.

  • C# Analogy: Think of it as a specialized, single-threaded (or multi-threaded if explicitly set up) TaskScheduler combined with a hidden event loop that specifically manages network I/O. It's not a direct counterpart to anything you explicitly write in ASP.NET Core, as the framework abstracts this. In ASP.NET Core, Kestrel's underlying event loop handles this.

• http_listener Class:

  • C++ Role: This class is responsible for "listening" on a specific network port (e.g., 8080) for incoming TCP connections. When a new connection arrives, it initiates an async_accept operation. Its run() method effectively starts the server.

  • C# Analogy: This is similar to the internal workings of Kestrel in ASP.NET Core. When you call Host.CreateDefaultBuilder().ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }).Build().Run();, Kestrel sets up listeners on specified ports. The http_listener in C++ is the explicit, programmatic representation of that listening component.

• http_session Class:

  • C++ Role: Each instance of http_session is dedicated to managing the full lifecycle of a single, accepted client connection. It owns the tcp::socket associated with that client and handles reading incoming HTTP requests (async_read) and writing outgoing HTTP responses (async_write) on that specific connection. It also manages connection persistence (Keep-Alive).

  • C# Analogy: This is roughly analogous to the internal "context" that ASP.NET Core creates for each incoming HTTP request. In C#, when an HTTP request comes in, the framework allocates objects (like HttpContext, HttpRequest, HttpResponse) that are specific to that request/connection, and these are then passed down to your controller methods. The http_session in C++ is a more explicit, developer-managed object that encapsulates the same concept of per-connection state and processing.

• Handler Functions (on_accept, on_read, on_write):

  • C++ Role: These are callback functions that Boost.Asio invokes when an asynchronous operation (like accepting a connection, reading a request, or writing a response) completes. They are the "continuation" points in the asynchronous flow.

  • C# Analogy: This is similar to how async/await works under the hood, or how event handlers function. When you await an HttpClient.GetAsync() call in C#, the framework registers a continuation. Once the network I/O is done, that continuation (your code after await) is executed. In C++, you're explicitly defining these continuation points as separate handler methods.

Full C++ Boost.Asio/Beast Asynchronous Server Example:

#include <boost/asio.hpp>
#include <boost/beast.hpp>
#include <boost/beast/http.hpp>
#include <boost/beast/version.hpp>
#include <iostream>
#include <memory> // Required for std::make_shared
#include <string>
#include <thread> // For io_context threads, if using multiple

namespace asio = boost::asio;
namespace http = boost::beast::http;
using tcp = asio::ip::tcp;

// Forward declaration of the session class
class http_session;

// Function to handle HTTP requests
void handle_request(const http::request<http::string_body>& req, http::response<http::string_body>& res) {
    // Set up a standard HTTP response
    res.version(req.version());
    res.keep_alive(req.keep_alive());
    res.set(http::field::server, BOOST_BEAST_VERSION_STRING);
    res.set(http::field::content_type, "text/plain");

    // Route requests based on the target path
    if (req.target() == "/hello") {
        res.result(http::status::ok);
        res.body() = "Hello from Asynchronous C++ server";
    } else if (req.target() == "/users") {
        res.result(http::status::ok);
        res.body() = "User1, User2 (from async server)";
    } else {
        res.result(http::status::not_found);
        res.body() = "Not Found (from async server)";
    }

    res.prepare_payload(); // Calculate Content-Length
}

// Represents an active HTTP session with a client
class http_session : public std::enable_shared_from_this<http_session> {
    tcp::socket socket_; // The socket for this connection
    boost::beast::flat_buffer buffer_; // Buffer for reading request data
    http::request<http::string_body> req_; // HTTP request object
    http::response<http::string_body> res_; // HTTP response object

public:
    // Constructor: Takes a socket object
    explicit http_session(tcp::socket socket)
        : socket_(std::move(socket)) {}

    // Start the session: Initiates an asynchronous read operation
    void start() {
        // We use a lambda as the completion handler for async_read.
        // `shared_from_this()` creates a shared_ptr to `this` instance,
        // ensuring the session object stays alive as long as asynchronous
        // operations are pending.
        http::async_read(socket_, buffer_, req_,
                         boost::beast::bind_front_handler(
                             &http_session::on_read,
                             shared_from_this()));
    }

private:
    // Callback function called when the asynchronous read operation completes
    void on_read(boost::beast::error_code ec, std::size_t bytes_transferred) {
        if (ec == http::error::end_of_stream) {
            // Client closed the connection cleanly
            std::cout << "Client closed connection cleanly.\n";
            return;
        }
        if (ec) {
            // Handle other read errors
            std::cerr << "Read error: " << ec.message() << "\n";
            return;
        }

        // Log successful read (optional)
        std::cout << "Received request from " << socket_.remote_endpoint() << "\n";

        // Process the request and build the response
        handle_request(req_, res_);

        // Initiate an asynchronous write operation to send the response
        http::async_write(socket_, res_,
                          boost::beast::bind_front_handler(
                              &http_session::on_write,
                              shared_from_this()));
    }

    // Callback function called when the asynchronous write operation completes
    void on_write(boost::beast::error_code ec, std::size_t bytes_transferred) {
        if (ec) {
            // Handle write errors
            std::cerr << "Write error: " << ec.message() << "\n";
            return;
        }

        // Check if the server should close the connection based on the client's request
        if (!res_.keep_alive()) {
            // Close the socket if keep-alive is not requested
            std::cout << "Closing connection for " << socket_.remote_endpoint() << "\n";
            socket_.shutdown(tcp::socket::shutdown_send, ec);
            // Don't care about the error code here, as we're closing anyway
            return;
        }

        // If keep-alive is true, clear for next request and read again
        // Reset the request and buffer for the next request on this same connection
        req_ = {}; // Clear previous request data
        buffer_.consume(buffer_.size()); // Clear the buffer
        start(); // Start reading the next request on this connection
    }
};

// Listener class to accept incoming connections
class http_listener : public std::enable_shared_from_this<http_listener> {
    asio::io_context& ioc_; // Reference to the io_context
    tcp::acceptor acceptor_; // The acceptor for listening to new connections

public:
    // Constructor: Takes io_context and endpoint
    http_listener(asio::io_context& ioc, const tcp::endpoint& endpoint)
        : ioc_(ioc), acceptor_(ioc, endpoint) {
        std::cout << "Server listening on port " << endpoint.port() << "...\n";
    }

    // Start accepting connections asynchronously
    void run() {
        // `async_accept` initiates an asynchronous accept operation.
        // When a new connection arrives, `on_accept` will be called.
        acceptor_.async_accept(
            boost::beast::bind_front_handler(
                &http_listener::on_accept,
                shared_from_this())); // Keep listener alive
    }

private:
    // Callback function called when an asynchronous accept operation completes
    void on_accept(boost::beast::error_code ec, tcp::socket socket) {
        if (ec) {
            std::cerr << "Accept error: " << ec.message() << "\n";
        } else {
            // Connection accepted successfully!
            std::cout << "Connection accepted from: " << socket.remote_endpoint() << "\n";
            // Create a new session for this accepted socket
            // `std::make_shared` is used to manage the lifetime of the http_session object.
            // The session will keep itself alive as long as its async operations are pending.
            std::make_shared<http_session>(std::move(socket))->start();
        }

        // Always continue accepting new connections, even if an error occurred
        // This ensures the server keeps listening for new clients
        run();
    }
};

int main() {
    try {
        std::cout << "Initializing asynchronous microservice...\n";

        // Create the io_context. It's the central hub for all I/O operations.
        // It should generally run on one or more threads.
        asio::io_context ioc{1}; 

        // Create the endpoint to listen on (IPv4, port 8080)
        tcp::endpoint endpoint(tcp::v4(), 8080);

        // Create and start the listener.
        // `std::make_shared` is important here to ensure the listener object's lifetime
        // is managed by a shared_ptr, so it doesn't get destroyed prematurely.
        std::make_shared<http_listener>(ioc, endpoint)->run();

        // Run the io_context. This call will block until all asynchronous
        // operations complete (i.e., when the server is explicitly stopped or no more work).
        // For a server, you usually want it to run indefinitely.
        std::cout << "Async server running. Press Ctrl+C to stop.\n";
        ioc.run();

    } catch (const std::exception& e) {
        std::cerr << "Server error: " << e.what() << "\n";
    }

    return 0;
}

This full C++ example demonstrates how an asynchronous server handles each incoming connection (http_session) and processes requests/responses on a single underlying io_context thread, which is more scalable than a thread-per-connection model.

📊 Key Differences: A Developer's Perspective

Let's translate the experience for a C# mindset, maintaining a neutral stance on their respective advantages:

• Abstraction Level:

  • C# (ASP.NET Core): Operates at a high level of abstraction. Developers primarily interact with IActionResult, JsonResult, and HttpClient, with the underlying TCP/IP, HTTP parsing, and thread management largely handled by the framework. This is analogous to using a high-level ORM for database interactions, focusing on object manipulation rather than raw SQL.

  • C++ (Boost.Asio/Beast): Works closer to the operating system's networking stack. Developers explicitly interact with tcp::socket objects, manage asynchronous operations, and directly handle raw HTTP message components. This is comparable to writing raw SQL and manually managing database connections, offering fine-grained control but with increased complexity.

• Development Velocity & Boilerplate:

  • C#: Characterized by faster iteration cycles and less boilerplate code for common tasks like routing, dependency injection, and JSON serialization/deserialization. NuGet streamlines library management.

  • C++: Development can be more verbose, often requiring manual setup, meticulous configuration of compiler flags and include paths, and explicit linking of specific libraries. Even fundamental server functionalities typically involve more lines of code and a deeper understanding of network protocols.

• Runtime Performance & Resource Utilization:

  • C#: Provides excellent performance for a wide range of enterprise applications. The .NET Runtime includes Just-In-Time (JIT) compilation and various runtime optimizations. However, the Garbage Collector (GC) can occasionally introduce brief, unpredictable pauses if not carefully managed.

  • C++: Offers the potential for higher raw performance and a smaller memory footprint. Code compiles directly to native machine code, eliminating JIT overhead and GC pauses. Developers gain direct control over memory allocation and CPU cycles. This characteristic makes C++ a frequent choice for applications demanding extreme performance, such as high-frequency trading systems, game servers, or real-time data processing.

• Memory Management Paradigm:

  • C#: The Garbage Collector automates memory reclamation. Developers primarily use new to allocate objects and seldom need to manually delete them.

  • C++: Lacks a garbage collector. Developers are solely responsible for memory management. Smart pointers (std::shared_ptr, std::unique_ptr) are essential tools that implement RAII (Resource Acquisition Is Initialization). They automatically manage resource lifetimes (including memory and network sockets) by tying them to object scopes. The std::shared_ptr combined with std::enable_shared_from_this pattern in Boost.Asio provides a mechanism similar to reference counting, but it is explicitly managed by the developer and enforced by the compiler, rather than being handled implicitly by a runtime GC.

• Ecosystem & Tooling Maturity:

  • C#: Benefits from a mature and highly integrated ecosystem, including powerful IDEs like Visual Studio, efficient code editors with extensions (Visual Studio Code with C# Dev Kit), robust package management (NuGet), and comprehensive debugging capabilities.

  • C++: The ecosystem can appear more fragmented. While modern tools like VS Code and Vcpkg have significantly improved the development experience, the integration is often not as seamless as in the .NET world. Debugging low-level network issues or memory-related problems can present greater challenges.

🤔 When to Consider Each Approach:

• C# (ASP.NET Core) is a strong consideration when:

  • Rapid development cycles and quick deployment are primary objectives.

  • The microservice focuses heavily on business logic and standard HTTP communication patterns.

  • Access to a large, mature ecosystem of libraries (via NuGet) and integrated tooling is a priority.

  • Maximizing developer productivity is a key concern.

  • The application fits typical enterprise scenarios, internal APIs, or standard web services.

• C++ (Boost.Asio/Beast) is a strong consideration when:

  • Absolute extreme performance, minimal latency, or exceptionally high throughput are non-negotiable requirements (e.g., highly concurrent network proxies, specialized communication protocols, real-time control systems).

  • Strict constraints on resource consumption (CPU, memory, power) are critical.

  • Fine-grained control over network behavior, threading models, and memory allocation is necessary.

  • Integration with existing C++ codebases or low-level system components is a requirement.

  • The development involves specialized network infrastructure or custom protocols.

✨ Conclusion

Both C# with ASP.NET Core and C++ with Boost.Asio/Beast represent powerful paradigms for constructing microservices. C# excels in fostering developer productivity, enabling rapid iteration, and offering a highly abstracted development experience, making it a compelling choice for many contemporary web services. C++, conversely, provides the capacity for superior raw performance and direct system control, but necessitates a deeper engagement with system-level complexities and explicit resource management.

Understanding these inherent tradeoffs empowers developers to select the most appropriate technology stack for their specific project requirements. For many typical REST API scenarios, the efficiency and productivity offered by C# may be a more pragmatic choice. However, for highly specialized or performance-critical services where every processing cycle and byte of memory matters, C++ remains a highly capable and, at times, indispensable option.