This document illustrates how to use the nodeJS client library to communicate with a Volt via grpc.
Two packages are required by nodeJS tdx Volt clients, @tdxvolt/volt-client-grpc and @grpc/grpc-js.
To install the @tdxvolt/volt-client-grpc and @grpc/grpc-js packages:
In order to be able to initialise a connection to a Volt, you will need to obtain a client configuration.
How your web application obtains or stores the client configuration is not discussed here, needless to say you need to be careful not to expose keys or other sensitive data. For the purposes of this document, we assume Bob's configuration is stored in a local file.
Example client connection object, obtained from the fusebox identity dialog:
Begin by creating a tdx Volt client instance:
Initialise the tdx Volt instance to enable Bob to connect to the Volt:
Once initialised successfully, you can issue any API call. In the example below, we retrieve the immediate descendants of the Volt root resource:
Refer to the API documentation for details of the method names and corresponding request and response messages. Each API method expects a JSON object representing the request as input, and returns a JSON object as indicated by the response message type. The JSON representation of the protobuf message format is intuitive.
If you see deprecation warnings along the lines of `Setting the TLS ServerName to an IP address is not permitted by RFC 6066` you can safely ignore them for the time being. See also this github issue.
All unary calls return a promise that will either resolve with a JSON response object matching that defined by the API protobuf, or reject if there is a problem with the grpc transport or an error status on the response object.
The promise model does not fit well with streaming calls since they are long-lived.
For this reason, all streaming calls (client streaming, server streaming, and bi-directional streaming) return a call object that is used to manage the call.
The call object emits events as interactions with the underlying websocket occur, and there are 3 events of interest:
“error” emitted when an error occurs on the call
“data” emitted when a response is received from the Volt
“end” emitted when the call ends
Server streaming calls
The example below shows execution of an SQL statement on a database, the data event will be emitted for each row of data in the result set.
The end event is emitted when the call ends.
Client streaming calls
Client streaming calls have a similar syntax to server streaming calls, although the data event should only be emitted once rather than multiple times.
Clients can use the send method on the returned call object to send requests to the server (see bi-direction example below).
Clients use the end method of the returned call object to indicate to the server that the call has ended.
Bi-directional streaming calls
As expected, bi-directional calls are a combination of client and server streaming calls, whereby the data event is emitted for each response from the server, and the client can send multiple requests using the call object send method.