Horizon wraps RethinkDB in four services and one CLI

Four services, one middleware server, and a CLI named hz

Horizon is RethinkDB's answer to a specific complaint: that building realtime applications means manually orchestrating several systems across the stack, learning distributed stream processing, and then learning how to deploy and scale the result. The README calls that learning curve steep and says most of the early work is boilerplate far removed from the actual task. Horizon's response is to sit between a browser and a RethinkDB instance so a front-end developer can subscribe to data with no backend code at all.

It ships as four parts. The Horizon server is a middleware server built on RethinkDB that exposes a simple API and protocol to front-end applications. The client library is JavaScript and wraps that server protocol in a friendlier shape for the browser. The CLI is named hz and handles scaffolding, development and deployment. The fourth part is GraphQL support, and that is where the promises start fraying.

Subscribe is the only service that does the realtime work

Of the services marked available, Subscribe is the one that carries the project's reason for existing. It is a streaming API for building realtime apps straight from the browser with no backend code written by the developer. The other three are ordinary backend concerns that Horizon bundles in.

Auth is an authentication API that connects to common auth providers, with Facebook, Google and GitHub named as examples. Identity is an API for listing and manipulating user accounts, which is what lets you have a real user model without a session layer of your own. Permissions is described as a security model that protects data from unauthorized access, and it is the piece that decides whether subscribing to a collection is safe.

That division is worth noting. Horizon did not invent realtime delivery; RethinkDB and WebSocket did. What Horizon contributes is a permission check in front of the stream and a user table behind it, which is the part most projects end up writing badly.

The audience is narrow and stated in the README's own framing: a developer who wants to start in their favourite front-end framework and write no backend code, on the assumption that adding business logic later will be incremental. That assumption holds because the data already lives in RethinkDB, so moving logic server-side is a change of where the query runs rather than a migration between two databases. It stops holding the moment you need sessions, geolocation or presence, since none of those three are in the shipped set.

The GraphQL adapter is an issue number, not a feature

The fourth component is listed as GraphQL support, and the entire description is a link to issue 125 plus an intention. The text says the server will have a GraphQL adapter so that anyone can get started building React and Relay apps without writing backend code, then states that this will not ship in v1 and that the team will follow up with an adapter quickly after launch.

The only release recorded is v1.1.3, published 2016-06-15, a v1 release. So the promise to ship the adapter after v1 has had a decade to land and the repository still points at the issue rather than at a directory. For anyone starting a React or Relay project against Horizon today, the component they were promised is the one they do not get, and the surrounding services are the substitute.

That is not an accusation so much as a scheduling fact, and it is the single most useful thing to know before choosing this project.

Session management, presence and plugins never moved off the roadmap

A second block of services is listed as future work: session management for browser sessions, geolocation for location-aware apps, presence for detecting and sharing whether a user is online, a plugins system for user-defined services, and a Backend API that would let custom code integrate with the server and client libraries.

Session management is the gap that matters most in practice. Identity gives you user accounts and Permissions gives you access control, but holding a browser session across requests is exactly the piece that goes unmentioned in the shipped set. The Backend API is the second one that shapes architecture, because it is the escape hatch that lets a project start with no backend code and add business logic later, which is the migration story Horizon advertises.

So the pitch is real, incremental: start in the browser, move logic server-side as the app grows. What the shipped set does not include is the session layer the migration path quietly assumes.

hz serve binds all and reads RETHINKDB_URI at container start

Running the server is one command, and the container image states exactly what it expects. The whole invocation, taken from the image definition, is:

hz serve --bind all --connect $RETHINKDB_URI /usr/app

Two things fall out of that line. The flag `--bind all` means the API is not restricted to loopback, so the port is reachable from anywhere the container network allows. And the database connection is not baked in; it comes from an environment variable read at start time. The image comments spell out the two runtime inputs the container needs, a database address and a mount for your app code:

docker run -e RETHINKDB_URI=HOST:PORT -v /path/to/app:/usr/app

The image exposes port 8181 and declares `/usr/app` as a volume. The base image is node:5-slim, which dates the runtime assumptions more clearly than any prose does.

The examples directory is the closest thing to API documentation

There is no documentation site in the repository listing. What there is, at the top level, is GETTING-STARTED.md, a protocol.md describing the wire protocol, a rfcs directory, and an examples directory holding eleven applications.

The examples are the interesting part because they span the framework landscape of the period: angularjs-todo-app, react-todo-app, vue-todo-app, and chat equivalents in React, Vue, Cycle and Riot. Alongside them sit auth-app plus three server integrations, express-server, hapi-server and koa-server. That spread tells you two practical things. First, a working Horizon client has existed for each of those frameworks. Second, the same era is visible in the framework list itself, which is a date stamp on the project.

Two compose files exist for local work, docker-compose.dev.yml and docker-compose.prod.yml, with a separate Dockerfile.dev, so there is a dev and a prod path in the tree. Their contents are not described anywhere in the documentation, so treat them as something to read rather than something to trust on sight.

Commits continue on next while the last release dates to 2016

The repository is not archived and the last push landed on 2026-10-10, so work is still landing on the default branch, which is named next rather than master or main. Against that, the release list holds exactly one entry, v1.1.3 from 2016-06-15. Those two facts sit awkwardly together: a decade of commits with no versioned release to point at.

The licence metadata is MIT, and the README's own licensing answer names the server, client and cli as the MIT parts, which is a narrower list than the four advertised components. Day to day tooling reflects an older stack too, with circle.yml for continuous integration, an .eslintrc.js for linting, and a Python script named update_versions.py sitting in a JavaScript repository for version bookkeeping.

For an adopter this splits cleanly. Reading the code and running it locally is cheap. Depending on published releases for a production upgrade path is not.

There is a companion signal in the repository listing worth noting for anyone evaluating support: a CONTRIBUTING.md and an ISSUE_TEMPLATE.md sit at the top level, so contributions were an expected path rather than an afterthought. Neither tells you how fast issues are answered, and the README routes questions to a Slack channel and a Twitter account instead of naming a response time.

Editorial conclusion

Horizon suits a team that wants subscribe plus a user model without writing backend code, and only if you are content to own the deployment and accept a 2016 release train. It does not suit a new GraphQL or React Relay project, since the adapter for that was never built. Before adopting, read protocol.md, then run hz serve yourself against your own RETHINKDB_URI to see whether the streaming layer behaves under your load.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rethinkdb/horizon on GitHub