Use Postman to test Appsync Subscription - websocket

I have been able to successfully execute Appsync GraphQL queries and mutations from Postman. However, i'm struggling to connect to subscriptions which are websocket urls.
How can I achieve the same ?

Since Postman supports WebSockets testing GraphQL subscriptions is achievable as well. Such a testing requires two steps:
connection to a server,
sending a start message.
Establishing a connection:
Create a new WebSocket request.
Put your server URL ws:// or wss://.
Add custom header parameter Sec-WebSocket-Protocol: graphql-ws. Other headers may depend on your server configuration.
Press the "Connect" button.
When the connection is established we may start a subscription.
In the "New message" field put the command.
Press the "Send" button.
The start message should look like this:
{
"id":"1",
"payload": {
"operationName": "MySubscription",
"query": "subscription MySubscription {
someSubscription {
__typename
someField1
someField2 {
__typename
someField21
someField22
}
}
}",
"variables": null
},
"type": "start"
}
operationName is just the name of your subscription, I guess it's optional. And someSubscription must be a subscription type from your schema.
query reminds regular GraphQL syntax with one difference:
__typename keyword precedes every field list.
For example, the query from the payload in regular syntax looks like the following:
subscription MySubscription {
someSubscription {
someField1
someField2 {
someField21
someField22
}
}
}
Example message with parameters (variables):
{
"id":"1",
"payload": {
"operationName": "MySubscription",
"query": "subscription MySubscription($param1: String!) {
someSubscription((param1: $param1)) {
__typename
someField
}
}",
"variables": {
"param1": "MyValue"
}
},
"type": "start"
}
It also reminds regular GraphQL syntax as described above.
variables is an object with your parameters.

#Vladimir's answer is spot on. Adding a few notes for folks still having trouble.
Full document here # https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html
Step 1 - establish connection:
make sure to base64 encode values in "header" and "payload" querystrings
header example:
{
"host":"example1234567890000.appsync-api.us-east-1.amazonaws.com",
"x-api-key":"da2-12345678901234567890123456"
}
payload: You can pass in empty payload
{}
Step 2 - register subscription:
Include the authorization in the message. Escape line feeds properly "\n" throws an error but "\\n" works. it throws the following error - misleading.
Don't forget to stringify value in "data" field.
{
"type": "error",
"payload": {
"errors": [
{
"errorType": "UnsupportedOperation",
"message": "unknown not supported through the realtime channel"
}
]
}
}
{
"id": "2",
"payload": {
"data": "{\"query\":\"subscription onCreateMessage { changeNotification{ __typename changeType from } }\",\"variables\":{}}",
"extensions":{
"authorization":{
"host":"example1234567890000.appsync-api.us-east-1.amazonaws.com",
"x-api-key":"da2-12345678901234567890123456"
}
}
},
"type": "start"
}

Related

Storage Transfer Service transferJobs.patch API does not work for nested object

Problem you have encountered:
Following steps at link below for transferJobs.patch API
https://cloud.google.com/storage-transfer/docs/reference/rest/v1/transferJobs/patch
Patch API works as expected if want to update description. Sample Below
Request:
{
"projectId": "<MY_PROJECT>",
"transferJob": {
"transferSpec": {
"objectConditions": {
"lastModifiedSince": "2022-01-24T18:30:00Z"
}
},
"description": "updated description"
},
"updateTransferJobFieldMask": "description"
}
Response: Success 200
Patch API do not work if want to update nested object field. Sample Below
{
"projectId": "<MY_PROJECT>",
"transferJob": {
"transferSpec": {
"objectConditions": {
"lastModifiedSince": "2022-01-22T18:30:00Z"
}
},
"description": "updated description"
},
"updateTransferJobFieldMask": "transferSpec.objectConditions.lastModifiedSince"
}
Response: 400
{"error": {
"code": 400,
"message": "Invalid path in the field mask.",
"status": "INVALID_ARGUMENT"}}
Tried other combinations following documentation/sample code reference but none of them work. Tried options as
transferSpec.objectConditions.lastModifiedSince
transferJob.transferSpec.objectConditions.lastModifiedSince
objectConditions.lastModifiedSince lastModifiedSince Snake case
combination referring to FieldMaskUtil as transfer_spec.object_conditions.last_modified_since
What I expected to happen:
Patch API to work successfully for nested object as per documentation I.e. "updateTransferJobFieldMask": "transferSpec.objectConditions.lastModifiedSince"
updateTransferJobFieldMask works on the top level object, in this case transferSpec.
Changing that line to updateTransferJobFieldMask: transferSpec should work.
From the documentation:
The field mask of the fields in transferJob that are to be updated in this request. Fields in transferJob that can be updated are: description, transfer_spec, notification_config, and status. To update the transfer_spec of the job, a complete transfer specification must be provided. An incomplete specification missing any required fields will be rejected with the error INVALID_ARGUMENT.
Providing complete object having required child field worked. Sample example for future reference to other dev.
Below job transfer dat from Azure to GCP bucket and during patch updating last modified time. Both transfer_spec and transferSpec works as updateTransferJobFieldMask.
{
"projectId": "<MY_PROJECT>",
"updateTransferJobFieldMask": "transfer_spec",
"transferJob": {
"transferSpec": {
"gcsDataSink": {
"bucketName": "<BUCKET_NAME>"
},
"objectConditions": {
"lastModifiedSince": "2021-12-30T18:30:00Z"
},
"transferOptions": {},
"azureBlobStorageDataSource": {
"storageAccount": "<ACCOUNT_NAME>",
"container": "<CONTAINER>",
"azureCredentials": {
"sasToken": "<SAS TOKEN>"
}
}
}
}
}

Consume graphQL API from Mule 4

I want to consumer graphQl API.
I know we need to use http requester to call graphQl.
I need some info on forming mutation request using dwl.
I was trying to hit this service https://www.predic8.de/fruit-shop-graphql
using below
%dw2.0
outputapplication/json
---
{
"query": "mutation(\$input:addCategoryInput!) { addCategory(input:\$input) { name products { name}} }",
"variables": {
"input": {
"id": 6,
"name": "Green Fruits",
"products": 8
}
}
}
its throwing bad request
But when using below
%dw 2.0
output application/json
---
{
"query": "mutation { addCategory(id: 6, name: \"Green Fruits\", products: 8) { name products { name } }}"
}
its working.
I want to use above format. Are both not valid requests.
Please share me your knowledge or guide me to right blog to refer.
Since GraphQL is not a supported format for DataWeave at this time, you have to write the query yourself as a string. You can however use DataWeave to create the body of a POST request for a query.
Example:
%dw 2.0
output application/json
---
{
"query": "mutation(\$schedule:PipelineScheduleCreateInput!) { pipelineScheduleCreate(input:\$schedule) { pipelineScheduleEdge { node { label nextBuildAt cronline } } } }",
"variables": {
"schedule": {
"pipelineID": "UGlwZWxpbmUtLS02MzliNWJjOC0wMGZmLT",
"cronline": "#midnight",
"label": "Nightly build"
}
}
}

When I send a mutation request to chaskiq graphql endpoint I get "Data not found"

I have been using Chaskiq for some work but ran into an error.
I built from source on Ubuntu 20.04.
I got the graphql part working and query requests work. However, whenever I make a mutation request I seem to get this response:
{
"errors": [
{
"message": "Data not found",
"data": {}
}
]
}
Example mutation request I sent to get the response above:
mutation updateAppUser($appKey: String!, $options: Json!, $id: Int!) {
updateAppUser(appKey: $appKey, options: $options, id: $id) {
appUser {
id
name
email
}
}
}
I have the variables Query Variables as below:
{
"appKey": <My_APP_KEY>,
"options": {
"name": <Custom_Name>
},
"id": <My_ID>
}
Please help me know the solution to the problem.
Data not found is returned when the server does not found any record.
basically ActiveRecord::RecordNotFound , so you are probably trying to find the wrong record. check the logs to see what's happening

office 365 outlook Graph api custom email message header

In order to organize emails into single thread GMail requires custom headers to be set within incoming message. Is there any way to set custom headers when sending Office O365 Outlook message through the Graph API? The documentation states about custom headers option through the InternetMessageHeaders property, however it is required to start header name with 'x-' appendix, which makes it not usable. For example, this message is supposed to set some custom headers, however, due to the 'x-' prefix limitation, this can't be used for organizing GMail messages:
POST https://graph.microsoft.com/v1.0/me/sendMail
Content-type: application/json
{
"message": {
"subject": "9/9/2018: concert",
"body": {
"contentType": "HTML",
"content": "The group represents Nevada."
},
"toRecipients": [
{
"emailAddress": {
"address": "AlexW#contoso.OnMicrosoft.com"
}
}
],
"internetMessageHeaders":[
{
"name":"x-custom-header-group-name",
"value":"Nevada"
},
{
"name":"x-custom-header-group-id",
"value":"NV001"
}
]
}
}
https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0&tabs=http
Is there any way to specify custom headers: 'References', 'In-Reply-To' without the prefix 'x-'?
https://gsuiteupdates.googleblog.com/2019/03/threading-changes-in-gmail-conversation-view.html
When trying to set custom email headers without 'x-' prefix, the Graph API returns following error message:
{
"error": {
"code": "InvalidInternetMessageHeader",
"message": "The internet message header name 'References' should start with 'x-' or 'X-'.",
"innerError": {
"request-id": "441e21b7-d4ca-47d3-957a-a72bcc854a67",
"date": "2019-12-10T14:28:35"
}
}
}
One workaround might be to use the Extended properties to set those values eg the In-Reply-to https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtaginreplytoid-canonical-property should look something like
"singleValueExtendedProperties": [
{
"id":"String 0x1042",
"value":"342342343234#domain.com"
}
]

Is GitHub API returning an invalid result for the schema query?

https://facebook.github.io/graphql/draft/#sec-Schema-Introspection
type __Schema {
types: [__Type!]!
queryType: __Type!
mutationType: __Type
subscriptionType: __Type
directives: [__Directive!]!
}
type __Type {
kind: __TypeKind!
name: String
description: String
...
Information downloaded from https://developer.github.com/v4/guides/intro-to-graphql/#discovering-the-graphql-api (curl -H "Authorization: bearer token" https://api.github.com/graphql)
(beginning of the file
{
"data": {
"__schema": {
"queryType": {
"name": "Query"
},
"mutationType": {
"name": "Mutation"
},
"subscriptionType": null,
"types": [
{
"kind": "SCALAR",
"name": "Boolean",
...
Question:
I interpreted this so this GitHub schema result is invalid because queryType doesn't specify a kind which is nonNullable (kind: __TypeKind!)
Is this result violating the schema rules or am I missing something?
This response passes validation because a missing field is not the same thing as a field that returns null. A field will be missing from the response only if it wasn't requested in the first place.
If you go to GitHub's GraphQL Explorer, you can generate an introspection query yourself, request the kind field as part of the selection set of the queryType field and it will return the field with a non-null value.
{
__schema {
queryType {
kind
}
}
}
Response:
{
"data": {
"__schema": {
"queryType": {
"kind": "OBJECT"
}
}
}
}
Fetching the schema by making a GET request to some endpoint is convenient, but it's not the standard way to introspect the schema. Instead, you should make the request using whatever selection set is needed against the endpoint itself. The drawback of doing it this less conventional way is made apparent by this question. In this case, whatever introspection query GitHub is making for you under the hood is missing one or more fields that could otherwise be requested. Because you're not the one making the introspection query, you don't know what to expect in terms of the shape of the response.

Resources