How to cascade GraphQL? - graphql

I'm currently using "client side GraphQL server" to wrap RESTful endpoint to GraphQL endpoint.
But what if server side is also a GraphQL endpoint? How can I queue another GraphQL server in a GraphQL server by a lightweight way?
Or more generally, If I have GraphQL servers "A" and "B", providing microservices, then I use a GraphQL server "C" to integrate "A" and "B". Should I use some kind of "Server side Client" using apollo-client or so to queue "A" and "B" in "C" ?

I've never seen client side GraphQL used that way, but I imagine it would work like usual. You have your query with a resolver which returns data. In this case, you would use a GraphQL request instead of a REST api request, but the principle is the same.
Remember, GraphQL is not that different from any other api. You send HTTP requests (with GraphQL, all of the requests are POST) to a URL endpoint (with GraphQL, the URL is always the same) and send parameter data with your request (with GraphQL, this is where the entire query goes).
I imagine you could translate your variables from the client GraphQL query to the variables in the server GraphQL query and construct your query that way.
With cURL, you can query with a format like this:
$ curl -XPOST -H "Content-Type:application/graphql" -d 'query RootQueryType { count }' http://localhost:3000/graphql
And the response would look like this:
{
"data": {
"count": 0
}
}
Just use the request library you are using on the client to hit the REST client, but modify it to match the API of the GraphQL server you are trying to reach.

Actually, I think it's the job of resolving function to interact with your micro services. For more information, you should have a look at GraphQL and Microservice Architecture

Related

Can I connect to a GraphQL Subscribtion using Insomnia REST client?

Insomnia now supports WebSockets. Therefore I was hoping that I can also use it to test GraphQL Subscriptions, since they are also using WebSockets.
I created a GraphQL request to open a new Subscription, but I always get the following response:
{
"errors": [
{
"message": "The response type is not supported."
}
]
}
Am I doing something wrong or are GraphQL Subscriptions simply not a feature in Insomnia?
I checked the Insomnia WebSocket Docs as well as the Insomnia GraphQL Queries Docs but couldn't find any info regarding this topic.

Can't I create a rest API in the apollo-server?

It is currently being developed using mysql-prisma-apollo server-nexus, and it is necessary to receive row data post using the REST API, not the GrqphQL statement currently developed. You want to process raw data passed to the post in Path (for example,/api/data/status). Is there a way to create a RestAPI on the apollo-server?
The apollo-server runs in a node environment, so you are able to use any http client you want.
Example:
axios
node-fetch

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

Why are GraphQL queries POST requests even when we are trying to fetch data and not update/submit new data?

I am using Postman to fetch data from my server and when I use a REST call it is a GET request but when I use a GraphQL API call, it needs to be a POST request. Why is it so?
The GraphQL spec is itself transport-agnostic, however the convention adopted by the community has been to utilize POST requests. As pointed out in the comments, some libraries support GET requests. However, when doing so, the query has to be sent as a URL query parameter since GET requests can't have bodies. This can be problematic with bigger queries since you can easily hit a 414 URI Too Long status on certain servers.
The best practice is to always utilize POST requests with a application/json Content-Type.

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.

Resources