Sogou C++ Workflow puts disk IO, compute and network tasks in one flow

Port 8888 and a lambda: the shortest useful server in the README

The first example in this project builds an HTTP server in about twenty lines, and every line of it tells you something about the design. The callback receives a WFHttpTask pointer, writes an HTML string into the response body, and returns. The server is started on port 8888 and then held open by getchar(), so pressing Enter stops it.

#include <stdio.h>
#include "workflow/WFHttpServer.h"

int main()
{
    WFHttpServer server([](WFHttpTask *task) {
        task->get_resp()->append_output_body("<html>Hello World!</html>");
    });

    if (server.start(8888) == 0) { // start server on port 8888
        getchar(); // press "Enter" to end.
        server.stop();
    }

    return 0;
}

Notice what is absent. There is no routing table, no configuration object and no thread count in this snippet. The task pointer is the only handle you get, and it carries the request in and the response out.

Disk IO is a task, so file reads share a queue with network calls

The claim that shapes everything else is that a file read is a task. On Linux, disk file IO joins the same scheduling machinery as HTTP requests, Redis commands and CPU work, which means a flow can block on a file and then continue to the network without anyone writing a thread handoff.

Alongside that, the project offers series and parallel structures plus DAG structures, and it places computing tasks in the same flow. Compute is defined symmetrically with protocol: if a protocol call is an rpc, an algorithm call is an apc, an Async Procedure Call. The stated formula is Program = Protocol + Algorithm + Workflow, and a built-in algorithm factory and user-defined computing tasks are documented as separate tutorial topics.

The tutorial index is a fair warning about where the difficulty lives: there are dedicated pages on error handling, timeouts, global configuration, DNS and exit behaviour. A DAG where one node fails and the rest are already queued is the case to read up on before you build it.

Kafka is the one client that drags extra libraries into your build

Four protocol clients ship in the box: HTTP, Redis, MySQL and Kafka. The MySQL client also speaks to MariaDB and TiDB, so a single client covers three database engines. Separate tutorials exist for the asynchronous MySQL and Kafka clients, and both are framed as cli tools built on the framework.

The dependency story is stated plainly and it has an exception. The project claims no other dependencies and no reliance on boost or asio, which is true of the core. If you use the Kafka protocol, the README says compression libraries should be installed, naming lz4, zstd and snappy. That sentence matters more than it looks. A team that standardises on this framework still has to get all three compression libraries into its build. A base image built for the HTTP server alone will not run the Kafka client as it stands.

Kafka also arrives as a first-class citizen rather than an extension, so it gets the same task type as everything else and participates in the same series, parallel and DAG structures. That is the appeal, and it is also why the three compression libraries are a hard dependency rather than an optional extra.

Windows lives on its own branch and swaps epoll for iocp

Windows support is real and it is separate. The Windows version is released as an independent branch that implements asynchronous networking with iocp, and the project states that all user interfaces are consistent with the Linux version so that code written on one runs on the other.

Consistent interfaces do not mean a consistent branch. Anyone building for Windows checks out the windows branch, and anyone building for Linux checks out master, which means your Windows CI and your Linux CI are compiling different commits of the same codebase until the branches converge. If your team spans both operating systems, that is a permanent tax on release engineering rather than a one-time setup cost, and nothing in the README describes how often the two branches are merged.

CPU coverage is broader than the platform story suggests. Beyond Linux, macOS, Windows and Android, the project claims support for 32-bit and 64-bit x86, big-endian and little-endian arm, and loongson processors. Portability is a design goal, but portability to a processor is not the same as portability to a Windows developer.

SSL is in master, and the nossl branch is a fork you now own

Master requires OpenSSL 1.1 or later, and BoringSSL is stated to be fully compatible. If your build has no business talking TLS, the answer is not a configuration flag. You check out the nossl branch instead, and from that moment your copy of the framework is your copy of the framework.

That branch is a long-term divergence for a project whose recent history is fast. Recent releases are v1.0.1 on 2026-06-24, v1.1.0 on 2026-08-10 and v1.1.1 on 2026-10-22. Backporting a fix from master into a nossl tree by hand is work nobody has budgeted for, and it is work that only shows up when something breaks in production.

The language floor is the other half of this. The project uses the C++11 standard and asks for a compiler that supports C++11. A codebase that has moved to C++17 or C++20 can still call into it, but the framework itself will not be offering new language features, and you should not expect its internal idioms to match the ones in your own code.

libworkflow-dev and libworkflow1: two package names per distribution

There is a packaged route for Debian and Ubuntu, and a separate one for Fedora. Each distribution splits the library into a development package with headers and a runtime package without, and picking the wrong one leaves you compiling against headers that are not installed.

sudo apt-get install libworkflow-dev

sudo apt-get install libworkflow1

sudo dnf install workflow-devel

sudo dnf install workflow

The packaging is stated for Debian Linux and Ubuntu 22.04 on one side and Fedora on the other. For everything else, the project builds from source:

git clone https://github.com/sogou/workflow
cd workflow
make
cd tutorial
make

That last pair of commands builds the framework and then the tutorial programs, which is how you get the example clients the tutorial pages refer to. An xmake route also exists and is documented separately.

srpc sits on top and owns the protocol vocabulary

The framework lets you write a client and a server for a protocol you define, supplying your own serialization and deserialization, which is enough to build an RPC system from scratch. Almost nobody starts there. The project points at srpc, an independent open-source project built on this framework, and srpc supports the srpc, brpc, trpc and thrift protocols.

The split is worth being precise about. This repository gives you tasks, series, parallel and DAG flows, computing tasks, file IO tasks, resource pools, counters and service governance with load balancing. For the srpc, brpc, trpc and thrift protocols you go to srpc, and the documentation structure reflects that split: the PaaS Architecture material lives in the wiki, and the service governance and upstream pages are documentation topics rather than a compiler plugin.

The practical consequence is a two-project dependency. Teams that adopt srpc track this repository's releases and srpc's releases separately, and they should check which version of the framework srpc was built against before assuming a version bump is transparent.

Apache-2.0 is declared, but the root also carries LICENSE_GPLV2

The repository is declared Apache-2.0, and the root directory contains both a LICENSE file and a LICENSE_GPLV2 file alongside CODE_OF_CONDUCT.md. Two licence-named files in one root is not something to resolve by guesswork. Read the text in each file, or ask the maintainers which terms apply to which component, before the framework ends up in something you distribute.

On the maintenance side, the numbers are recent rather than alarming. The last push was on 2026-10-30, after v1.1.1 was tagged on 2026-10-22, and v1.1.0 and v1.0.1 came earlier in 2026. That cadence suits a framework carrying its own server engine, and it also means upgrades arrive often enough that a pinned version in your build definition is worth having.

One more detail to check before you commit. The root holds a GNUmakefile, a CMakeLists.txt, a workflow-config.cmake.in file, xmake.lua, and separate BUILD and WORKSPACE files, so there are several build descriptions to choose from and the quick start uses make, with xmake documented separately.

Editorial conclusion

Sogou C++ Workflow fits teams writing a single back-end service in C++ who want one scheduling model for HTTP, Redis, MySQL, Kafka and file reads instead of stitching a thread pool onto an event loop. It fits less well if you need a build without OpenSSL or Windows and Linux developers on the same branch, since both mean tracking a separate branch. Before adopting, check three things: the license text in the root LICENSE file rather than the file name, whether the Kafka client pulls lz4, zstd and snappy into your build, and whether your team is willing to track the windows and nossl branches separately from master.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. sogou/workflow on GitHub