Tencent Flare for C++ backend RPC services

Why Tencent Flare targets latency-sensitive C++ backends

Flare addresses the cost of writing and operating C++ backend services with built-in infrastructure, especially synchronous-looking RPC code that must behave well under concurrent I/O. It is aimed at service developers and teams that need low long-tail latency rather than optimizing only for peak throughput. Tencent states that the framework began in 2019 and is used across Tencent Advertising backends. The README does not enumerate the deployed services or explain which components each one uses, so the production context should not be treated as proof that every feature is equally mature.

The project is a broad backend framework rather than a narrow RPC library. Its documented scope includes RPC, fibers, HTTP and Tencent Cloud COS clients, configuration, encoding, compression, encryption, strings, time and date handling, service discovery, load balancing, monitoring, alerting, and tracing. It also describes extension mechanisms for adding protocols and infrastructure. This scope can reduce the number of components a service must assemble, but it also creates a larger adoption surface than a focused RPC library.

The stated performance priority is latency and latency stability, while the README says Flare also tries to maintain competitive throughput. It points to `flare/doc/benchmark.md` for initial comparison data without reproducing the measurements in the main README. An engineer should examine that benchmark file, its workload definitions, and its test conditions before applying its numbers to a particular service.

The fiber and RPC data flow behind synchronous calls

Flare uses an M:N user-space thread model. Its `Fiber` implementation lets application code use synchronous call syntax while operations are scheduled across operating-system threads. The README's concurrent example starts an HTTP request, a Tencent Cloud COS request, and an RPC request through their respective asynchronous interfaces. It passes the three operation objects to `flare::fiber::WhenAll` and waits through `flare::fiber::BlockingGet`.

The important scheduling boundary is that `BlockingGet` blocks a user-space fiber rather than an operating-system thread. Once all three operations finish, the example checks their combined result, logs the responses, and fills the RPC response. This pattern fits a handler that needs several downstream results before producing one answer. It also shows that Flare can coordinate heterogeneous clients instead of requiring concurrency to be expressed through one protocol or client abstraction.

The relay example shows a simpler path. A server registers the `flare` protocol, adds `RelayServiceImpl`, listens on an endpoint, and starts through `flare::Server`. The service creates an `EchoService_SyncStub`, sends an `EchoRequest`, and copies the downstream body into its response. If the RPC fails, it reports the error through `flare::RpcServerController`.

Headers ending in `*.flare.pb.h` are generated by Flare's Protocol Buffers plugin. The README says this approach produces more usable interfaces than Protocol Buffers' native `cc_generic_services`. That generation choice matters for existing projects: teams should confirm that the plugin fits their build rules and generated-code lifecycle. Flare supports message-based streaming RPC, but the main README does not present a complete streaming service example or explain its configuration.

Installing with Git LFS, Blade, or Bazel

The README says required third-party sources are already bundled under `thirdparty/`, so Flare normally does not require each dependency to be installed separately. Those sources are stored with Git LFS, which must be installed and configured before repository contents are obtained. The main README does not provide a clone command or a package-manager installation command, so those steps should follow the source controls already used by the adopting organization.

For daily development, the repository uses Blade. Its documented build form is:

./blade build ...

The documented test form is:

./blade test ...

The README does not identify one complete build target in these commands. A new user therefore needs to choose the relevant target from the repository or follow `flare/doc/intro-rpc.md` when setting up the example service.

Bazel is also supported. The README directs users to `bazel/support/README.md` rather than documenting one complete invocation on the main page. Engineers integrating Flare into an existing Bazel workspace should inspect `.bazelrc`, `.bazelversion`, `WORKSPACE.bazel`, and the `bazel/` directory before assuming that a Blade build maps directly to their rules and dependency declarations.

Linux requires kernel 3.10 or later and GCC 11 or later. The GCC baseline is connected to `std::atomic<T>::wait` and `notify_*` support in libstdc++. The primary Linux architecture is x86-64. Aarch64 and ppc64le are listed as supported, but the README says they have not been used in production. macOS requires version 13 Ventura or later and Apple Clang from Xcode 14 or later, on either arm64 or x86_64. Windows is not listed as a supported platform.

A first RPC service through the relay example

The documented starting route is `flare/doc/intro-rpc.md`, followed by the programs under `flare/example`. The relay example exposes three command-line settings for its listener and downstream Flare service:

DEFINE_string(ip, "127.0.0.1", "IP address to listen on.");
DEFINE_int32(port, 5569, "Port to listen on.");
DEFINE_string(forward_to, "flare://127.0.0.1:5567",
              "Target IP to forward requests to.");

These declarations show default listener address `127.0.0.1:5569` and downstream target `flare://127.0.0.1:5567`. The README does not give a complete executable invocation or the commands that start both example services, so it would be misleading to invent them. The introductory guide and example directory are the sources for selecting the build target and starting the required peers.

The service implementation derives from `SyncRelayService`, constructs `EchoService_SyncStub`, and calls `Echo`. Its entry function creates `flare::Server` with the service name `relay_server`, adds the `flare` protocol and service implementation, calls `ListenOn`, starts the server, and waits for a termination signal. Before this code can compile, the required `*.flare.pb.h` files must be generated through Flare's Protocol Buffers plugin.

For a first evaluation, build the supplied example before changing its service definitions. That keeps code generation and framework integration separate from application changes. Once the example builds, the more complex example can be used to assess asynchronous HTTP, COS, and RPC coordination through `flare::fiber::WhenAll` and `flare::fiber::BlockingGet`.

Flare's platform, packaging, and upgrade boundaries

Flare is not presented as a portable C++ framework with equal support for every environment it mentions. Linux support centers on x86-64, while aarch64 and ppc64le receive no stated production use. Windows is absent from the supported systems. A service targeting one of these gaps would need separate compatibility work that the README does not promise.

The compiler baseline is also significant. GCC 11 and Xcode 14 are required because the project relies on atomic wait and notify runtime support. An older image may otherwise appear to support C++20 but fail when compiling these facilities. Build images should therefore expose their kernel, architecture, compiler, and standard-library versions before application dependencies are added.

Packaging is another constraint. The repository has no GitHub releases, so the documented workflow begins with source acquisition rather than installing a versioned package. It uses Git LFS for bundled third-party sources and supports Blade and Bazel build paths. Adopting teams must decide how they pin revisions, archive dependencies, produce artifacts, and validate upgrades. The README does not document a compatibility matrix, a long-term-support policy, or a rollback procedure.

The repository is not archived, and its last push was on 2026-07-03. That records source activity, but it does not establish a stable release cadence or semantic-version policy. Production adoption should pin an exact commit and inspect the bundled `thirdparty/` contents at that revision rather than assuming a newer commit is a drop-in upgrade.

How Flare differs from brpc and gRPC

The README names brpc and gRPC as design references, but it does not offer a feature-by-feature compatibility comparison. The concrete difference is Flare's runtime and scope. It combines an M:N fiber runtime, synchronous and asynchronous client interfaces, message-based streaming RPC, Tencent Cloud COS support, and a wider set of backend utilities. Its concurrent example coordinates HTTP, COS, and RPC operations inside one fiber.

brpc is cited as inspiration for Flare's lower-level implementation. The README does not claim API compatibility, wire compatibility, deployment compatibility, or support for brpc clients. A migration cannot be inferred from that attribution. Engineers would need brpc's own documentation and direct comparisons of transports, service definitions, and generated interfaces.

gRPC also influenced Flare's RPC design, and Flare works with Protocol Buffers definitions and generated service headers. The README does not state that Flare implements a standard gRPC transport or exposes a gRPC-compatible API. The `flare://` target shown in the relay example and the Flare Protocol Buffers plugin are project-specific interfaces that need direct examination if interoperability with existing gRPC services is required.

A useful comparison should cover runtime scheduling, transports, generated APIs, protocol compatibility, platform builds, dependency policy, licensing, and release handling. Flare's clearest attraction is its fiber-centered C++ backend stack and documented use at Tencent Advertising. Its clearest exclusion is a team that requires Windows, versioned GitHub releases, a conventional license, or a fixed gRPC or brpc interface.

License and dependency review before adopting Flare

Repository metadata classifies Flare's license as a custom license that GitHub cannot classify, while the README displays a NewBSD badge. The README points readers to the repository's `LICENSE` file, and `thirdparty/` contains bundled source packages. Those signals do not establish that every included file is covered by one simple BSD grant. A team considering source redistribution or binary distribution must inspect `LICENSE` and identify the terms attached to each dependency.

This is a compliance and distribution concern rather than a formatting preference. The README does not provide a complete mapping from every package under `thirdparty/` to its license. The discrepancy between repository metadata and the README badge should be resolved before source is copied into another release system. This review concerns project licensing terms and does not constitute legal advice.

Upgrades also carry a source-control cost. Without GitHub releases, teams need an explicit process for pinning commits, reviewing changes under `thirdparty/`, regenerating Protocol Buffers outputs, and repeating builds and tests. The documented commands are `./blade build ...` and `./blade test ...`, but the README does not explain how existing service compatibility is certified across commits. The exact source revision and dependency set therefore need to be tracked alongside application binaries.

Editorial conclusion

Engineers building C++ backend services that need fibers, streaming RPC, and Tencent-style infrastructure should first inspect the LICENSE, verify the custom third-party dependency set, build with Blade or Bazel on a supported host, and confirm that the documented example meets their deployment needs. Projects requiring versioned GitHub releases, an unambiguous standard open source license, or Windows support should stop at those boundaries and select a framework with a more conventional package and release model.

Frequently asked questions

Official sources

1. Issues
2. README
3. Tencent/flare on GitHub