When I add integration: lambda and authorizer it is throwing TypeError: event.path.endsWith is not a function error
graphql:
handler: handlers/graphql/handler.graphqlHandler
events:
- http:
path: graphql
method: post
cors: true
integration: lambda
authorizer:
arn: arn:aws:cognito-idp:${env:COGNITO_USER_POOL_ARN}
claims:
- email
- nickname
- http:
path: graphql
method: get
cors: true
As per my observation, without integration lambda and authorizer, I get event.path = {} whereas nornally it is '/
dependency:
"apollo-server-lambda": "^2.22.2",
"serverless": "2.31.0",
handler:
const { ApolloServer } = require('apollo-server-lambda');
import { dbConnect, models } from '../../db';
import { default as typeDefs } from '../../graphql/types';
import { default as resolvers } from '../../graphql/resolvers';
const createHandler = async () => {
const db = await dbConnect();
const server = new ApolloServer({
typeDefs,
resolvers,
context: { models, db }
});
return server.createHandler();
};
export const graphqlHandler = (event, context, callback) => {
createHandler().then(handler => handler(event, context, callback));
};
Expected:
Should not break with TypeError: event.path.endsWith is not a function error
Hmm. I think we need to do a better job of understanding in all cases what the event object provided to Lambda is.
That said, at this point I'm leaning pretty strongly towards getting out of the business of slowly reimplementing @vendia/serverless-express and am more excited by the prospect of an Apollo Server 3 where Lambda users combine apollo-server-express with that package, rather than Apollo Server having lots of Lambda-specific knowledge embedded in it.
I mean I can just change the event.path.endsWith line to event.path?.endsWith but where does it end? There's lots of parts of this file that want to know what the path is.
I'm getting the same issue with apollo-server-lambda "^2.22.2"
fyi, can fix this by aliasing event.path to event.rawPath
there are only two possible payloads for API Gateway Lambda and they are documented here: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html
@brianleroux Thanks, that's helpful.
apollo-server-lambda is largely authored by external contributors who actually use Lambda, but that does mean that it's challenging for us to review changes as non-Lambda experts (which is why I'm hoping to remove most of the complexity from this package soon).
It looks like what your link says is that there are two API Gateway lambda payload versions, and the current code only supports version 1.0. This seems like something I can plausibly fix today and get into v2.23.0 which should be out today or Monday.
awesome, thank you! appreciate it. 馃檹
@brianleroux I can't find any docs explaining the difference between rawPath and requestContext.http.path in payload 2.0. Do you have any idea what the difference is? (Perhaps something around escaping or fragments or query strings or something?)
@brianleroux I'm using requestContext.http.path and it's working! Thanks for the tip!
@brianleroux I can't find any docs explaining the difference between
rawPathandrequestContext.http.pathin payload 2.0. Do you have any idea what the difference is? (Perhaps something around escaping or fragments or query strings or something?)
@glasser threw up a couple of greedy endpoints that echo the request for testing:
http apis v2 payload: https://music-oib-staging.begin.app
rest apis v1 payload: https://cbwrnzqkm8.execute-api.us-east-1.amazonaws.com/staging
I think looks like they are consistent / but verify!
I've released a prerelease with this fix, version 2.23.0-alpha.1. Try out the alpha and see if it works for you! Please provide any feedback in #5094.
(as a workaround you can also switch your setup to using payloadFormatVersion 1.0)
This is released in Apollo Server 2.23.0.
Thank you!
Thank you guys
Most helpful comment
@brianleroux Thanks, that's helpful.
apollo-server-lambdais largely authored by external contributors who actually use Lambda, but that does mean that it's challenging for us to review changes as non-Lambda experts (which is why I'm hoping to remove most of the complexity from this package soon).It looks like what your link says is that there are two API Gateway lambda payload versions, and the current code only supports version 1.0. This seems like something I can plausibly fix today and get into v2.23.0 which should be out today or Monday.