wss:// is the websocket endpoint so that’s correct. Did you look to your websocket handler lambda’s cloudwatch logs of there is some error? Otherwise it’s hard to help you without the code.

On Sat, 15 Aug 2020 at 00:24, miliu99 [email protected] wrote:

Ah, somehow I got that problem resolved, but get a new one:

WebSocket connection to 'wss:// 2nilfiusp1.execute-api.us-east-1.amazonaws.com/dev' failed: WebSocket is closed before the connection is established.

I'm wondering is this the right endpoint? In the document, it says "please provide the uri of the api gateway v2 endpoint", but I got it from serverless.yml output as:

endpoints:

ANY - https://ys13c4hyo4.execute-api.us-east-1.amazonaws.com/dev/

wss://2nilfiusp1.execute-api.us-east-1.amazonaws.com/dev

Is this v2? How do I know? In the serverless.yml there is no reference to v2.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/michalkvasnicak/aws-lambda-graphql/issues/107#issuecomment-674296157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKU7B2XBVQAFO73BJ5KDDSAW2SZANCNFSM4P7ZJDXA .

-- Michal Kvasničák - web developer

Kontakt: web: www.kvasnicak.info mobil: +421 908 876 467 skype: misiak_michal

If you want to share your project that uses this library please do so here 🙂

Hello michal,

Thank for making such a helpful package, i'm currently facing a minor problem with subscriptions, and here is whats going on.

I'm working on a app, where when a customer creates a new order (A react native application), which will trigger a mutation and then publish a subscription event to our web app (A react application), it successfully triggers and the new order is received and shown in the UI and shown in the event table in dynamodb.

const createOrder = async ({ NewOrderInputs }, _ ,{pubSub}) => {
  try {
    const orderNum = await nextOrderNum();
    
    const createdOrder = await new Orders({
      ...NewOrderInputs,
      customerId: "customerId",
      orderNumber: "orderNum",
    });

    createdOrder.save();

    pubSub.publish(NEW_ORDER, {newOrder: createdOrder});

    return createdOrder;
  } catch (error) {
    console.log("newOrderNoAuth -> error", error);
  }
};

Now when the web user accepts the new order, a mutation is triggered to change the order status to "Accepted" and publish a subscription event to our user in the RN app, here is when the subscription doesn't do what its suppose to.

const changeOrderStatus = async ({OrderStatusInput}, _ ,{pubSub}) => {
  const {status, eta, orderId} = OrderStatusInput;
  try{
    const currentDateAndTime = new Date();
    const estimatedDateAndTime = eta;

    const order = await Orders.findOneAndUpdate({ _id: orderId },{
      timeStampEta : eta ? estimatedDateAndTime : currentDateAndTime,
      orderStatus: status
    },{new:true});

    pubSub.publish(ORDER_STATUS_CHANGED, {orderStatusChanged: order });

    return true
  }catch(error){
    console.log("changeOrderStatus -> error", error)
  }
}

The first event is triggered but it doesn't go through as if its stuck mid way and nothing shows up in the RN UI and the event table in dynamodb, then when the same event is triggered with a new order status of "Ready", the first event of order status "Accepted" goes through and shows up in the RN UI as well as the event table in dynamodb, and the last order status of "Completed" gets the Ready event.

I am not sure as to why this happening and your help would be much appreciated.

also this is happening only when its deployed to aws, works properly when the server is running on local .

here is what my subscriptions look like

const subscriptions = {
  helloWorldSub: {
    resolve: (rootValue) => rootValue,
    subscribe: (rootValue, args, ctx, info) => ctx.pubSub.subscribe(HELLO_WORLD)(rootValue, args, ctx, info),
  },
  orderStatusChanged: {
    subscribe: withFilter(
      (root, args, ctx, info) => ctx.pubSub.subscribe(ORDER_STATUS_CHANGED)(root, args, ctx, info),
      (payload, variables) =>
        payload.orderStatusChanged.customerId === variables.customerId
    ),
  },
  newOrder: {
    subscribe: withFilter(
      (root, args, ctx, info) => ctx.pubSub.subscribe(NEW_ORDER)(root, args, ctx, info),
      (payload, variables) => payload.newOrder.storeId === variables.storeId
    ),
  },
};

@Adel-ak unfortunately I don't know why it worked only for newOrder subscription. There can be numerous reasons why. For example if you have some nested resolvers on the result type of createOrder mutation that you ask for when you send this mutation, it could cause event loop to last longer and process the published event. But changeOrderStatus returned only boolean so maybe the function just finished its lifetime and subsequent call to it maybe flushed the event. Hard to say.

In examples there is always await pubSub.publish(...) so I don't think it's necessary to add something to documentation but thank you 🙂 .

Hey..

We use IAM for our auth, and have been using it with this lib for normal queries and mutations without issues. Getting started with subscriptions now, and had to do a little hack to be able to access the IAM info. Thought I'd share it with you in case you find it useful.

I wasn't sure if I could put this info inside connection.data.context, so I just left it in connection.data.identity

The way I am using this is in onConnect, I access the identity data from the connection object, I build my user context, and return it from onConnect, then I have it accessible in the resolvers.

Not sure if that's the most straightforward way to weave the identity data down to resolvers, happy to hear of better ways to do it.

PS: Thanks for the great library, it's saved our team a lot of work and time, and it's just a pleasure to use.

Cheers!

Pepe

Great job, thank you very much!

Thanks for developing such an awesome package for us. I have a stupid question here.

What I want to achieve is that I want to merge this package into our main application which is based on Apollo Server. In your example, the endpoints are all generated from the "Server" class. Question is how could I integate it with Apollo Server, is there any sample?

Thanks CJ

This one should be replaced with this.connectionManager.unregisterConnecition which will delete the connection from Connection store but won't call ApiGatewayManager.

Please format the code with prettier 🙂

I think that it's not possible to return anything in $connect phase. So this should be removed I think.

I think this name is good! 👍

Hey @Adel-ak , please try to append await to pubSub.publish() because it's async and maybe your event loop closes sooner so eventStore won't get a chance to store the event to dynamodb.

Have you checked logs of your functions? I saw this happening in chat app when I deployed buggy version of the server where processing of DynamoDB event stream failed and it caused the stream to pause. Then when I deployed fixed version and published a new message it resumed the stream and the client received all the failed messages + the new one.

It already uses ApolloServer for HTTP requests because Server extends ApolloServer from apollo-server-lambda, for WebSocket connections it extends it with the handler for WebSocket events.

Thank you very much! In that case it seems we need to add a way how to set up a data on connection during $connect phase that can be leveraged for any authorizer. I think your approach is correct but let's do it more "generic" if you agree.

We have onConnect handler already occupied (https://github.com/michalkvasnicak/aws-lambda-graphql/blob/master/packages/aws-lambda-graphql/src/Server.ts#L70). I think it'd be great to add a sentence or two to it's type definition so developers can easily find out when in lifecycle this event handler is called.

Then we can introduce another event handler that can return a data, that will be stored on connection. I'm not sure what name of an event handler to use, maybe onConnectionReceived or something better. Set up connection data in $connect phase only and only if the handler is specified and resolves to {[key: string]: any }.

Could you point me to the documentation where I can verify it? If that's the case, then the problem is that $connect handling does nothing except registers the connection. If we're limited to use it only during $connect then we'd need to provide some sort of handler (like onConnect) that can be called during $connect phase and store something on connection.

I'd appreciate a link to docs and maybe some easy example of how cognito is treated by Apigw for websockect connections.

@jcane86 onConnect is called when server receives GQL_CONNECTION_INIT message from a client (https://github.com/michalkvasnicak/aws-lambda-graphql/blob/master/packages/aws-lambda-graphql/src/Server.ts#L300).

Then if everything is OK, server will return GQL_CONNECTION_ACK (https://github.com/michalkvasnicak/aws-lambda-graphql/blob/master/packages/aws-lambda-graphql/src/Server.ts#L349).

The problem is that Apollo client doesn't wait for ACK if I remember correctly. So maybe the problem is, that your client implementation fires subscriptions or operations in the meantime between INIT and ACK, so your context doesn't have data necessary to perform auth. But in that case you should see errors in logs or receive errors in responses 🤔

@jcane86 Could this have something in common with #71 ? Basically you return some sort of an ID from onConnect that can be used in context to hydrate identity.

The problem is that I don't want to pollute the typings because of that.

Also thank you for kind words, I'm glad this library helps 🙂

It seems that initial mount takes too long especially for components with big style sheet that is extended multiple times.

Closes #639

It seems that Responsive style generator has performance problems with large styles. It makes sense, because the styles are generated for each breakpoint in an app, but the problem is that if component is shared across app, we don't need to generate styles over and over again because the instance is same unless a developer use styles prop or styles function.

We need to find a way to cache styles for same component across whole app and optimise it. For example if I have a Button and I use it on 10 places, I need to generate styles only for first render and then next 9 instance should just use it.

For example combination of ResponsiveDesignSystem + createResponsiveEmotionStyleGenerator seems to be problematic, because resizing of a window can cause recompute because responsive DesignSystem uses window.matchMedia to match current breakpoint, otherwise IsBreakpoint wouldn't work. This causes cache to reset on each change. We need to add check to IsBreakpoint component to warn developer if DesignSystem is not responsive.

We need to find out how to cache styles maybe for each breakpoint without reset? Maybe cache of all breakpoints and reset cache only on theme or styleGenerator change.

Closes #639

Also we maybe should preserve cache if breakpoint is changed and cache per breakpoint and reset whole cache only if theme or generator is changed.

Bumps elliptic from 6.5.2 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li>See full diff in <a href="https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Maybe it could be sufficient to add cache here https://github.com/Byteclaw/visage/blob/5861ae80071720be79b31fe1ef012eebb887b485/packages/visage-core/src/styleSheet/resolveStyleSheets.ts#L16 so if style sheets are not changed at all we'll store the result for a given breakpoint in WeakMap. Another option is to add extra cache for resolveStyleSheet call so at least if the list of style sheet changes, we can skip resolution of already known style sheets.

It seems that maybe caching intermediary stylesheets could help a little. Basically the point is, that if component receives parentStyles, those style sheet can be already resolved so maybe we should cache them in resolveStyleSheet and use the result directly if there is any.

@clmntrss Ok I don't see any problem with optional debug flag. Could you prepare a PR ?

@clmntrss what would you like to log?

It seems that Responsive style generator has performance problems with large styles. It makes sense, because the styles are generated for each breakpoint in an app, but the problem is that if component is shared accross app, we don't need to generate styles over and over again because the instance is same unless a developer use styles prop or styles function.

borderRadius theme setting is applied only to borderRadius CSS prop, but in case we want granular control e.g. borderTopLeftRadius, it's not applied.

For example you have 2 versions of Tabs with different visuals in your app. If you change the looking using face it's impossible to create second version too, because face will apply on both versions.

The solution could be to change API so user can provide custom components like TabNavigationButton, etc.

Hello,

I've been trying over the past few days to get subscriptions working with my application. I set things up like you did in the example and I used Serverless to deploy it to AWS. However, I can't get subscriptions either on the website or testing with playground.

In the dev tools, I can see that it is connecting to the webSocket, and receiving an acknowledgement.

And everything else seems to work. The mutations and the queries.

In DynamoDB, all the tables are being created I believe

But I noticed that the subscriptions table is always empty. There is some activity when it comes to reading but none when it comes to writing.

I'm attaching my serverless.yml, graphql.js (index.js) and also the subscription resolvers.

Serverless.yml

provider:
  name: aws
  runtime: nodejs10.x
  region: us-east-1 # NOTE: change with your preferred region
  memorySize: 256

  iamRoleStatements:
    - Effect: Allow
      Action:
        - execute-api:ManageConnections
      Resource: "arn:aws:execute-api:*:*:*/dev/POST/@connections/*"
    - Effect: Allow
      Action:
        - dynamodb:DeleteItem
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
      Resource: !GetAtt ConnectionsDynamoDBTable.Arn
    - Effect: Allow
      Action:
        - dynamodb:DescribeStream
        - dynamodb:GetRecords
        - dynamodb:GetShardIterator
        - dynamodb:ListStreams
      Resource: !GetAtt EventsDynamoDBTable.StreamArn
    - Effect: Allow
      Action:
        - dynamodb:PutItem
      Resource: !GetAtt EventsDynamoDBTable.Arn
    - Effect: Allow
      Action:
        - dynamodb:BatchWriteItem
        - dynamodb:DeleteItem
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:Query
        - dynamodb:Scan
      Resource: !GetAtt SubscriptionsDynamoDBTable.Arn
    - Effect: Allow
      Action:
        - dynamodb:BatchWriteItem
        - dynamodb:DeleteItem
        - dynamodb:GetItem
        - dynamodb:PutItem
      Resource: !GetAtt SubscriptionOperationsDynamoDBTable.Arn

functions:
  wsHandler:
    handler: graphql.handleWebSocket
    events:
      - websocket:
          route: $connect
      - websocket:
          route: $disconnect
      - websocket:
          route: $default
  eventProcessorHandler:
    handler: graphql.handleEvents
    events:
      - stream:
          enabled: true
          type: dynamodb
          arn:
            Fn::GetAtt: [EventsDynamoDBTable, StreamArn]
  # this one is optional (if you want to support HTTP)
  httpHandler:
    handler: graphql.handleHTTP
    events:
      - http:
          path: /
          method: any
          cors: true
      - http:
          path: /graphiql
          method: any
          cors: true

resources:
  Resources:
    ConnectionsDynamoDBTable:
      Type: AWS::DynamoDB::Table
      Properties:
        # see DynamoDBConnectionManager
        TableName: Connections
        AttributeDefinitions:
          - AttributeName: id
            AttributeType: S
        BillingMode: PAY_PER_REQUEST
        KeySchema:
          # connection id
          - AttributeName: id
            KeyType: HASH
        # This one is optional (all connections have 2 hours of lifetime in ttl field but enabling TTL is up to you)
        TimeToLiveSpecification:
          AttributeName: ttl
          Enabled: true

    SubscriptionsDynamoDBTable:
      Type: AWS::DynamoDB::Table
      Properties:
        # see DynamoDBSubscriptionManager
        TableName: Subscriptions
        AttributeDefinitions:
          - AttributeName: event
            AttributeType: S
          - AttributeName: subscriptionId
            AttributeType: S
        BillingMode: PAY_PER_REQUEST
        KeySchema:
          - AttributeName: event
            KeyType: HASH
          - AttributeName: subscriptionId
            KeyType: RANGE
        # This one is optional (all subscriptions have 2 hours of lifetime in ttl field but enabling TTL is up to you)
        TimeToLiveSpecification:
          AttributeName: ttl
          Enabled: true

    SubscriptionOperationsDynamoDBTable:
      Type: AWS::DynamoDB::Table
      Properties:
        # see DynamoDBSubscriptionManager
        TableName: SubscriptionOperations
        AttributeDefinitions:
          - AttributeName: subscriptionId
            AttributeType: S
        BillingMode: PAY_PER_REQUEST
        KeySchema:
          - AttributeName: subscriptionId
            KeyType: HASH
        # This one is optional (all subscription operations have 2 hours of lifetime in ttl field but enabling TTL is up to you)
        TimeToLiveSpecification:
          AttributeName: ttl
          Enabled: true

    EventsDynamoDBTable:
      Type: AWS::DynamoDB::Table
      Properties:
        # see DynamoDBEventStore
        TableName: Events
        KeySchema:
          - AttributeName: id
            KeyType: HASH
        BillingMode: PAY_PER_REQUEST
        # see ISubscriptionEvent
        AttributeDefinitions:
          - AttributeName: id
            AttributeType: S
        StreamSpecification:
          StreamViewType: NEW_IMAGE
        # This one is optional (all events have 2 hours of lifetime in ttl field but enabling TTL is up to you)
        TimeToLiveSpecification:
          AttributeName: ttl
          Enabled: true

graphql.js

const { tradeTokenForMember, authenticated } = require("./middleware/is-auth");
const {
	DynamoDBConnectionManager,
	DynamoDBEventProcessor,
	DynamoDBEventStore,
	DynamoDBSubscriptionManager,
	PubSub,
	Server,
} = require("aws-lambda-graphql");

const typeDefs = require("./graphql/schema/index");
const resolvers = require("./graphql/resolvers/index");

const eventStore = new DynamoDBEventStore();
const eventProcessor = new DynamoDBEventProcessor();
const subscriptionManager = new DynamoDBSubscriptionManager();
const connectionManager = new DynamoDBConnectionManager({
	subscriptionManager,
});
const pubsub = new PubSub({ eventStore });

const server = new Server({
	// accepts all the apollo-server-lambda options and adds few extra options
	// provided by this package
	connectionManager,
	eventProcessor,
	resolvers,
	subscriptionManager,
	typeDefs,
	playground: {
		endpoint:
			"******/dev/graphiql",
		subscriptionEndpoint:
			"******/dev",
	},
	context: async ({ event, lambdaContext }) => {
		let token = null;
		let currentMember = null;
		console.log("Set token for context");
		try {
			token = event.headers.Authorization;
			if (token) {
				currentMember = await tradeTokenForMember(token);
			}
		} catch (err) {
			console.warn(`Unable to authenticate using auth token: ${token}`);
		}
		return {
			token,
			currentMember,
			pubsub,
			headers: event.headers,
			event,
			lambdaContext,
		};
	},
});

module.exports.handleWebSocket = server.createWebSocketHandler();
module.exports.handleHTTP = server.createHttpHandler({
	cors: {
		origin: "*",
		credentials: false,
	},
});
// this creates dynamodb event handler so we can send messages to subscribed clients
module.exports.handleEvents = server.createEventHandler();

resolver

	Subscription: {
		onNewRequest: {
			//! Will need WithFilter here to filter for only "Processing transactions"
			resolve: (rootValue) => {
				return rootValue;
			},
			subscribe: (rootValue, args, ctx, info) => {
				ctx.pubsub.subscribe(TRANSACTION_SUBSCRIPTION)(
					rootValue,
					args,
					ctx,
					info
				);
			},

Please let me know if you need more info

P.s. I'm a self proclaimed noob so please let me know if my logic is wrong

I haven't found any error in your repository in server package. I haven't tested it because it relies on Mongo so it's not really something I can just quickly run.

The error logged in your logs can be caused by invalid parsing of GraphQL operation so it would be helpful to see a JSON operation that is being sent when the client is subscribing to some subscription. The problem happens in execute function which is called in web socket handler created by server.createWebSocketHandler(). If you can send a mutation or query and get correct result then the problem is in subscription operation. So I'd try sending some test query and mutation over websocket if the server returns correct response.

But as I said, I don't think this is a problem with aws-lambda-graphql library. So I'm closing this unless you provide me with some minimum repository that I can run without any problem.

What version of aws-lambda-graphql do you have? Can you upgrade to 1.0.0-alpha.13 because as I wrote above, versions alpha.10-12 are deprecated because of an error in headers processing.

If that won't help, can you provide a minimal project repository? But I don't think this is a problem with aws-lambda-graphql. There must be something else going on in your code.

I need to see how you publish events, and if you can, provide CloudWatch logs of websocket lambda handler after client subscribes, because if you don't have subscriptions in your table, an error should occur on subscription.

@jurajhrib there is an interesting package https://react-spectrum.adobe.com/react-aria/index.html and they have focus ring and other accessibility features solved by hooks, maybe it would be beneficial to take a look on their implementation, if we can use their package or just get inspired.

After #97 it stopped working because the header is not always present.

Closes #100

Closes #100

After #97 it stopped working because the header is not always present.

Error in your logs can be caused by this line https://github.com/michalkvasnicak/aws-lambda-graphql/blob/master/packages/aws-lambda-graphql/src/execute.ts#L97 which means that operation you sent is malformed.

But I'd need more information. Is it caused by sending a mutation or does it happen when you're trying subscribe?

How do you test it ? Could you please explain client side steps you do in order to test your server implementation? Because I don't see any problem with the server code you provided.

Reverts the behaviour of using effect to detect breakpoints with matchMedia otherwise SSR hydration is broken.

Reverts the behaviour of using effect to detect breakpoints with matchMedia otherwise SSR hydration is broken.

Closes #634

Closes #634

Closes #632

Basically we want to detect current breakpoint sooner than useEffect but we want to unregister listeners on unmount.

Closes #632

Basically now we're relying only on Typescript typecheck but some users are using Javascript so it'd be good to have native validation for options in constructors.

Ok I found a problem, you need to pass SubscriptionManager to ConnectionManager in subscriptions option (https://github.com/michalkvasnicak/aws-lambda-graphql/blob/master/packages/aws-lambda-graphql/src/DynamoDBConnectionManager.ts#L38).

Just change:

const connectionManager = new DynamoDBConnectionManager({
	subscriptionManager,
});

to

const connectionManager = new DynamoDBConnectionManager({
	subscriptions: subscriptionManager,
});

I think you should have errors in cloud watch logs for your function.

Thank you, good work :)

Removing multiValueHeader not compatible with web-socket and might be source of error in the code.

I should had remove it in the last PR

PR following the modifications you made after the issue about returning empty Sec-Webprotocol (#93)

The changes you made throwed a new error that made the problem a little more understandable.

Looks like it's not possible to return a few headers even if you receive multiple. Server has to chose only one protocol he wants to give back to the client.

I think "graphql-ws" is the best to return since you need to use it in subscription-transport-ws

https://github.com/apollographql/subscriptions-transport-ws/blob/0e81e9e45929db2f4d2699cf34229fb4cb2144e8/src/protocol.ts#L1

Error received on Chrome : Error during WebSocket handshake: 'Sec-WebSocket-Protocol' header must not appear more than once in a response