Repository navigation
Firebolt CPP 2.0 Transport
The Firebolt Transport layer abstracts communication between the Firebolt Client and the Firebolt runtime.
Rather than coupling Firebolt APIs to a specific transport implementation, Firebolt CPP 2.0 introduces an explicit transport contract through IFireboltTransport.
This allows applications to:
- Use the default Firebolt transport implementation
- Integrate with an existing transport stack
- Substitute transport implementations for testing
- Reuse generated Firebolt APIs independent of transport choice
The Transport layer is responsible only for moving messages between the Firebolt Client and the Firebolt runtime.
It has no knowledge of:
- Firebolt APIs
- Firebolt Models
- Request types
- Response types
- Transport abstraction
- Explicit ownership
- Dependency injection
- Multiple transport implementations
- Runtime configurability
- Framework independence
+----------------------+
| Firebolt Client |
+----------+-----------+
|
v
+----------------------+
| IFireboltTransport |
+----------+-----------+
|
|
+------+------+
| |
v v
+-----------+ +-----------+
| Default | | Custom |
| Transport | | Transport |
+-----------+ +-----------+
The Firebolt Client depends only on IFireboltTransport.
It does not know whether requests are transported using:
- WebSocket
- Thunder
- Local IPC
- Test implementation
- Future transport mechanisms
At its core, the transport layer provides a simple mechanism for sending requests and receiving responses.
The transport exposes:
- Connection lifecycle
- Request transmission
- Callback registration
- Notification delivery
while remaining completely independent of Firebolt APIs and generated models.
The Transport layer is responsible for:
- Communication
- Connectivity
- Request delivery
- Response delivery
- Event delivery
The Transport layer is not responsible for:
- JSON-RPC correlation
- Request serialization
- Response deserialization
- Typed callbacks
- Firebolt API execution
These responsibilities belong to FireboltClient.
Firebolt CPP 2.0 provides a default transport implementation.
App
│
▼
FireboltClient
│
▼
FireboltDefaultTransport
│
▼
WebSocket
│
▼
App Gateway
This implementation provides:
- WebSocket connectivity
- JSON-RPC transport
- Connection management
Most applications will use this implementation directly.
Applications that already own a communication stack may provide their own transport implementation.
App
│
▼
FireboltClient
│
▼
CustomTransport
│
▼
Existing Runtime Infrastructure
Examples include:
- Existing Thunder integrations
- Existing WebSocket infrastructure
- Test doubles and mocks
- Specialized platform transports
Transport implementations are selected at runtime.
Unlike Firebolt Models, which are generated and known at compile time, transport implementations are application-defined.
As a result, runtime polymorphism is appropriate.
class IFireboltTransport
{
public:
virtual ~IFireboltTransport() = default;
virtual bool open(
const std::string& url,
const std::map<std::string, std::string>& context) = 0;
virtual bool isConnected() = 0;
virtual void onConnectionStatusChanged(
std::function<void(bool connected,
const std::string& errorInfo)> callback) = 0;
virtual bool send(
const std::string& message) = 0;
virtual void onMessageReceived(
std::function<void(const std::string& message)> callback) = 0;
virtual void disconnect() = 0;
};
This allows FireboltClient to depend only on an abstraction while applications decide which transport implementation to provide.
Transport ownership becomes visible within application code.
Transport implementations can be supplied externally.
Unit tests can provide lightweight transport implementations.
Multiple transport implementations can coexist.
The transport layer focuses exclusively on moving messages.
Firebolt API execution and model conversion remain within FireboltClient.