feat(api-client,cmd-api-server): add Socket.IO as transport #297
Labels
API_Server
enhancement
New feature or request
Performance
Everything related to how fast/efficient the software or it's tooling (e.g. build) is.
SPIKE
Exploratory work to better scope additional effort
Milestone
Comments
petermetz
added
enhancement
3 tasks
petermetz
changed the title
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 29, 2021
…er#297 WORK IN PROGRESS To-do: 1. authz 2. auto-reconnect test(?) 3. Socket provider singleton on client side for connection multiplexing Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 29, 2021
…er#297 WORK IN PROGRESS To-do: 1. authz 2. auto-reconnect test(?) 3. Socket provider singleton on client side for connection multiplexing Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 29, 2021
…er#297 WORK IN PROGRESS To-do: 1. authz 2. auto-reconnect test(?) 3. Socket provider singleton on client side for connection multiplexing Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 1, 2021
…er#297 WORK IN PROGRESS To-do: 1. Socket provider singleton on client side for connection multiplexing Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 2, 2021
…er#297 WORK IN PROGRESS To-do: 1. Socket provider singleton on client side for connection multiplexing Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 3, 2021
…er#297 Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. Secondary change(s): 1. To-do: 1. Socket provider singleton on client side for connection multiplexing Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 3, 2021
Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. 3. The idea is that all async endpoints would declare their event names as constants in the OpenAPI specification so as to make it easier at least to some degree to implement solutions on top even if we cannot support async endpoints with the OpenAPI code generator to the same extend we do for HTTP RESTful endpoints. The five default events are Subscribe, Next, Unsubscribe, Error and Complete. These are defined in order to match what the client can do on the RxJS Observable object returned by the API client object's method that invokes the async endpoints. The difference between Unsubscribe and complete is subtle, but it definitely exists. The unsubscribe event is used by the client to tell the backend that it no longer requires updates, regardless of the streaming of data having been completed or not. The complete event on the other hand is for the backend to signal that the streaming of data is in fact completed. The complete event is only applicable for endpoints that do have an ending which is not the case for some endpoints that are usually time-series related and therefore a lot of times just stream endlessly until stopped. Secondary change(s): -------------------- 1. Added an async endpoint powered by the just now added SocketIO integration that streams the health check response every one second which is mainly added to that we can test the functionality but at could also be used for monitoring purposes by someone who'd rather implement something from scratch than use Prometheus for example. To-do: ------ 1. Socket provider singleton on client side for connection multiplexing Fixes hyperledger#297 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
This was referenced May 3, 2021
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 25, 2021
Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. 3. The idea is that all async endpoints would declare their event names as constants in the OpenAPI specification so as to make it easier at least to some degree to implement solutions on top even if we cannot support async endpoints with the OpenAPI code generator to the same extend we do for HTTP RESTful endpoints. The five default events are Subscribe, Next, Unsubscribe, Error and Complete. These are defined in order to match what the client can do on the RxJS Observable object returned by the API client object's method that invokes the async endpoints. The difference between Unsubscribe and complete is subtle, but it definitely exists. The unsubscribe event is used by the client to tell the backend that it no longer requires updates, regardless of the streaming of data having been completed or not. The complete event on the other hand is for the backend to signal that the streaming of data is in fact completed. The complete event is only applicable for endpoints that do have an ending which is not the case for some endpoints that are usually time-series related and therefore a lot of times just stream endlessly until stopped. Secondary change(s): -------------------- 1. Added an async endpoint powered by the just now added SocketIO integration that streams the health check response every one second which is mainly added to that we can test the functionality but at could also be used for monitoring purposes by someone who'd rather implement something from scratch than use Prometheus for example. To-do: ------ 1. Socket provider singleton on client side for connection multiplexing Fixes hyperledger#297 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 25, 2021
Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. 3. The idea is that all async endpoints would declare their event names as constants in the OpenAPI specification so as to make it easier at least to some degree to implement solutions on top even if we cannot support async endpoints with the OpenAPI code generator to the same extend we do for HTTP RESTful endpoints. The five default events are Subscribe, Next, Unsubscribe, Error and Complete. These are defined in order to match what the client can do on the RxJS Observable object returned by the API client object's method that invokes the async endpoints. The difference between Unsubscribe and complete is subtle, but it definitely exists. The unsubscribe event is used by the client to tell the backend that it no longer requires updates, regardless of the streaming of data having been completed or not. The complete event on the other hand is for the backend to signal that the streaming of data is in fact completed. The complete event is only applicable for endpoints that do have an ending which is not the case for some endpoints that are usually time-series related and therefore a lot of times just stream endlessly until stopped. Secondary change(s): -------------------- 1. Added an async endpoint powered by the just now added SocketIO integration that streams the health check response every one second which is mainly added to that we can test the functionality but at could also be used for monitoring purposes by someone who'd rather implement something from scratch than use Prometheus for example. To-do: ------ 1. Socket provider singleton on client side for connection multiplexing Fixes hyperledger#297 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 25, 2021
Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. 3. The idea is that all async endpoints would declare their event names as constants in the OpenAPI specification so as to make it easier at least to some degree to implement solutions on top even if we cannot support async endpoints with the OpenAPI code generator to the same extend we do for HTTP RESTful endpoints. The five default events are Subscribe, Next, Unsubscribe, Error and Complete. These are defined in order to match what the client can do on the RxJS Observable object returned by the API client object's method that invokes the async endpoints. The difference between Unsubscribe and complete is subtle, but it definitely exists. The unsubscribe event is used by the client to tell the backend that it no longer requires updates, regardless of the streaming of data having been completed or not. The complete event on the other hand is for the backend to signal that the streaming of data is in fact completed. The complete event is only applicable for endpoints that do have an ending which is not the case for some endpoints that are usually time-series related and therefore a lot of times just stream endlessly until stopped. Secondary change(s): -------------------- 1. Added an async endpoint powered by the just now added SocketIO integration that streams the health check response every one second which is mainly added to that we can test the functionality but at could also be used for monitoring purposes by someone who'd rather implement something from scratch than use Prometheus for example. To-do: ------ 1. Socket provider singleton on client side for connection multiplexing Fixes hyperledger#297 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 25, 2021
Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. 3. The idea is that all async endpoints would declare their event names as constants in the OpenAPI specification so as to make it easier at least to some degree to implement solutions on top even if we cannot support async endpoints with the OpenAPI code generator to the same extend we do for HTTP RESTful endpoints. The five default events are Subscribe, Next, Unsubscribe, Error and Complete. These are defined in order to match what the client can do on the RxJS Observable object returned by the API client object's method that invokes the async endpoints. The difference between Unsubscribe and complete is subtle, but it definitely exists. The unsubscribe event is used by the client to tell the backend that it no longer requires updates, regardless of the streaming of data having been completed or not. The complete event on the other hand is for the backend to signal that the streaming of data is in fact completed. The complete event is only applicable for endpoints that do have an ending which is not the case for some endpoints that are usually time-series related and therefore a lot of times just stream endlessly until stopped. Secondary change(s): -------------------- 1. Added an async endpoint powered by the just now added SocketIO integration that streams the health check response every one second which is mainly added to that we can test the functionality but at could also be used for monitoring purposes by someone who'd rather implement something from scratch than use Prometheus for example. To-do: ------ 1. Socket provider singleton on client side for connection multiplexing Fixes hyperledger#297 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
that referenced
this issue
May 26, 2021
Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. 3. The idea is that all async endpoints would declare their event names as constants in the OpenAPI specification so as to make it easier at least to some degree to implement solutions on top even if we cannot support async endpoints with the OpenAPI code generator to the same extend we do for HTTP RESTful endpoints. The five default events are Subscribe, Next, Unsubscribe, Error and Complete. These are defined in order to match what the client can do on the RxJS Observable object returned by the API client object's method that invokes the async endpoints. The difference between Unsubscribe and complete is subtle, but it definitely exists. The unsubscribe event is used by the client to tell the backend that it no longer requires updates, regardless of the streaming of data having been completed or not. The complete event on the other hand is for the backend to signal that the streaming of data is in fact completed. The complete event is only applicable for endpoints that do have an ending which is not the case for some endpoints that are usually time-series related and therefore a lot of times just stream endlessly until stopped. Secondary change(s): -------------------- 1. Added an async endpoint powered by the just now added SocketIO integration that streams the health check response every one second which is mainly added to that we can test the functionality but at could also be used for monitoring purposes by someone who'd rather implement something from scratch than use Prometheus for example. To-do: ------ 1. Socket provider singleton on client side for connection multiplexing Fixes #297 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
RafaelAPB
pushed a commit
to RafaelAPB/blockchain-integration-framework
that referenced
this issue
Mar 9, 2022
Primary changes: --------------- 1. The API server now has a SocketIO server running on the same port as the HTTP REST API. 2. The API server now has an ApiServerApiClient class which is an extension of the DefaultApi class that we generate from the OpenAPI specifications. The reason why this extension was necessary (something that we try to avoid like the plague normally) is because OpenAPI is strictly for defining HTTP/REST based APIs and not async/streaming ones such as WebSocket/SocketIO based ones and therefore the OpenAPI generator does not support these types of transports at all meaning that we have to manually write the client code for async endpoints which is why the class extension here is not something that we can get around. 3. The idea is that all async endpoints would declare their event names as constants in the OpenAPI specification so as to make it easier at least to some degree to implement solutions on top even if we cannot support async endpoints with the OpenAPI code generator to the same extend we do for HTTP RESTful endpoints. The five default events are Subscribe, Next, Unsubscribe, Error and Complete. These are defined in order to match what the client can do on the RxJS Observable object returned by the API client object's method that invokes the async endpoints. The difference between Unsubscribe and complete is subtle, but it definitely exists. The unsubscribe event is used by the client to tell the backend that it no longer requires updates, regardless of the streaming of data having been completed or not. The complete event on the other hand is for the backend to signal that the streaming of data is in fact completed. The complete event is only applicable for endpoints that do have an ending which is not the case for some endpoints that are usually time-series related and therefore a lot of times just stream endlessly until stopped. Secondary change(s): -------------------- 1. Added an async endpoint powered by the just now added SocketIO integration that streams the health check response every one second which is mainly added to that we can test the functionality but at could also be used for monitoring purposes by someone who'd rather implement something from scratch than use Prometheus for example. To-do: ------ 1. Socket provider singleton on client side for connection multiplexing Fixes hyperledger#297 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
HTTP is cool, but in certain scenarios WebSockets are much more efficient and provide lower latency due to reduced overhead when exchanging messages in a re-used connection, multiplexing them over the same connection, etc.
Describe the solution you'd like
Something that allows the currently defined endpoints via the OpenAPI spec to be also callable via WebScokets not just HTTP.
This is not a well formed idea yet, but we could potentially have a generic WebSocket service that speaks JSON-RPC 2 and through that the existing API endpoints can be called but without HTTP being in the mix.
This will require some refactoring (most likely) on the current endpoints to ensure that the HTTP handling code is properly separated from the actual logic (so that the logic can be called by the WebSocket handling code the same way the HTTP code does it)
cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo
The text was updated successfully, but these errors were encountered: