# Wangle: a C++ networking library built on folly and fizz > Wangle is Facebook's answer to combining Netty and Finagle in C++, wrapping folly's async IO with bootstraps, pipelines and service filters. It also drags two large Meta dependencies along with it, which is the decision that shapes who can realistically use it. **facebook/wangle** — Wangle is a framework providing a set of common client/server abstractions for building services in a consistent, modular, and composable way. - Repository: https://github.com/facebook/wangle - Stars: 3,092 · Forks: 547 - Language: C++ - License: Apache-2.0 - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/facebook-wangle ## Netty and Finagle in one C++ stack The README's own summary of the project is blunt: it is a library that makes it easy to build protocols, application clients, and application servers, and it describes itself as Netty plus Finagle smooshed together, but in C++. That framing is worth unpacking, because those two Java and Scala libraries cover different halves of the problem. Netty contributes the server side shape: thread pools for accept and IO work, a pipeline of handlers that transform socket data, and a bootstrap object that assembles all of it. Finagle contributes the client side: matched service interfaces, client pooling, load balancing, retries and stats. A C++ service that wants both ends of a request and response protocol written once and shared between client and server has historically had to pick one or hand-roll the other half. Wangle's answer is to sit one level above folly's async IO, which the documentation positions by comparison against boost::asio, and to expose both halves as first class. The interfaces are asynchronous and built on folly Futures, with fiber support named as something still being explored. The practical consequence is that Wangle is not a standalone networking library in the way many people expect the word to mean. Its value is as the service framework above an async runtime, and the dependency list at the top of the README makes that concrete. ## Building requires folly, fizz, CMake and OpenSSL The dependency list is short enough to quote in full and heavy enough to matter. The main dependencies are the folly library, the fizz library, CMake, and OpenSSL at version 1.0.2 or newer, preferably built with TLS extension support. Both folly and fizz are Meta projects with their own build requirements, and Wangle expects folly to be installed first. Given that, the build itself is short. Once folly is in place, you run these in the wangle directory: ```bash cmake . make ctest sudo make install ``` That is an in-source cmake configure followed by a build, the test suite, and an install step that needs root. The `sudo make install` is worth noticing: it installs into system paths, which is fine on a workstation and awkward inside a container image or a hermetic build. The repository does carry Buck build support, with a `buck2/` directory and `.buckconfig.d/`, and a `build/` directory at the top level, so there is more than one build path even though the README documents only the cmake one. The fizz dependency deserves a note. Fizz is Facebook's TLS implementation, which is why the OpenSSL requirement is really about fizz's own build rather than something Wangle calls directly. If you only need a plain TCP service, you are still building a TLS stack. ## ServerBootstrap manages accept threads and SO_REUSEPORT `ServerBootstrap` sets up one or more acceptor threads and one or more sets of IO threads, with the option to make them the same pool. `ClientBootstrap` does the equivalent for clients. The documentation is specific about the accept side: SO_REUSEPORT is supported automatically when there is more than one accept thread, and the default configuration is a single accept thread with one IO thread per core. The method surface is small and worth knowing by name. `childPipeline` takes a pipeline factory and creates one pipeline per new connection. `group` sets the accept and IO thread pools. `bind` takes a socket address or a bare port and starts accepting immediately after binding. `stop` closes all listening sockets, and `join` blocks until all thread pools finish their current reads and writes. There is a documented sharp edge in `join`. The documentation notes that both the accept and IO pools are stopped by that call, so the pools cannot be shared, or shared pools need careful handling during shutdown. That is exactly the kind of detail that turns into a production incident if you have not read it, and it is a fair summary of what owning your own thread pools costs. UDP is supported through `channelFactory`, which defaults to a TCP async server socket and can be set to an async UDP server socket. The documentation is candid that ServerBootstrap is only worth it for UDP if you need to multiplex messages across many threads or have TCP connections running at the same time. ## Pipelines and the accept-time hook The pipeline is the series of handlers that modify socket data, and there are two places to install one. `childPipeline` configures the per connection pipeline. There is also an accept-level `pipeline` method that runs on the accepted socket before it is handed to an IO thread, which the documentation points at for steering a connection to a particular thread or for logging before the handoff. For that steering problem, the documentation names two specific handlers: `AcceptRoutingHandler` and `RoutingDataHandler`, described as additional help for reading data off the accepted socket before it is attached to an IO thread, and as usable to hash incoming sockets to specific threads. That is the mechanism for consistent hashing of a connection to a thread, which you would otherwise write yourself. There is a third path for compatibility. `childHandler` takes an `AcceptorFactory` and exists because Facebook had a lot of existing code using acceptor factories rather than pipelines, so this method keeps that code working. The acceptor factory is responsible for creating acceptors, setting up pipelines, and wiring async socket read callbacks. The layering is worth internalising: an accept pipeline can act on a connection before any per connection pipeline exists, which is the point at which connection-level routing decisions are still cheap to make. ## Service, ServiceFilter and the client factory stack The request and response abstraction is the Finagle half of the project, and the documentation compares it to Finagle directly. The aim is stated as easy testing, load balancing, client pooling and retry logic for any request and response service, thrift or http for instance. Whether it delivers all four is a separate question, since the README names them as goals rather than documenting their mechanics. Four types carry that abstraction. A `Service` is the matched interface between client and server: the server implements it, the client calls into it, and it is protocol specific. A `ServiceFilter` is a generic filter on a service, with stats, request timeouts and rate limiting given as examples. A `ServiceFactory` creates client connections and is where protocol specific setup code goes. A `ServiceFactoryFilter` filters how connections get created, with load balancing, pooling, idle timeouts and markdowns named as client side examples. The split between the factory and the factory filter is the part that pays off in production. Connection policy, the things you want to apply uniformly to every client in a service, lives in `ServiceFactoryFilter`, while protocol wiring stays in the factory itself. Stats and timeouts attach to the service layer, above the connection layer, so they compose with whatever the factory does. Markdowns are worth a second look. Having a filter that can take a portion of a client fleet out of rotation without a deploy is a resilience feature, and it is the sort of thing that tends to be reinvented badly in each service until a framework provides it. ## Weekly tags, Apache 2.0, and a tutorial instead of API docs The maintenance picture looks healthy from the outside. The repository is not archived and the last push was on 2026-09-23, and the release tags follow a date based scheme with a weekly cadence: v2026.09.21.00, v2026.09.14.00 and v2026.09.07.00 all appear as releases, and their notes are generated automatically by a tool called TagIt, including SHA-256 and SHA-512 hashes of the published zip. That regularity is a good sign for a library whose whole job is to stay in step with folly and fizz. Documentation is the weaker part. The README describes the API in prose with method lists rather than generated reference pages, and it points to a `tutorial.md` at the repository root that explains the basics and builds an echo server and client. It also points to an `examples/` directory of example servers and clients. The bootstraps and filters are documented in enough detail to be useful, but load balancing, pooling, idle timeouts and markdowns are listed as capabilities without a spec, so expect to read the source for those. One inconsistency is worth flagging so you do not chase the wrong build: the README still leads with a Travis build badge from the `master` branch while also carrying a GitHub Actions CI badge. The Actions badge is the one attached to the repository you would actually build from. The licence is Apache 2.0, which is the permissive choice you would expect for a library meant to be adopted inside other companies' server code. ## Conclusion Wangle makes sense inside an organisation already on folly and fizz, where the client and server abstraction, the pipeline model and the filter stack save you from rebuilding service plumbing per protocol. Outside that context it is a heavy proposition, since folly and fizz are substantial dependencies to adopt for a networking layer, and a single protocol service may find boost::asio or a thinner library a better trade. The README covers bootstraps and filters well and leaves load balancing, pooling and retry behaviour as named features rather than specified mechanics, so read `tutorial.md` and the `examples/` directory before committing. Build with `cmake .`, `make`, `ctest`, and expect the CI badge on GitHub rather than the Travis badge still shown at the top of the README. ## FAQ ### What is the Wangle C++ library used for? Wangle is used to build protocols, application clients and application servers in C++. It provides both the server side pieces familiar from Netty, such as ServerBootstrap and pipelines, and the client side pieces familiar from Finagle, such as Service, ServiceFactory and their filters. ### How do you build and install Wangle? Install folly first, then run `cmake .`, `make`, `ctest` and `sudo make install` from the wangle directory. The main dependencies are folly, fizz, CMake, and OpenSSL 1.0.2 or newer with TLS extension support preferred. ### What is the difference between Wangle and Finagle? They cover the same request and response territory, but in different languages. The README describes Wangle as Finagle and Netty combined in C++, so the client and server abstractions that Finagle provides in Scala are paired here with Netty's server bootstrap and pipeline model. ### What does ServerBootstrap do in Wangle? It sets up the accept and IO thread pools for a server and builds a pipeline per accepted connection. SO_REUSEPORT is used automatically with multiple accept threads, the default is one accept thread and one IO thread per core, and TCP is the default with UDP available through `channelFactory`. ### What licence is Wangle released under? Wangle is Apache 2.0 licensed, as the README and the LICENSE file at the repository root both state. ## Sources - [facebook/wangle on GitHub](https://github.com/facebook/wangle) - [Issues](https://github.com/facebook/wangle/issues) - [License: Apache-2.0](https://github.com/facebook/wangle/blob/main/LICENSE) - [README](https://github.com/facebook/wangle/blob/main/README.md) - [Releases](https://github.com/facebook/wangle/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/facebook-wangle