Resgate puts a realtime gateway in front of NATS microservices

A gateway that clients talk to instead of services

Resgate is a Go project implementing a realtime API gateway for the RES protocol with NATS server as the messaging system. The README describes it as a simple server that lets you create REST, real time, and RPC APIs, where all your clients are synchronized.

The arrangement it replaces is worth drawing out. Normally a client talks to each microservice it needs, over HTTP for reads and over WebSockets for live updates, and the service that owns the data has to work out how to tell everyone that the data changed. With Resgate, clients connect to Resgate instead, over HTTP or WebSocket, and Resgate talks to the microservices over NATS.

That inversion is what removes most of the work. The services behind the gateway become request handlers and event publishers rather than API designers, and the gateway owns the concerns that are the same for every service: routing, subscription bookkeeping, caching and change notification.

The intended audience is stated as building new REST APIs with real-time functionality, or creating single page applications using reactive frameworks such as React, Vue.js, or Modapp. The repository topics match, with api-gateway, microservices, microservices-architecture, nats-server and realtime among them. The licence is MIT and the homepage is resgate.io, which carries guides, live demos and a resources page.

How a request and a change event flow through it

The mechanism is described in the How it works section of the README, and it has two halves.

On the request side, Resgate handles all API requests from your clients instead of directly exposing the microservices. Requests are sent to the micro-services over NATS server, and Resgate keeps track of which resource each client has requested.

On the change side, whenever there is a change to the data, the responsible micro-service sends an event. Resgate uses that event to update its own cache and to make sure each subscribing client is kept up-to-date.

So a subscription is not just a read. When a client asks for a resource, Resgate caches it and notes that the client wants it. Later, when a service announces that the resource changed, the gateway has both the new value and the list of interested clients, and can push to exactly those. That is the part a hand written polling endpoint has to rebuild badly.

The repository layout matches that structure, with a nats directory for the messaging side, a server directory for the HTTP and WebSocket handling, a logger directory and main.go at the root. The go.mod pins the messaging client to github.com/nats-io/nats.go and the WebSocket implementation to github.com/gorilla/websocket, with github.com/jirenius/timerqueue, github.com/rs/xid and github.com/bsm/openmetrics alongside them.

Running it with Docker in three commands

The quickstart assumes you have Docker installed, and it brings up both NATS and Resgate as containers on a shared network so they can find each other.

docker network create res
docker run -d --name nats -p 4222:4222 --net res nats
docker run --name resgate -p 8080:8080 --net res resgateio/resgate --nats nats://nats:4222

The first command creates a Docker network named res. The second starts NATS in the background with its client port published on 4222. The third starts Resgate on the same network with port 8080 published and points it at the NATS container by its container name, nats://nats:4222.

The README notes that both images are small, about 10 MB each, which is a fair description of the footprint compared with a typical API gateway that pulls in a service mesh and a proxy.

Other installation routes, including running the binary directly, are covered at resgate.io/docs/get-started/installation/.

Building from the Dockerfile in the repository is equally short. The image is based on golang, sets GO111MODULE=on, copies the source into /src/resgate, builds a static binary with CGO_ENABLED=0 go build -v -ldflags "-s -w" -o /resgate, exposes port 8080 and runs /resgate as the entrypoint. The go.mod targets Go 1.20.

Server options and what the defaults hide

The option table is where the interesting behaviour lives, because several defaults are conservative and one is easy to miss.

The basics are -n, --nats for the NATS server URL defaulting to nats://127.0.0.1:4222, -i, --addr for the bind address defaulting to 0.0.0.0, -p, --port for the HTTP port defaulting to 8080, and -w, --wspath for the WebSocket path defaulting to /. The web resource path is set with -a, --apipath and defaults to /api/.

The one to look at twice is -r, --reqtimeout, which sets the timeout duration for NATS requests and defaults to 3000 seconds. That is a long ceiling by default, which means a service that never answers a request can hold a client connection open for a very long time unless you lower it.

Two throttle flags exist for protecting the gateway from a storm of parallel requests: --resetthrottle limits parallel requests sent on a system reset, and --referencethrottle limits parallel requests sent following references. Both default to 0, which the README marks as no limit, so by default there is no cap on either.

There is also -m, --metricsport for OpenMetrics connections, disabled by default with a value of 0, and -c, --config for a configuration file in JSON format, which is the practical way to set all of this in a deployment rather than through a long command line.

TLS, NATS credentials and the client-facing surface

The security options are separate from the server options and cover two different hops.

For the HTTP side there is --tls to enable TLS for HTTP, defaulting to false, together with --tlscert for the HTTP server certificate file and --tlskey for the private key. So the gateway terminates TLS itself, and by default it does not.

For the NATS side there is --creds for a NATS User Credentials file, plus further options in the same table for NATS certificates and authentication. That is the connection from the gateway to the message bus, and it is where the credentials that matter operationally live: the gateway needs to be trusted by NATS, and separately the services it talks to need to be trusted by it.

On the client-facing side there is -u, --headauth for the resource method used for header authentication, and -t, --wsheadauth for the equivalent on WebSocket connections. These point at methods on your services, so authentication is handled by the service that owns the user data rather than by the gateway, which is why the jwt-authentication and password-authentication examples exist in the repository.

There are also method mappings for HTTP verbs: --putmethod, --deletemethod and --patchmethod name the service methods called for PUT, DELETE and PATCH requests respectively, and --apiencoding chooses between json and jsonflat for web resources, defaulting to json. The --wscompression flag enables WebSocket per message compression.

The examples are the documentation

The examples directory is the part of the repository that teaches fastest, and each entry is a complete service and client pair rather than a fragment.

The list is short and each one covers a different problem. Hello World is a simple service serving a static message. Edit Text is a text field that can be edited by multiple clients concurrently, which is the case that breaks naive implementations. Book Collection is a list of book titles and authors that can be edited by many, and there is a screen capture of it in the README. JWT Authentication shows how JWT tokens can be used for authentication, and Password Authentication shows authentication with user and password credentials. Client Session creates client sessions that survive reloads and reconnects.

The examples are written in JavaScript for Node.js without any additional library, and the README is explicit that Resgate itself may be used with any language. For other stacks the README points at separate client and service packages, the go-res package for Go and the RES Service for .NET for C#.

That separation is worth understanding: the protocol is the contract, and the client libraries are convenience. If the existing ResClient does not fit, the RES-Client protocol document covers how to write your own, and the RES-Service protocol document covers the service side.

Where the project stands, and what to check before adopting it

The repository is not archived and the last push was on 2026-05-11, so the code is being worked on. The release tags tell a different story about cadence, with v1.8.0 dated 2024-07-03, v1.7.5 from 2022-01-06 and v1.7.4 from 2021-11-12. The repository does carry a go.sum and a test directory, and the CI badges point to a build workflow, a Go Report Card and a Coveralls coverage badge.

That gap between a recent commit and an old release tag is the thing to weigh. If you are evaluating this for production, the distinction between the master branch and the latest tagged release is a real question, and the CHANGELOG and the documentation site are where the answer lives.

The other thing to check is the NATS dependency. The gateway and the services must agree on subject naming and message format, which the RES-Service protocol document defines. That document is the integration contract, and reading it before writing a service is the difference between a short afternoon and a debugging session.

There is also the option of writing against the protocol yourself. The RES protocol, RES-Service protocol and RES-Client protocol documents are all in the docs directory, and the ResClient client library is a separate project, so the gateway is usable without adopting anything else in the ecosystem.

Editorial conclusion

Resgate suits a team with several microservices behind NATS that wants one address for REST, WebSocket and RPC without writing the subscription, cache and change notification logic for each service, since the gateway handles all three and the RES protocol is documented in the repository. It is the wrong tool if you have a single service, because the gateway then adds a hop and a protocol to learn for no gain, and it is the wrong tool if you are not already on NATS. Before adopting it, read the RES protocol and RES-Service protocol documents in docs/, run the hello-world example in the repository to see a complete service and client pair, and check that your services can publish change events on the NATS subjects the protocol expects.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. resgateio/resgate on GitHub