Paozhu vs Drogon —C++ Web framework System Design Comparison

Based on source-code verification (paozhu(https://github.com/hggq/paozhu)，drogon(https://github.com/drogonframework/drogon), both retrieved Oct 2026).

Key finding：drogon-master (master branch checked out Oct 2026) has no HTTP/2 server implementation in lib/ or trantor/ (no Http2Server/Http2Connection; lib/src/HttpServer.cc only outputs HTTP/1.1, no h2/ALPN registration; trantor only has TLS-layer ALPN stubs). Paozhu ships HTTP/2 built-in (http2_parse.cpp and related). All Drogon HTTP/2 references below are scoped to the actual code present in this checkout — Drogon's mainline had not yet landed an HTTP/2 server at time of writing, making Paozhu's HTTP/2 a genuine differentiator.

0. One-Line Positioning

• Drogon: Classic muduo-style reactor + reflection-macro registration + compile-time code generation. Industrial-grade, complete ecosystem, friendly high-level API.
• Paozhu (炮竹): Single io_context + Asio C++20 coroutines throughout the stack (even ORM queries are coroutines). HTTP/1.1 and HTTP/2 both custom-built. "Full async coroutine + multi-tenant" orientation.

1. Concurrency / I/O Model (Core Difference)

Philosophical divergence:

• Drogon's "multiple independent loops" fits the classic Reactor model more cleanly — a single connection binds to one thread for its full lifetime, lock-free, good cache locality.
• Paozhu's "single io_context, multiple workers" is the classic Asio model. Coroutine frames live on the heap and don't occupy I/O threads. I/O and business are explicitly layered (I/O coroutines vs. business clientrunpool). router::co_resolve dispatches incrementally: coroutine steps co_await in place; synchronous steps go to the business pool (server.cpp:2351 comment).

2. HTTP Protocol Layer

Note: request.h is a misleading name — Paozhu's actual HTTP request model is httppeer.

2.1 Static File Serving + Compression Cache (Both Have It, Opposite Strategies)

Neither does "real-time compression on every request" — both use a cache after the first access. But the caching strategies are diametrically opposed: Paozhu lazily compresses and auto-writes to disk; Drogon expects pre-compressed files to already exist.

Paozhu — Lazy cache + auto-reclaim (server.cpp:395-518):

• Compress on first request: Detect Accept-Encoding → brotli / gzip → temp file → rename atomic write (safe for concurrent first hits).
• Cache filename: {original_path}.{hash(host+"\n"+urlpath)}.br or .gzip. Subsequent hits just fopen and serve — zero CPU cost.
• Large file protection: Skip compression for content_length > 16MB (saves memory).
• Bad-cache protection: Fall back to original content on compression failure, don't write cache; auto-detects 0-byte cache files, deletes and regenerates.
• Cache reclaim: Pushes mtime back on large-file hits; background daemon reclaims cold entries based on CONST_HTTP_STATIC_CACHE_REFRESH_AGE.

Drogon — Pre-compressed file lookup (config.example.json:296-301 + StaticFileRouter.cc):

• Framework reads but never writes: gzip_static: true (default), brotli_static: false. On request, framework directly looks for pre-compressed .gz / .br files in the same directory. If not found, serves original.
• Requires pre-compression via gzip -k / brotli in CI/CD deploy pipelines. Framework itself never computes compression.
• Plus: IOThreadStorage-isolated static file content cache (StaticFileRouter.h:150-153, per-EventLoop isolation, lock-free).

Essential difference: Paozhu makes compression caching an auto-managed framework concern (lazy compression + atomic write + bad-cache guard + reclaim) — zero developer cost. Drogon pushes compression caching to the deployment phase — framework only reads, never writes, keeping itself lighter. Both have equivalent runtime performance (zero CPU after cache hit), but the first-access path and operational model are different.

3. Routing System (Deep Dive)

Both use "declarative route registration", but the mechanisms fork: Drogon uses compile-time reflection + macros + static self-registration; Paozhu uses source annotations + build-time codegen generating reg_raw tables. Additionally, Paozhu extra-provides simple task orchestration based on httppeer::flow_method (see §3.4). Drogon has no equivalent.

3.1 Registration & Code Generation

Paozhu (controller/src/*.cpp with //@urlpath(pre,urlpath):mask, scanned by paozhu_pre at build time):

• The generated common/autocontrolmethod.hpp contains a reg_raw call table (autocontrolmethod.hpp:127-141): reg_raw(site, path, pre_sync, co_pre, reg_sync, co_reg, mask_code). Each route registers 5 slots: synchronous pre, co_await-pre, synchronous handler, coroutine handler, and mask_code (numeric in the //@urlpath annotation distinguishing HTTP methods).
• Paths with a :param segment get a separate reg_urlpath(site, path, {param_names...}) table right after (autocontrolmethod.hpp:139-140).
• Build also generates helper tables: common/autorestfulpaths.hpp, common/reghttpmethod.hpp, etc.

Drogon (via HttpController.h macros, compile-time):

• METHOD_ADD(method, pattern, ...) / ADD_METHOD_TO(method, path, ...) (HttpController.h:31-34) → registerMethod(&method, pattern, {...}, ...). Also supports ADD_METHOD_VIA_REGEX (:35) for regex patterns.
• Static self-registration: Each controller includes class methodRegistrator + static methodRegistrator registrator_ (HttpController.h:127-139). The constructor registers the method name + parameter pack into the framework — completed by CRT static init before main(), zero runtime scanning. Class-name-to-path mapping is auto-derived by DrClassMap::demangle(typeid(T).name()) (HttpBinder.h:235), :: becomes /.

3.2 Matching Structures

Paozhu: Core router class (router.h:32). At runtime, reg_raw populates _handlers / _urlpath_map / _site_to_slot (global slot 0; multi-tenant see §3.5). co_resolve(peer, known_idx) (router.h:79) coroutine-drives the entire match + pre + handler chain, with route_exact_checked optimization (httppeer.h:298-299, RPC/sync chains skip redundant exact lookup).

• If exact match fails, prefix fallback up to 6 segments (router.cpp two-level lookup: lookup_exact → lookup_registered → lookup_key_in_slots, router.cpp:180-185). Unregistered hop names are skipped during chain draining (router.cpp:350-363).

Drogon: HttpControllersRouter + StaticFileRouter. Three structures (HttpControllersRouter.cc):

• simpleCtrlMap_: no-parameter exact match (lowercase-keyed std::unordered_map).
• ctrlMap_: parameterized but structurally fixed exact routes. ctrlMap_.find(loweredPath) directly hash-hits (HttpControllersRouter.cc:626).
• ctrlVector_: routes with :param / regex. At compile time {param} placeholders are replaced with ([^/]*) via regex_replace (:564). At runtime, std::regex_match does linear matching (:635-640).
• Each route has binders_[req->method()] buckets by HttpMethod; initMiddlewaresAndCorsMethods auto-injects middlewares and opens OPTIONS/CORS (:58/63/75).

3.3 Pre-handler Chain & Sync/Coroutine Mixing

Paozhu — Each route splits into 4 independent slots; sync and coroutine are "first-class routing citizens": reg_raw(site, path, pre_sync, co_pre, reg_sync, co_reg, mask_code) (common/autocontrolmethod.hpp) registers a route as sync-pre / coro-pre / sync-handler / coro-handler four separate entry points. The main driver co_resolve (router.cpp:694) transparently interleaves them: coroutine steps co_await in place (pre co_await h.co_pre(peer); handler co_await h.co_regfun(peer)); synchronous steps go to the business thread pool.

• Sync/coroutine mixing is a built-in capability: Within one request, "sync-pre auth → coro-handler DB lookup" and "coro-pre → sync-handler" can be declared directly. The framework auto-dispatches based on each entry's pre_kind/reg_kind. Developers never need to manually switch threads or wrap in std::async. This is a different design philosophy from Drogon's "handler picks one form, CoroMapper is a separate type" — Paozhu treats "is this a coroutine" as a property of each registration slot, not the handler as a whole.
• Built-in urlpath pre interception: Each route's pre_sync/co_pre chain up in declaration order into a serial pre chain; classify_step() decides direction based on return value — @ok (pass), same-name (continue), @exit (explicit stop), jump name (router.cpp:76-87). First non-empty return short-circuits; empty string is the only "pass" signal (router.cpp:458-461). Additionally, site-level pre/after hooks: run_site_hooks (sync :462) and co_run_site_hooks (coro :478) batch-run action_pre_lists/action_after_lists. When the list exceeds the limit, it truncates to the first site_hook_limit entries rather than dropping the whole thing (avoids silent auth failures).
• Flow stack draining: When the orchestration stack drains (pop_flow_index), if the driver is a sync chain but the popped entry is a coroutine, draining stops (:364-368); if coroutine-driven, it co_awaits inline (:865-873).

Drogon: Pre-handler logic lives in Filters (HttpFilter + ADD_FILTER_TO / GlobalFilters.cc) and Middlewares (HttpMiddleware, MiddlewaresFunction.cc + HttpAppFramework.h:718). The framework executes them before handlers, ordered by path / global ordering, decoupled from the routing table, reusable, sortable. The sync/async choice lives on the individual method form (binder's Blocking/Callback/future triad, or coroutines via separate CoroMapper). There is no slot-based mixed declaration like "one route declares a sync-pre + coro-handler together".

3.4 Simple Task Orchestration (Paozhu flow_method)

Conclusion: Yes, Paozhu has built-in simple task orchestration on httppeer, implemented via httppeer::flow_method for "sequential multi-handler orchestration within a single request".

• Structure: httppeer holds a lazily-allocated stack std::unique_ptr> flow_method (httppeer.h:300-301) — stores names of subsequent handlers to execute.
• Push API (httppeer.cpp:2135-2155):
  • push_next(name): push_back (stack top, LIFO — last pushed runs first).
  • push_last(name): push_front (stack bottom, FIFO — first pushed runs first, the default recommended for sequential breakdowns).
  • push_steps({...}): batch-push.
• Pop/Consume (httppeer.cpp:2156-2169 pop_flow() pops back; router.cpp:340-368 pop_flow_index): After a handler completes normally (returns empty string), the router pops the next registered handler name from the stack and executes it. One handler pops exactly one; the rest wait for that handler to return empty before popping, until the stack empties or the chain hits the top (router.cpp:651-657 sync chain, 834-839 coro chain).
• Flow control directives: kFlowOk / kFlowExit (explicit stop, no pop) / kFlowTimeloop (transfer to event loop), interpreted by classify_step (router.cpp:76-87).
• Robustness: When popping an unregistered name, skip and continue to the next (don't swallow the whole chain, :350-363); a coroutine entry pushed onto a sync chain stops by design (:364-368).

This means one request can do "handler A → push B, C, D → after A returns empty, run B→C→D in order", forming a lightweight sequential workflow / pipeline. Drogon has no equivalent built-in mechanism: its composition primitives are Filters/Middlewares (cross-cutting concerns, not sequential step orchestration) and handler-internal logic. To chain multiple handlers in Drogon, you'd manually call or redirect inside the handler — the framework layer provides no orchestration stack.

3.5 Multi-Tenant / Site Slot

Paozhu：Routes naturally attach to site slots — host_index → slot, _site_to_slot maintains one slot per site. Route tables are isolated by slot (router.cpp:337 find_name_in_slots(peer_slot(peer), ...)); the first argument of reg_raw is site (domain, empty string = global slot 0). Combined with theme views (§9), this is framework-level multi-tenancy.

Drogon：Routes themselves carry no tenant concept. Multi-tenancy is achieved at the business layer via "multiple apps / multiple controller groups + DrObject naming" — no one-stop slot isolation.

3.6 Summary Table

Key difference: Drogon routing is an industrial-class classic pattern — "macro reflection + static registration + Filters/Middlewares" with clean separation of concerns. Paozhu takes an integrated approach — "annotation + codegen + site slot + flow_method orchestration" with built-in light sequential workflow capability and multi-tenancy right at the routing layer.

4. ORM Deep Dive

Both support MySQL / PostgreSQL / SQLite and their ORM queries support C++20 coroutine async. But they differ significantly in generation timing, code organization, query style, caching, transactions, and relationship expression.

4.1 Generated Code Structure

Paozhu (paozhu_cli orm , generator vendor/httpcli/modelfun.hpp) produces three layers per table:

• _base.h: pure data/reflection layer — namespace _info contains col_count, enum cols, struct meta (field definitions), type:: type aliases, col_names, null_col bitmap, assign_field_value (world_base.h:41-45, L76-80), plus dirty-field bitmap __dirty_bits + get_dirty_indices()/clear_dirty()/make_update_dirty_sql().
• _opsql.h: template class _opsql : public B_BASE containing all query/cache/dirty-update methods. Constructor fetches orm_conn_pool from get_orm_conn_pool_obj() per dbtag.
• Dirty-update mechanism: setXxx() marks the corresponding dirty bit when writing a field. update_dirty() (text protocol) / exec_update_dirty() (prepared) / async_update_dirty() / async_exec_update_dirty() / commit_update_dirty() only build UPDATE for dirty-bit fields. On success clear_dirty(). Short-circuits when the dirty set is empty (prevents accidental all-field updates) and refuses execution without WHERE (article_opsql.h:9866/15248/10319/15323/13120). Mechanistically equivalent to Drogon's dirtyFlag_[] — both are "incremental writes of changed columns only".

Drogon (drogon_ctl create_model, reuses CSP templates model_h.csp/model_cc.csp) generates one model class per table (example orm_lib/tests/mysql/Users.h):

Key difference: Paozhu separates "data definition (base)" from "SQL operations (opsql)" into two files and supports external FK .cpp; Drogon puts everything into one model class with private+friend persistence internals — more OOP.

4.2 Query API Style

Paozhu — Chained builder (returns M_MODEL&), method names lean toward "direct SQL verbs":

Drogon — Streaming Mapper + Criteria (template Mapper in orm/Mapper.h:115, constructor takes DbClientPtr):

Style divergence：Paozhu leans toward "familiar chained verbs + per-column shortcuts" — low learning curve. Drogon uses Criteria expression objects + Mapper streaming — more type-safe, but needs understanding the Criteria/SqlBinder system.

Pagination comparison：Paozhu's page() auto-reuses already-set where, completes "count + fetch + return navigation 4-tuple" in one call. Drogon's paginate(page,perPage) (Mapper.h:173/2013) only sets offset/limit; count() defaults to empty Criteria() (Mapper.h:459), so you need to pass the same Criteria to both count(criteria) and the query. Pagination navigation (total pages / window) you compute yourself.

4.3 Query-Result Caching (Largest Functional Gap)

Paozhu — Optional capability on the model object, ready out of the box: Caching is an optional feature on the model object, no third-party library needed. Core API:

4.4 Async & Coroutine Model

Paozhu — Sync + coroutine dual form; coroutine is the primary paradigm:

Drogon — Three forms (sync / callback / future) + coroutine overlay:

4.4.1 Dual-Pool Concurrency Architecture (io_context Coroutine Pool + Dedicated ThreadPool)

Paozhu's execution layer runs two thread pools side by side, with concurrency split into three layers via "strand serialization + business-pool dispatch-back-to-strand + peer chained shared ownership". No GC needed, still safe:

Drogon comparison: Drogon uses "multiple independent EventLoop" (one EventLoop per worker, MPSC cross-thread, epoll/kqueue). Handlers run on the owning ioLoop; heavy blocking needs manual offload. It doesn't have Paozhu's "shared io_context + independent generic ThreadPool + strand closed loop" cross-pool model, so it also avoids the cross-pool object ownership question.

4.5 Transactions

Paozhu transactions have two layers of API, both with real examples in business code (controller/src/test_sql_commit.cpp):

① Native SQL layer (orm::db_conn directly holds the transaction connection):

auto ulink = std::make_unique("cms");
ulink->begin_commit();                 // BEGIN / BEGIN IMMEDIATE
ulink->edit_query("UPDATE sysuser set ...");
ulink->edit_query("INSERT INTO sysuser ...");
// Queries also go through the same write connection (reads what we just wrote, no master-replica replication lag)
orm::cms::LocalusersqlStruct row;
ulink->edit_query("SELECT * FROM sysuser WHERE ...", row);
if (ulink->iserror) ulink->rollback();
else                ulink->commit();

② ORM layer (lock_conn binds the transaction connection to the model):

auto txnlink = std::make_unique("cms");
txnlink->begin_commit();// Multiple different model objects all lock onto the same transaction connection — cross-object transaction
orm::cms::Sysuser user_m;
user_m.lock_conn(txnlink->mysql_edit_conn);
user_m.where("adminid", 10000);
user_m.update("nickname");orm::cms::Sysroles role_m;              // Different table, different model class
role_m.lock_conn(txnlink->mysql_edit_conn);  // Also locks onto the same one
role_m.where("roleid", 50);
role_m.update("remark");user_m.unlock_conn();
role_m.unlock_conn();
txnlink->commit();                      // Unified commit or rollback

Drogon — First-class Transaction object:

Comparison: Drogon uses a first-class Transaction object passed to Mapper — API is clean, models don't know they're inside a transaction. Paozhu is explicit and manual — either use db_conn for native SQL, or lock_conn to bind ORM models to the transaction connection (models need to be aware of transaction state). Both work, but Drogon is more elegant.

4.6 Relationships / Foreign Keys

Paozhu: oneXXX/manyXXX live in external .cpp (orm/fk_child_opsql.cpp / orm/fk_parent_opsql.cpp), implemented by applying where()/whereIn() to the related model using this table's FK values. Also provides generic leftJoin() for explicit JOINs.

Drogon: Relationships are "generation-time config + per-model methods at runtime", no generic Mapper API for hasMany/hasOne style.

4.7 Type Mapping & Parameter Binding

Paozhu: At generation time, modelfun.hpp uses pg_type_to_mysql_type() + SQLite affinity mapping to convert SQL types to MySQL binary type codes, then get_field_type() maps codes to C++ (integers/dates/strings etc.), landing in the struct meta + type:: of _base.h.

Drogon: At generation time, create_model.cc writes per-DB hardcoded mappings (PG / MySQL / SQLite branches). Parameter binding SqlBinder::operator<< branches on ClientType:

4.8 Connection Pools

Paozhu: orm_conn_pool.cpp maintains a read-write separated pool per dbtag (async_get_mysql_select_conn for reads / async_get_mysql_edit_conn for writes); coroutine connection fetch/build via co_await async_add_*_connect; backends pg_conn/mysql_conn/sqlite_conn each implement async_* non-blocking I/O; started by init_orm_conn_pool(io_context,...) (server.cpp:9269).

Drogon: DbClientLockFree (orm_lib/src/DbClientLockFree.cc) with three-state collections connections_/readyConnections_/busyConnections_ (mutex-protected). execSql reuses an idle one if available, otherwise pushes into sqlCmdBuffer_ (max 20000; exceeding it reports "Too many queries in buffer", DbClientLockFree.cc:203). Number of event loops decided by connNum (SQLite fixed at 1, PG/MySQL take min(hardware_concurrency(), connNum)). Per-library connection classes PgConnection/MysqlConnection/Sqlite3Connection only handle single-connection non-blocking I/O; supports execSqlWithTimeout which throws TimeoutError on timeout.

Underlying protocol implementation divergence (architecture-level):

4.9 Business Code Style (Actual Usage)

§4.2 covered API shapes. Here's what real business code looks like (examples taken from both sides' source).

Paozhu — The model object IS the query builder; chained verbs + coro/sync dual form (example controller/src/testormcache.cpp / testcrud.cpp):

// The model object itself is the builder; conditions, caching, and query all chained in one go
Article art;
art.where("isopen", 1).whereEQ(art.Alias::aid, aid).use_cache();  // Chained conditions + query cache
co_await art.fetch_one();                          // Coroutine query, result backfills art
client << "
title:" << art.getTitle();
if (art.is_hit_cache()) { /* cache hit branch */ }// Pagination: directly returns (nav_min, nav_max, cur_page, total_page)
unsigned int page = client.get["page"].to_int();
auto [nav_min, nav_max, cur_page, total_page] = art.page(page, 10, 5); // page, per_page, nav width

Style takeaway: get a model instance → chain .where()/.whereEQ()/.use_cache()/.fetch_one()/.page() on it → co_await or sync fetch_one(). No separate Mapper layer — the model IS the DAO.

Drogon — Generic Mapper + Criteria expression; CRUD by model type (example orm_lib/tests/db_test.cc):

using namespace drogon_model::postgres;
Mapper mapper(clientPtr);          // clientPtr = app().getDbClient()
Users user;
user.setUserId("pg"); user.setUserName("alice");
mapper.insert(user);                      // Sync write
auto u = mapper.findByPrimaryKey(2);      // PK lookup// Coroutine form
CoroMapper cmapper(clientPtr);
auto cu  = co_await cmapper.findByPrimaryKey(2);
auto us  = co_await cmapper.orderBy(Users::Cols::_user_id).limit(2).findAll();
auto one = co_await cmapper.findOne(Criteria(Users::Cols::_id, CompareOperator::EQ, 1));

Style takeaway: Mapper is a generic CRUD facade independent of the model object. Conditions use Criteria(col, op, val) expression construction. The model object only carries data + setter/getter; all persistence goes through Mapper.

One-liner: Paozhu is "the model queries itself" (builder attached to the model, verb-style, quick to pick up). Drogon is "Mapper proxies model CRUD" (generic facade + Criteria expressions, type-safe, cleaner separation of concerns).

4.10 Summary Table

Key difference takeaways:

5. Rate Limiting Comparison

Both have rate limiting at different layers, with some overlap: Drogon has both hard connection caps (HttpConnectionLimit, global + per-IP hard caps) and request-level (per-IP / per-user / per-route, token bucket/sliding window/fixed window, plugin-ready out of the box). Paozhu has connection-admission-level overload protection (60-second connection window + load-adaptive admission rate + queued slow admission) + site upload limits + IP blocking. They approach connection-level protection differently (hard reject vs. queued admission); request-level quotas are Drogon's unique business capability.

5.1 Drogon — Request-Level RateLimiter + Hodor Plugin

Core class (lib/inc/drogon/RateLimiter.h):

Hodor plugin (lib/inc/drogon/plugins/Hodor.h, official Drogon rate-limiting plugin):

Drogon's request-level rate limiting is production-grade, fine-grained, and declarative: configure one JSON block to get "global 1000/s + per-IP 100/s + per-user 50/s" combo policies matching URLs like /api/.*, with swappable algorithms.

Hard connection cap (lib/src/HttpConnectionLimit.h:26, atomic counting at accept stage):

5.2 Paozhu — Connection-Admission Overload Protection + Upload Limits + IP Blocking

Connection admission throttling (built into httpserver core, server.h:247 ratelimiter() thread-driven):

Upload limits: httppeer::check_upload_limit() (httppeer.cpp:789, guarded by site-level host_index) — limits upload body size per site.

IP blocking: check_blockip(peer_session) (server.cpp:5757, TLS handshake failed connections excluded from traffic counts), blacklist/whitelist access-layer interception.

Paozhu has no built-in "per-IP / per-user / per-route request quota" layer, but can be implemented with framework capabilities: add an IP sliding-window counter (maintaining std::unordered_map>) inside router's site pre hooks (action_pre_lists, router.cpp:462), and on limit hit return httppeer::kFlowExit (@exit) to reject the request — the pre chain short-circuits on the first non-empty return. The whole implementation closes within the framework, no core extension needed.

5.3 Summary Table

Core difference: Drogon rate limiting is two-layer — bottom layer HttpConnectionLimit hard cap (prevent overload, reject immediately on over-limit) + top layer Hodor request-level quota (business-friendly, per-IP/user/route, swappable algorithms, pluginized). Paozhu is single-layer connection-admission-level protection — over threshold it doesn't reject, it queues and admits gradually (gentler, avoids transient rejection shock), but request-level quotas need self-implementation via site pre hooks. The two-layer connection protection is different strategies for the same problem (hard reject vs. queued admission), not entirely non-overlapping.

6. Protocol & Middleware Support (WebSocket / MQTT / Redis / RPC / Socket)

This dimension diverges sharply: Paozhu builds all five protocol types natively into httpserver core (and uses a unified subpub registration model across ws/mqtt/socket); Drogon only builds WebSocket and Redis natively, with no framework-level support for MQTT / RPC / raw Socket servers.

6.1 WebSocket

6.2 Redis

6.3 MQTT

6.4 RPC

6.5 Raw Socket / TCP Server

6.6 Architecture Theme: Unified subpub Registration Model

Paozhu uses *_subpub_reg across ws/mqtt/socket (ws_subpub_reg / mqtt_subpub_reg / sock_subpub_reg) — the same "subscription registration + publish dispatch" kernel spans multiple protocols. Redis also goes through redis_subpub. This is the unified abstraction behind Paozhu's "protocol big family". Drogon's capabilities are independent of each other (WebSocket controller, Redis nosql lib, no MQTT/socket), with no framework-level cross-protocol unified pub/sub kernel. However, the business layer has a PubSubService template class (lib/inc/drogon/PubSubService.h) — it provides named topics + subscribe/publish/unsubscribe, uses shared_mutex + copy-on-write, and is an in-process tool for business code, not a protocol dispatch mechanism inside the framework.

6.7 JWT & OAuth 2.0 / OIDC

6.8 Session Management

6.9 HTTP Client

6.10 Monitoring & Observability

6.11 Timers & Scheduled Tasks

Paozhu timeloop workflow (using frametasks_timeloop as example):

1. Business code calls httppeer.add_timeloop_task("frametasks_timeloop", 100)→ peer.linktype = 7, timeloop_num = 100
2. server.cpp main loop: fps++ every frame
3. When fps % 100 == 0 AND timeloop_inflight == false:→ CAS sets timeloop_inflight→ Dispatches to clientrunpool thread pool (linktype==7 → timetasks_run)
4. Inside thread pool (threadpool.cpp:603):→ router.run_timeloop_task(peer, "frametasks_timeloop")→ call_sync_regfun finds the controller function with the same name (registered at serverwatch.cpp:67)→ After execution, inflight_release() resets timeloop_inflight

Drogon EventLoop Timer usage:

auto loop = drogon::app().getMainEventLoop();
// Run every 5 seconds
auto tid = loop->runEvery(5.0, [] { doSomething(); });
// Cancel
loop->cancel(tid);

Summary: Neither supports cron expressions; both are interval-based timers. But business-layer plug-in cost is drastically different. Paozhu binds scheduled tasks to route handlers + thread-pool execution, fully integrated with the framework routing system — write a sync controller function annotated with //@urlpath(null, taskname), plus an arm route (URL trigger or startup-time registration), and the task is into the scheduler; deleting the controller file auto-clears the task table. Zero boilerplate, zero framework-API learning cost, routes and tasks share one registration. But it only accepts sync annotation functions (fn_kind::sync); coroutine handlers are skipped (timeloop runs in a sync thread pool, no strand to co_spawn on). Drogon is a low-level EventLoop primitive (higher precision, richer API — runAt/runAfter), but interval-task→business-handler mapping, EventLoop ownership, TimerId lifecycle all must be handled by business code itself, with no controller annotation auto-registration.

6.12 Summary Table

Core difference: Paozhu is "multi-protocol + built-in identity stack + resident outbound" — one framework is simultaneously HTTP/2, WebSocket, MQTT(broker), Redis, RPC, raw Socket server, with built-in JWT + OAuth 2.0/OIDC authorization server, plus Session, HTTP client, and four resident outbound clients (Redis subscription / WS / TCP / MQTT). But monitoring needs business-layer integration, no HTTP pipeline, no handler-per-chunk-callback streaming request body (only parser-layer auto-persist memory protection), no reverse proxy, no LISTEN/NOTIFY. Drogon is a "production-grade Web framework focused on HTTP" — WebSocket and Redis are first-class citizens, HTTP client is stronger (with pipeline), Session/monitoring/Prometheus/RequestStream/reverse proxy/DbListener are all built-in, with a unified plugin system. But JWT/OAuth/MQTT/RPC/TCP/resident outbound are delegated to external libraries or self-implementation — the framework itself doesn't build them in.

6.13 Drogon-Exclusive HTTP Enhancements (Items marked as Drogon-only in §6.12 table)

The following capabilities are directly provided by Drogon's framework layer, with no equivalent API in Paozhu:

RequestStream streaming request body (RequestStream.h + MultipartStreamParser.h): per-chunk callbacks; handler doesn't wait for the entire body to arrive before processing. Multipart stream parser decomposes while receiving. Enable with enableRequestStream(true); handler receives RequestStreamPtr. Official example examples/async_stream/RequestStreamExampleCtrl.cc.

Note: Paozhu also has large-file memory protection, but by a different mechanism. Multipart uploads have auto-persist at 3MB threshold (http_parse.cpp: opens fp when threshold exceeded, then post_multipart_itemcontent_append() flushes accumulated blocks via fwrite). HTTP client has save(path) → respreadtofile() streaming file-write interface. Neither accumulates large files in memory, but Paozhu doesn't have Drogon's framework-level "handler gets per-chunk callbacks" streaming API: Paozhu's parser layer auto-persists to disk, business handlers receive paths to already-persisted temp files (httppeer::upload_file.tempfile), business code never sees the byte stream itself.

Reverse proxy / forward() (HttpAppFramework.h:732-764): framework-level built-in reverse proxy. forward(req, targetHost) forwards requests to a specified backend. Plugin example examples/simple_reverse_proxy/ uses IOThreadStorage> as a connection pool, isolated per EventLoop for lock-freedom.

DbListener — PostgreSQL LISTEN/NOTIFY (DbListener.h): based on PostgreSQL native LISTEN/NOTIFY, event-driven, no polling. DbListener::newPgListener(connectionInfo) → listen(chan, cb) / unlisten(chan). Complete db_listener_test.cc.

Plugin system (AOP Advice): unified framework plugin mechanism, three hooks registerSyncAdvice / registerPreHandlingCallback / registerPostHandlingCallback. Redirector, SlashRemover, AccessLogger, GlobalFilters, PromExporter, Hodor all go through this system; plugins can declare dependencies, startup order auto-topologically sorted.

6.14 Paozhu-Exclusive Resident Outbound Clients (Items marked as Paozhu-only in §6.12 table)

At framework boot, four types of resident outbound clients can be spun up, sharing the same coroutine pool as HTTP handlers, for cross-process reporting / subscription:

Unified management infrastructure:

Drogon comparison: No framework-level resident client registration system. DbListener (PostgreSQL LISTEN/NOTIFY) is DB-layer only; HttpClient is on-demand — neither is a "process-boot-spun, long-lived outbound long connection".

7. Controllers & Code Generation

Key differences:

7.1 Minimal Working Examples (Annotation Functions vs. Registration Macros)

Paozhu — Annotation functions (from controller/src/testrand.cpp, real minimal form):

#include "httppeer.h"
namespace http
{
//@urlpath(null,testrand)        // site(null = global slot) + URL path; no pre-filter
std::string testrand(std::shared_ptr peer)
{httppeer &client = peer->get_peer();client << "

Random number: " << rand_range(100, 999) << "

Drogon — Registration macro (HttpController + reflection, class name auto-derived to path):

class TestCtrl : public drogon::HttpController
{public:METHOD_LIST_BEGIN// Path "/testrand", GET method, binds testrand methodADD_METHOD_TO(TestCtrl::testrand, "/testrand", Get);METHOD_LIST_ENDvoid testrand(const HttpRequestPtr &req,std::function &&cb) const{auto resp = HttpResponse::newHttpResponse();resp->setBody("

Random number

One-liner: Paozhu is "one //@urlpath annotation in business code completes registration" — declarative, zero boilerplate. Drogon is "declare routes inside the class with METHOD_LIST_BEGIN/ADD_METHOD_TO macros" — macro reflection, requires inheriting from an HttpController base class.

7.2 Code Generation Engine (vendor/httpcli) vs. Database Migration Tools

Clarification: Paozhu's vendor/httpcli/ is not a database migration tool — it's the build-time codegen / ORM schema parsing engine (the implementation behind paozhu_pre, the CMake target paozhu_codegen), equivalent to Drogon's drogon_ctl. It does three things:

Migration tool comparison:

Conclusion: Neither has Flyway/Liquibase-style versioned migration executors, and both support database-first (connect to live DB to reverse-generate models: Drogon create_model; Paozhu modelfun.hpp runs SHOW CREATE TABLE / PG table lists). The difference is Paozhu additionally supports pure offline schema/*.sql generation (CI-friendly, decoupled from DB), while Drogon's create_model must connect to a live DB. If you need a real DB migration pipeline, both need external tools or self-managed SQL scripts — this is the uncovered area in the "full self-built stack" engineering story.

8. C++20 Coroutines

Key difference: Paozhu makes coroutines the only first-class citizen (IO, business, DB all end-to-end awaitable). Drogon is a hybrid model: "callbacks/future as base + coroutine overlay". Paozhu uses Asio's standard co_await; Drogon has self-developed Task/Awaiter system.

9. Multi-Tenant / Theme

Paozhu's multi-tenancy is framework-level built-in (domain → slot → route-table isolation + theme views). Drogon has no equivalent one-stop multi-tenant abstraction in this tree.

10. Dependencies & Engineering

10.1 Wrap-Up: Zero-Third-Party Built-in "Big Family" (Paozhu Engineering Mainline)

Consolidating all self-built points from previous sections into one statement: Paozhu has extremely thin mandatory external dependencies (only Asio + OpenSSL 3). On top of that, almost the entire stack is self-built — the only exception is SQLite (embedded DB, no independent wire protocol to self-implement, uses official sqlite3 C API, linked when ENABLE_SQLITE=ON). Drogon's core is also thin (trantor + OpenSSL/Botan), but capabilities are assembled from an ecosystem.

Paozhu self-built coverage (no corresponding third-party lib pulled in)

Drogon comparison (thin core + ecosystem assembly)

Costs and benefits come from the same source: Paozhu's "self-built big family" brings simpler deployment (fewer external libs to install), capability consistency, zero protocol authorization/version entanglement — but enormous code size, self-implemented correctness risk, and a small ecosystem/community (see §11). Drogon takes "HTTP depth + easy assembly" as its engineering mainline.

11. Design Tradeoffs Summary

Paozhu strengths

Paozhu costs

Drogon strengths

Drogon costs (measured in drogon-master)

12. Selection Guide

Appendix: Key Source Evidence Index