https://pastebin.com/7vqdrHyg greet.proto
https://pastebin.com/4PYDYZ6Q greet_grpc.pb.go
https://pastebin.com/2n6n8JjS greet_pb.go
https://pastebin.com/FPpCJEGR main.go
https://pastebin.com/CXuxG5fB handler/greet.go
I have implemented a simple grpc server using Golang. The server accepts a connection from a client and returns a simple response message.
I have a Python client that is trying to connect to the server through localhost:8080.
The gRPC code for the client and server are created with the same IDL interface.
https://pastebin.com/RLp3QUWX client.py
However, the connection is unsuccessful and I got the following error.
https://pastebin.com/Cji9Pkhj
I don't know how GreetService is called at the server side, but I assumed that the interface is defined somewhere in greet_grpc.pb.go
UPDATE: I have pushed the code to this repo for better readability.
Related
I'm writing a client which communicates with multiple server via gRPC. The data transfer works absolutely fine but I'm getting an exception on client side when one of the server stops abruptly. I would like to know if there is any error handling in gRPC library which can handle this server disconnection and do a clean exit from client side.
I can see methods like bool IsCancelled() const which could be used on server side to get status about client disconnection.
I need a similar method to be used on client to get notified about server disconnection.
I am trying to implement a GraphQL WebSocket-based #subscription on a server (using NestJS #subscription). The server is hosted on an AWS ECS and is behind an ALB.
We currently have an AWS API GW connection via VPC-link to our ALB.
I tried to build a dedicated Websocket API GW with the same VPC link we use in the HTTP API GW.
I also tried to spin up a new NLB (Network Load Balancer) over our ECS and a new REST VPC link to be used in the dedicated Websocket API GW.
The client and server are communicating over a graphql-transport-ws sub-protocol using graphql-ws library and the communication is working fine on a localhost setup.
When running the following command on our local host I am able to establish a web socket connection:
wscat -c ws://localhost:3000/graphql -s graphql-transport-ws
When running the same against the WebSocket API GW URL
wscat -c wss://*****.execute-api.*****.amazonaws.com/**** -s graphql-transport-ws
I’m getting this:
error: Server sent no subprotocol
The error indicates a problem with the sub-protocol so when removing the sub-protocol a connection is established and I am getting a prompt:
Connected (press CTRL+C to quit)
>
However, there’s no indication of reaching the server and it seems like the connection is only made with the WebSocket API GW itself.
When I circumvent the gateway and directly connect an internet-facing NLB I'm able to establish a WebSocket connection.
I am not a super Websocket expert, but I understand WebSocket connections will be terminated by the API Gateway and cannot be used as a connection pass-through. You can forward web socket events using AWS_PROXY integration to a graphQL server backend, BUT it's not a maintained direct connection - API Gateway terminates and events towards the backend integration and will not return the integration response to the WebSocket since it is event-driven and not a connection-oriented service - hence the “error: Server sent no subprotocol” you are seeing.
So to use API GW as the WebSocket layer, you would need to build out connection management functionality somewhere to manage the event-based nature of the APIGW and send out data to the APIGW connections or adjust the integration mechanism within the graphql server to utilise the #connection functionality to send responses/notifications to WebSocket consumers.
Integrating Backend Service documentation:
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-routes-integrations.html
Sending responses to a connected client:
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-how-to-call-websocket-api-connections.html
API GW Websockets are great for building custom solutions but take some effort since you will be configuring the setup for the events.
For a GraphQL API on AWS - I would recommend taking a look at AppSync, which is an AWS Managed GraphQL service - it handles GraphQL subscriptions via WebSockets natively and with zero additional code and its highly scalable out of the box and would simplify the GraphQL hosting burden of an ECS based solution.
I suspect there may be a lot of other reasons for the need to build out using existing GraphQL on ECS, so understand it's not always possible to pivot to something like AppSync. I feel the NLB solution you tried is okay within the existing ECS backend landscape and, as you have noted, is connection-oriented (via NLB), so will achieve the outcome you are after.
Websockets are hailed as a bi-directional process. However, whilst there are hundreds of websocket code examples on the web, they all require a request from the client(browser) to the server to get the data (like an echo server or chat).
So far, I have not found any code which will send new data (originating at the server end) to the client via an open websocket. Ideally, I would like to use a node.js server but I'm open to alternatives. Any ideas?
I was experimenting hashicorp/yamux over gorilla/websocket, and got stuck.
I started with vanilla WebSocket using the echo example from Gorilla WebSocket project. It was very a straight forward client-server setup. Then image that the server is now behind a firewall, thus the client cannot make a direct connection to it. So I introduced a hub and an agent. The hub is supposed to be publicly visible and connectable for the client. The agent would run alongside the server, who would first make a WebSocket connection to the hub and then multiplex the connection using Yamux so that the hub can then initiate requests to the server. In this way, I effectively "exposed" the server beyond the firewall.
For normal HTTP endpoints, things are good. The client can make requests to the hub, who would proxy these requests to the agent using the WebSocket connection initiated by the hub, and then the hub would further proxy these requests to the server.
However, this trick failed to work with WebSocket endpoints. For the echo example, the client can access the HTML on / through the hub-agent-server chain, but would fail on the /echo path, which is a WebSocket endpoint.
My question is, is this WebSocker over Yamux over WebSocket fundamentally impossible, or do I just need some extra lines to get things work? Here's the code I've been experimenting with. Really appreciate your helps!
I have a server that redirects to server:443 when connecting to server:80. I have a grpc client that is connecting to server:80 with
clientConn, err = grpc.Dial("server:80", grpc.WithTransportCredentials(credentials.NewTLS(config)))
Its throwing a "tls: first record does not look like a TLS handshake" error. Is there a way to make the client follow the redirects?
gRPC client does not handle 302 redirects. See this https://github.com/grpc/grpc-java/issues/5330 - this is for Java but also applies to Golang.