https://serverless-stack.com/ logo
Join Slack
Powered by
is anyone here by any chance using `middy` for API...
# help
s
is anyone here by any chance using 
middy
for API request validation? for some reason, invalid API calls (missing required params) are being passed to the underlying Lambda code
d
using middy with their middy validator
Copy code
lambda.use(
        validator({
          inputSchema: validators.inputSchema,
          ajvOptions: {
            strict: false,
            useDefaults: false,
          },
        })
      );
I haven't seen AJV (used underneath the hood) passing through bad requests when we have the proper 
"required": ["field_one", "field_two", ...]
in our openapi schema
s
it works for POST requests, but not GET. still diving into why..
wait, no.. it works for another endpoint that’s a GET. ok, it’s something else then
ahhh nvm, got it
had to make 
queryStringParameters
required too, in case NO params are sent
Copy code
const schema = {
  type: 'object',
  properties: {
    queryStringParameters: {
      type: 'object',
      properties: {
        item_type: { enum: ['TRACK', 'VIDEO', 'IMAGE', 'REEL'] },
      },
      required: ['item_type'],
    },
  },
  required: ['queryStringParameters'],
} as const;
a
@Sam Hulick why not using Class Validator?
It’s better for schema definition.
If you using typescript.
Not sure what you using.
s
not familiar with that. I’m using 
middy
w/ its 
httpValidator
middleware
which uses JSON schema
d
what's class validator? i use generate a json schema as well for input. And separately have a tool that outputs the type defs for input and outputs.
a
This is what NestJS uses, I’m using it for other APIs (not serverless).
It’s similar to Joiful.
Also Joi it’s pretty interesting, the foundation for Joiful.
s
I’m using middy just because it’s super easy as a middleware.. I just wrap my Lambda function in it and it handles everything including JSON parsing. e.g.
Copy code
return middy(lambdaHandler).use(httpValidator({ inputSchema: schema })).use(...)
a
@Sam Hulick you using TS? I don’t want to define schemas, I want to define classes.
s
yeah, using TS. the JSON schema is converted internally to TypeScript so it’s fully type aware of what values are being passed in via the HTTP request
a
Hum, interesting.
But your schema above, is not typed.
s
magic 🙂
a
Why you have to put this sintax? 
type: 'object',
? Isn’t better just define a Class?
s
it’s JSON schema
a
Yeah but it’s too magical in my opinion.
I see.
s
a
Yeah I know json schema.
s
ahh ok
a
I was trying to avoid it.
🙂
But yeah now makes sense.
With class-validator and class-tranform it’s all TS code.
You can extend and many other advantages of classes.
d
assuming you only want to use ts
a
With JSON schema it’s harder.
s
for sure. as you can see, I had to do 
as ItemType
to convert it to an actual enum
a
This is the other lib which plays well with class-validator: https://github.com/typestack/class-transformer
Yeah, but doesn’t feel right to me, when we can have all the power of classes.
And types, all built in.
Of course, if you not using TS, then makes sense.
I’m planning to use Middy too, but for SSM and Epsagon (ideally).
a
@Sam Hulick use the http-event-normalizer middy package to ensure that queryStringParameterss and pathParameters are always present.
s
they won’t & shouldn’t always be present though
a
Yes, the point is that if they’re not it’ll be an empty object otherwise it’ll have those params. it helps avoid being verbose in the handler because you can validate the params in the http-validator step.
Open in Slack
PreviousNext
Powered by