-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(cmd-api-server): support grpc web services #1189
Labels
API_Server
dependencies
Pull requests that update a dependency file
Developer_Experience
enhancement
New feature or request
Significant_Change
Applying this label triggers the more stringent review of the maintainers and the 2+1 PR rule.
Milestone
Comments
3 tasks
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Aug 8, 2021
WORK IN PROGRESS! Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Aug 8, 2021
WORK IN PROGRESS! Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
We have to wait for this to be fixed in order to have the camelCase property names turned into lowerCamelcase: |
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Aug 11, 2021
TODO: 1. Figure out how to stop the generator from mangling the model property names into capital case (getCreatedat) See: https://github.com/protocolbuffers/protobuf/issues/8608 2. Figure out how to export the OpenAPI model classes and the gRPC model classes at the same time without name conflicts (they have the same names) 3. Implement streaming healthcheck endpiont with gRPC 4. Allow plugins to hook in their own gRPC service implementations. 5. Verify with test case that the secure credentials flavor also works. Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Aug 11, 2021
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. The "allowJs" flag for the Typescript compiler is now specified as true for the cmd-api-server package which is necessary because without this the .js files generated by protoc do not get copied over from the ./src/main/typescript/generated/ folder to the ./dist/lib/.../generated folder with the rest of the build files. It is not ideal that we are generating JS code into the TS folder but it does come with .d.ts files and this is the "state of the art" at the moment becaues we can only do what the protocol buffer compiler will support and this is it. Later on we should improve on this situation once the tooling catches up and adds support to generate straight up TS code instead of JS+d.ts files so that we keep to our convention of having only TS code under ./src/main/typescript for obvious reasons. TODO: ---- 1. Figure out how to stop the generator from mangling the model property names into capital case (getCreatedat) See: https://github.com/protocolbuffers/protobuf/issues/8608 2. Figure out how to export the OpenAPI model classes and the gRPC model classes at the same time without name conflicts (they have the same names) 3. Implement streaming healthcheck endpiont with gRPC 4. Allow plugins to hook in their own gRPC service implementations. 5. Verify with test case that the secure credentials flavor also works. Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Aug 13, 2021
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. Custom protobuf-schema openapi generator template added because of this issue: thesayyn/protoc-gen-ts#82 (we override the stock template to not use the public keyword) TODO: ---- 1. Implement streaming healthcheck endpiont with gRPC 2. Allow plugins to hook in their own gRPC service implementations. Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Aug 17, 2021
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. Custom protobuf-schema openapi generator template added because of this issue: thesayyn/protoc-gen-ts#82 (we override the stock template to not use the public keyword) TODO: ---- 1. Implement streaming healthcheck endpiont with gRPC 2. Allow plugins to hook in their own gRPC service implementations. Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Aug 26, 2021
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. Custom protobuf-schema openapi generator template added because of this issue: thesayyn/protoc-gen-ts#82 (we override the stock template to not use the public keyword) TODO: ---- 1. Implement streaming healthcheck endpiont with gRPC 2. Allow plugins to hook in their own gRPC service implementations. Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
added a commit
that referenced
this issue
Aug 27, 2021
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. Custom protobuf-schema openapi generator template added because of this issue: thesayyn/protoc-gen-ts#82 (we override the stock template to not use the public keyword) TODO: ---- 1. Implement streaming healthcheck endpiont with gRPC 2. Allow plugins to hook in their own gRPC service implementations. Fixes #1189 Signed-off-by: Peter Somogyvari <[email protected]>
hanxu12
pushed a commit
to hanxu12/cactus
that referenced
this issue
Aug 29, 2021
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. Custom protobuf-schema openapi generator template added because of this issue: thesayyn/protoc-gen-ts#82 (we override the stock template to not use the public keyword) TODO: ---- 1. Implement streaming healthcheck endpiont with gRPC 2. Allow plugins to hook in their own gRPC service implementations. Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
RafaelAPB
pushed a commit
to RafaelAPB/blockchain-integration-framework
that referenced
this issue
Mar 9, 2022
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. Custom protobuf-schema openapi generator template added because of this issue: thesayyn/protoc-gen-ts#82 (we override the stock template to not use the public keyword) TODO: ---- 1. Implement streaming healthcheck endpiont with gRPC 2. Allow plugins to hook in their own gRPC service implementations. Fixes hyperledger#1189 Signed-off-by: Peter Somogyvari <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
API_Server
dependencies
Pull requests that update a dependency file
Developer_Experience
enhancement
New feature or request
Significant_Change
Applying this label triggers the more stringent review of the maintainers and the 2+1 PR rule.
Is your feature request related to a problem? Please describe.
We have HTTP, SocketIO (WebSockets) support and the third big one that we definitely need is gRPC support so that plugins can expose gRPC services as needed.
Describe the solution you'd like
Extend the API server with the additional gRPC web services functionality the same way as it was extended with SocketIO a while ago, e.g. update the necessary core-api interfaces and then the API server itself so that it can include plugins that use gRPC either in addition or instead of HTTP/SocketIO.
Include a test case that exposes a gRPC web service plugin verifying the mechanisms end to end.
Develop a way to provide a consistent experience to users of the API client packages regardless of them using gRPC or SocketIO/HTTP => The API surface of the API client package should be based on reactive programming patterns (e.g. Observables from the RxJS library in this case)
Describe alternatives you've considered
Nothing, I'm pretty sure we need this and there isn't any other way around it as far as I can tell.
Additional context
Before we can bring the Weaver code base closer, this is a prerequisite.
The text was updated successfully, but these errors were encountered: