Drogon: a C++ HTTP framework where the controller owns its route

The problem Drogon solves for C++ server developers

Writing an HTTP service in C++ usually means assembling a stack yourself: a socket library, an event loop, an HTTP parser, a routing table, a JSON library, a session store. Drogon bundles those pieces behind one CMake target and one application object. The README describes it as a C++17/20 based HTTP application framework for building web application server programs in C++, and the repository layout reflects that: lib/ for the framework, orm_lib/ for the object-relational mapping layer, nosql_lib/ for Redis, and trantor as a submodule for the underlying network library.

The intended audience is a C++ developer who wants to stay in C++ rather than reach for Go or Node for the HTTP edge. Drogon targets that developer with a specific promise: the main program stays small and the framework handles the rest. The README states that unlike most C++ frameworks, the main program of a drogon application can be kept clean and simple, and that routing settings of controllers can be done through macros or a configuration file.

The scope is wider than routing. The feature list covers HTTP 1.0/1.1 on both server and client side, HTTPS via OpenSSL, WebSocket on both sides, cookies and built-in sessions, gzip and brotli compression, pipelining, file upload and download, JSON request and response handling, plugins loaded from the configuration file, AOP joinpoints, and C++ coroutines. Whether you need all of that is a separate question, but a single framework covering it means one build system and one set of conventions across a service.

How the routing and controller mechanism actually works

Drogon decouples the controller from main() through a template-based reflection mechanism. A controller class derives from HttpSimpleController<TestCtrl>, and the route is declared inside the class body between PATH_LIST_BEGIN and PATH_LIST_END, with PATH_ADD("/test",Get) mapping the path to the HTTP method. The framework discovers that declaration at startup, so main() never needs to know which controllers exist.

The handler signature is asynchronous by construction. A controller overrides asyncHandleHttpRequest, receives an HttpRequestPtr and a std::function callback, and returns nothing. The response is delivered by invoking the callback with an HttpResponsePtr. That shape is what lets the framework keep the I/O non-blocking: the handler can hand work to a database or a Redis client and call the callback later, and the event loop is free in the meantime.

The README is explicit about when not to use the shortcut. Drogon lets you register a handler directly in main() with app().registerHandler, and the README shows an example that binds a path parameter and attaches a filter: app().registerHandler("/test?username={name}", ..., {Get,"LoginFilter"}). But it then says that while such interfaces look intuitive, they are not suitable for complex business logic scenarios, and that unless your logic is very simple, the project does not recommend using them. That is a real design boundary rather than marketing: the inline form is for small cases, and the class form is for everything else.

Filters are the other half of the mechanism. The README describes filter chains as a way to run unified logic before handling HTTP requests, naming login verification and HTTP method constraint verification as examples. A filter is attached to a route by name, as the LoginFilter reference in the registerHandler example shows.

Installing Drogon and generating a first controller

The README does not contain installation instructions; the repository points at the project wiki for documentation, and the presence of a conanfile.txt plus a Conan Center badge indicates Conan is a supported route. The docker/ directory and the Docker image badge indicate a container path as well. Because the README gives no install commands, treat the following as the workflow the repository files describe, not as verified steps.

Drogon ships a command-line tool, drogon_ctl, which the README describes as simplifying the creation of classes and the generation of view code. To create a controller, the README gives this command:

drogon_ctl create controller TestCtrl

That produces a header and a source file. The README states that most of the example programs can be generated this way and that all the user needs to do is add business logic. The generated header follows the pattern the README shows for TestCtrl:

#pragma once
#include <drogon/HttpSimpleController.h>

using namespace drogon;

class TestCtrl : public HttpSimpleController<TestCtrl>
{
public:
    void asyncHandleHttpRequest(const HttpRequestPtr& req, std::function<void (const HttpResponsePtr &)> &&callback) override;
    PATH_LIST_BEGIN
    PATH_ADD("/test",Get);
    PATH_LIST_END
};

A minimal main() then loads configuration and runs. The README gives a two-line form:

#include <drogon/drogon.h>

using namespace drogon;

int main()
{
    app().loadConfigFile("./config.json").run();
}

The repository contains both config.example.json and config.example.yaml, so the configuration file can be written in either format. The README also shows a programmatic form that sets the log path, log level, listener address, thread count and daemon mode directly on app(), for example .addListener("0.0.0.0", 80).setThreadNum(16).enableRunAsDaemon().run(). What you should see after building and starting: the controller responds on the path declared in PATH_ADD, which in the generated example is http://ip/test, returning the body the handler sets.

Where Drogon is the wrong choice

The framework's own README sets the first boundary: the inline registerHandler interface is not suitable for complex business logic, and the project recommends the controller class form instead. If your service is mostly a handful of trivial endpoints, the class-per-controller ceremony is overhead you will feel on every addition.

A second boundary is the build itself. Drogon uses CMake, includes a third_party/ directory and a trantor submodule, and the repository carries a conanfile.txt, build.sh, format.sh and test.sh. That is a normal C++ toolchain, which means your build environment needs to be able to compile the framework and its dependencies. Teams used to dropping a package into a runtime and restarting will find the iteration loop slower.

Platform coverage is broad but not uniform in cost. The README lists Linux, macOS, FreeBSD, OpenBSD, HaikuOS and Windows, and notes that the network library is based on epoll with kqueue under macOS and FreeBSD. Those are two different kernel event mechanisms behind one API, and the README does not describe how much platform-specific code a Windows build pulls in. If Windows is your only target, verify the build path yourself before designing around it.

The README also does not document rollback, migration procedures or a compatibility policy across releases. The presence of both v1.9.x releases and a v1.10.0-beta.3 HTTP/2 client beta release means the project distinguishes stable from beta, but the README does not state what an upgrade between minor versions requires. For a long-lived service, that is a gap you have to close by reading ChangeLog.md.

Drogon compared with Crow and the C++ REST SDK

The nearest comparison in the C++ HTTP space is Crow, which also offers routing through a small amount of code and is header-oriented in its typical use. The difference in approach is where the route lives. Crow applications commonly register routes on an application object in main(), which keeps everything visible in one place. Drogon pushes routes into controller classes via PATH_LIST_BEGIN and PATH_ADD, so routes are discovered rather than listed. If you value one file that shows every endpoint, Drogon's model works against you; if you want each endpoint's code and its route to move together, that is the point of the design.

Against Microsoft's C++ REST SDK (cpprestsdk), the split is different again. cpprestsdk is built around asynchronous task chains and is often used for HTTP clients as much as servers. Drogon provides both a server and a client, but its server story is the deeper one: sessions, filters, view rendering through CSP templates, plugins loaded from configuration, and an ORM in orm_lib/. A team that only needs to call a few REST endpoints from C++ is not the target for Drogon's controller machinery.

On the database side, Drogon's claim is specific: non-blocking I/O based asynchronous reading and writing for PostgreSQL and MySQL/MariaDB, asynchronous sqlite3 access based on a thread pool, and Redis with asynchronous reading and writing. That combination in one framework is less common than it sounds, and it is the strongest argument for adopting Drogon over assembling an HTTP library plus a separate database client.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-16. Recent releases are v1.9.13 on 2026-05-07 and v1.9.12 on 2026-01-26, with v1.10.0-beta.3 released on 2025-12-21 as an HTTP/2 client beta. That release pattern suggests a stable 1.9 line and a 1.10 line still in beta for at least part of its surface.

The licence is MIT. In practice that means you can use Drogon in closed-source and commercial products, and you carry the usual obligation to preserve the copyright notice and licence text. This is not legal advice; check how your organisation handles third-party notices. One thing worth noting for a C++ project: Drogon depends on OpenSSL for HTTPS, and OpenSSL's licence is separate from Drogon's, so your dependency inventory is not just the MIT one.

Upgrade cost is the part the README leaves open. There is a ChangeLog.md at the repository root, which is where release-to-release changes are recorded, but the README does not describe a deprecation policy or a support window for older minor versions. If you pin a version, read ChangeLog.md before moving. The v1.10.0-beta.3 label also tells you the HTTP/2 client is not presented as stable, so do not plan around it without checking the release notes.

Editorial conclusion

Adopt Drogon if you are writing a C++ service and want routing, sessions, WebSocket, an ORM and a database client in one dependency instead of stitching libraries together yourself. Do not adopt it if your team is not comfortable with C++ templates, CMake and a framework that registers controllers through macros, or if you need a language with a larger hiring pool. Before committing, build the helloworld example from a clean checkout on your target platform, then run drogon_ctl create controller on a throwaway name and read the generated header, because the PATH_LIST_BEGIN block it writes is the routing mechanism you will live with.

Frequently asked questions

Official sources

1. drogonframework/drogon on GitHub
2. Issues
3. License: MIT
4. README
5. Releases