Bidirectional service-to-edge cloud-native gateway for long-lived connection.
See the code
Bidirectional service-to-edge gateway for long-lived connections
Frontier is an open-source gateway written in Go for service <-> edge communication. It lets backend services and edge nodes talk to each other over long-lived connections, with built-in bidirectional RPC, messaging, and point-to-point streams.
It is built for systems where both sides stay online and need to actively call, notify, or open streams to each other. Frontier is not a reverse proxy and not just a message broker. It is infrastructure for addressing and operating large fleets of connected edge nodes from backend services.
Traffic relay and media streaming |
Remote agents and device fleets |
| You need to... | Frontier gives you... |
|---|---|
| Call a specific online device or agent from your backend | Service -> Edge RPC and messaging over long-lived connections |
| Let edge nodes initiate calls without opening inbound ports | Edge -> Service RPC on the same connection model |
| Move bytes, not just request/response payloads | Point-to-point streams between service and edge |
| Run one control plane for a large connected fleet | Presence, lifecycle hooks, control APIs, clustering |
Most infrastructure is optimized for one of these models:
Frontier is optimized for a different model:
Use Frontier if you need:
Do not use Frontier if:
| Scenario | Why Frontier fits |
|---|---|
| Device control plane | Address a specific online edge node, push commands, receive state, and keep the link alive |
| Remote connector platform | Let connectors dial out, avoid inbound exposure, and keep service-side routing simple |
| Real-time apps | Maintain long-lived sessions and combine notifications, RPC, and streams in one path |
| Internal zero-trust access | Use agent-style edges as the last-mile bridge between backend systems and private resources |
| Capability | Frontier | gRPC | NATS | frp | Envoy |
|---|---|---|---|---|---|
| Built for service <-> edge communication | Yes | No | Partial | No | No |
| Backend can address a specific online edge node | Yes | No | Partial | Partial | No |
| Edge can call backend services | Yes | Partial | Yes | No | No |
| Point-to-point streams between service and edge | Yes | Partial | No | Tunnel only | No |
| Unified RPC + messaging + streams model | Yes | No | No | No | No |
| Long-lived connection fleet as a primary model | Yes | No | Partial | Partial | No |
Partial here means the capability can be assembled with extra patterns, but it is not the system's primary communication model.
docker run -d --name frontier -p 30011:30011 -p 30012:30012 singchia/frontier:1.2.2
make examples
# Terminal 1
./bin/chatroom_service
# Terminal 2
./bin/chatroom_agent
The chatroom example shows the basic Frontier interaction model: long-lived connectivity, edge online/offline events, and service <-> edge messaging.
You can also run the RTMP example if you want to see Frontier's stream model used for traffic relay:
# Terminal 1
./bin/rtmp_service
# Terminal 2
./bin/rtmp_edge
Demo video:
https://github.com/singchia/frontier/assets/15531166/18b01d96-e30b-450f-9610-917d65259c30
README is intentionally optimized for fast understanding and fast conversion. The implementation details, configuration surface, deployment playbooks, and cluster operations live in the docs.
Start here:
If you are evaluating Frontier for production, the docs cover:
Join our WeChat group for discussions and support.
Released under the Apache License 2.0
A Star ⭐️ would be greatly appreciated ♥️
Bidirectional service-to-edge cloud-native gateway for long-lived connection.
See the code
Bidirectional service-to-edge gateway for long-lived connections
Frontier is an open-source gateway written in Go for service <-> edge communication. It lets backend services and edge nodes talk to each other over long-lived connections, with built-in bidirectional RPC, messaging, and point-to-point streams.
It is built for systems where both sides stay online and need to actively call, notify, or open streams to each other. Frontier is not a reverse proxy and not just a message broker. It is infrastructure for addressing and operating large fleets of connected edge nodes from backend services.
|
Traffic relay and media streaming |
Remote agents and device fleets |
| You need to... | Frontier gives you... |
|---|---|
| Call a specific online device or agent from your backend | Service -> Edge RPC and messaging over long-lived connections |
| Let edge nodes initiate calls without opening inbound ports | Edge -> Service RPC on the same connection model |
| Move bytes, not just request/response payloads | Point-to-point streams between service and edge |
| Run one control plane for a large connected fleet | Presence, lifecycle hooks, control APIs, clustering |
Most infrastructure is optimized for one of these models:
Frontier is optimized for a different model:
Use Frontier if you need:
Do not use Frontier if:
| Scenario | Why Frontier fits |
|---|---|
| Device control plane | Address a specific online edge node, push commands, receive state, and keep the link alive |
| Remote connector platform | Let connectors dial out, avoid inbound exposure, and keep service-side routing simple |
| Real-time apps | Maintain long-lived sessions and combine notifications, RPC, and streams in one path |
| Internal zero-trust access | Use agent-style edges as the last-mile bridge between backend systems and private resources |
| Capability | Frontier | gRPC | NATS | frp | Envoy |
|---|---|---|---|---|---|
| Built for service <-> edge communication | Yes | No | Partial | No | No |
| Backend can address a specific online edge node | Yes | No | Partial | Partial | No |
| Edge can call backend services | Yes | Partial | Yes | No | No |
| Point-to-point streams between service and edge | Yes | Partial | No | Tunnel only | No |
| Unified RPC + messaging + streams model | Yes | No | No | No | No |
| Long-lived connection fleet as a primary model | Yes | No | Partial | Partial | No |
Partial here means the capability can be assembled with extra patterns, but it is not the system's primary communication model.
docker run -d --name frontier -p 30011:30011 -p 30012:30012 singchia/frontier:1.2.2
make examples
# Terminal 1
./bin/chatroom_service
# Terminal 2
./bin/chatroom_agent
The chatroom example shows the basic Frontier interaction model: long-lived connectivity, edge online/offline events, and service <-> edge messaging.
You can also run the RTMP example if you want to see Frontier's stream model used for traffic relay:
# Terminal 1
./bin/rtmp_service
# Terminal 2
./bin/rtmp_edge
Demo video:
https://github.com/singchia/frontier/assets/15531166/18b01d96-e30b-450f-9610-917d65259c30
README is intentionally optimized for fast understanding and fast conversion. The implementation details, configuration surface, deployment playbooks, and cluster operations live in the docs.
Start here:
If you are evaluating Frontier for production, the docs cover:
Join our WeChat group for discussions and support.
Released under the Apache License 2.0
A Star ⭐️ would be greatly appreciated ♥️