how to add static(html,js) files for grpc - go

I have a grpc client and server. I have a protofile. I am using a grpc gateway and I want to use html for the client. There is a path localhost:8081/test, I would like it to be an html file when I go through this path. How can I tell the handler to give the html file in the response?
what should the handler look like?
syntax = "proto3";
option go_package = "/go_proto";
package api;
import "google/api/annotations.proto";
service authorization{
rpc Test(testRequest) returns (testResponse){
option(google.api.http) = {
get: "/test"
};
}
}
message testRequest{
}
message testResponse{
int32 arg1 = 1;
}

If I understand your question correctly, you cannot (directly).
gRPC Gateway is one way (Envoy's gRPC-JSON transcoder is another) to expose gRPC services as (JSON) REST APIs.
In your example, the above solutions will enable you to make HTTP GET calls against /test returning a JSON representation of testResponse ({"arg1":...}).
If you want to serve HTML, see Adding custom routes to the mux this would allow you to write a handler that serves HTML.
NOTE This HTML handler could include JavaScript that uses e.g. fetch to GET the /testendpoint.
Have a look at gRPC-Web too. This requires Node.JS but it provides a gRPC client for JavaScript as an alternative to the REST client described above.
If you want to expose gRPC services with REST APIs, then use gRPC Gateway or Envoy's gRPC-JSON transcoder. This gives you the ability to have clients that use gRPC and REST.
If you want to have only gRPC clients, gRPC-Web gives Node.JS developers access to your gRPC services too.

Related

How to setup ApolloServer and SubscriptionServer to use http and ws in graphql

I have been following the docs for here and here to implement the subscriptions-transport-ws plugin. My big confusion is differentiating the graphql url for http:// and ws://. In the examples above it looks like ApolloServer is getting replaced by SubscriptionServer. But if I only want to use websockets in special circumstances, then don't I still need both? Or is SubscriptionServer handling both at once and doing some magic in the background which figures out which one to use based on whether or not a subscription is called?
apollo-server combines several tools such as: graphql-tools, graphql-subscriptions, graphql-upload, provide some custom errors, and use express.js web framework as its default web server implementation.
subscriptions-transport-ws is a GraphQL WebSocket server and client to facilitate GraphQL queries, mutations, and subscriptions over WebSocket.
subscriptions-transport-ws is an extension for GraphQL, and you can use it with any GraphQL client and server (not only Apollo).
So, ApolloServer is NOT replaced by SubscriptionServer.
Without using ApolloServer, you need to set up GraphQL HTTP server using express.js, graphqlExpress, graphiqlExpress, cors middlewares by yourself. Like this official sample does.
If you want to create a subscription server, you need to create HTTP server and pass it to SubscriptionServer constructor for initing and connecting WebSocket server to http

Is there any tool to debug the rest calls made by GraphQL Playground?

I'm not able to figure out why the REST API call works just fine in Postman but not in the GraphQL Playground. If I could see the actual REST call being made by GraphQL, would be helpful to debug the issue.
Firecamp's GraphQL client lets you test the GraphQL as an API call or as a Query way.
Here is the dedicated GraphQL client
Here is REST like GraphQL client
Note: Make sure that you double-check the method and headers while using REST-like GraphQL client. IN most cases method would be post and header should contains Content-Type: application-json / application/graphql
The GraphQL playground allows to send GraphQL queries/mutations to your GraphQL server. You can see the requests that are send using the network tab of a browser dev tools.
For example, if a server is in running at the following address http://localhost:4000/graphql, sending a query/mutation, a XHR request will be sent to it. In the Request Payload of the Headers section there is the query/mutation itself.
In the Response section you can see the returned response.
You can start having a look at the returned response of your query/mutation. Perhaps there is something wrong in the related resolve function in GraphQL.

GraphQL endpoint for file download

Is it possible to trigger a file download in a browser from the GraphQL endpoint on an apollo-server-express application?
I have the endpoint written in a standard express app.get function (see below) but I would like to make use of the GraphQL context for file download and so I'm wondering if it's possible to cause a download from a GraphQL endpoint.
Here's a bare-bones example of what I have on the express end in the app.get function:
app.get('/download-batch/:batchId', async (req, res) => {
res.send(new Buffer('test'));
});
Any help would me much appreciated. Thanks!
Yes, but you would be required to create a custom endpoint for that. You can't use the existing endpoint which you are using for making requests.
Using the custom endpoint, you have to add a middleware and process the data into a buffer or whatever format you need. But it would not be recommended. That would again become one more endpoint instead which you can write an API to serve that.(After all graphql is built mainly on the focus of single endpoint).
BoĊĦtjan Cigan mentions here some solutions and gives details about using GraphQL as a proxy with Minio. The backend would ask Mino to generate a temporary link that can be sent back to the browser for direct access.
This is a valid solution for many use cases.

AWS api gateway - http proxy should take status code from origin

I am currently trying to setup AWS Api Gateway, to proxy to another api, that has fully functional methods, response content, status codes etc. This is fairly simple to setup, but I have noticed that the Api Gateway always returns 200 OK no matter what the origin api responds with.
Fx. if there was a bad request (in the origin api) which results in a error message in JSON and a 400 Bad Request, the Api Gateway will respond with a the exact same error message, but a status code of 200 OK
If I remove all settings from the Message Response in the API Gateway web-interface, I get an internal error in the API Gateway. Can it be true that I have to map all the different status codes from the origin api manually in the Api Gateway?
I would prefer if it was possible to just let the status code (as well as the response, which currently works great) pass through, and not have the Api Gateway touch it in any way.
Proxy integration can be used to achieve this. In this case, it is HTTP Proxy. Lambda Proxy integration can also be used but will need some code logic in lambda. API GW will then return the result as-is.
You are correct that currently when using API Gateway you are required to map all response codes in your integration responses. We have heard this "pass through" request from other customers and we may consider including this in future updates to the service.

grpc header/cookie in Go

I want to do place on server application which can be called by Go APP and Java app both.
for some reason ,there's a cookie authentication and oAuth mechanism ,so I want to set one Go app as Auth Micro-service for the authentication purpose.
As GRPC is built on the HTTP2 ,so The headers and cookies are on the protocol.but I did not find out how to carry on header and cookie when the rpc occurs,implemented by Go, on GitHub I only found the JAVA-Implementation for headers at :
https://github.com/grpc/grpc-java/tree/master/examples/src/main/java/io/grpc/examples/header
Can anybody give me some direction of Go implementation for this purpose?
Headers in gRPC are called "Metadata." Clients can only send "headers". Servers can send both "headers" and "trailers."
You want to:
Use the google.golang.org/grpc/metadata package and metadata.NewContext() to send metadata from the client-side.
Use grpc.SendHeader() and grpc.SetTrailer() to send metadata from the server-side.
Use the grpc.Header() and grpc.Trailer() CallOptions for receiving the Metadata on the client-side.
Use metadata.FromContext() for receiving metadata on the server-side.

Resources