New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Http Error messages #64
Comments
For the unexpected 'E', don't you minify the code? Great to see an improvement in error tracking though. |
The error is from the response returning a string instead of JSON via the |
Hello (again 😊) @DavidWells! Thanks for the interesting input. Honestly it's my first time seeing the JSON API standard. It sounds pretty interesting but i would like to understand more all the implications before deciding whether it makes sense to adopt it by default in Middy or not. Regarding our API gateway integration we prefer to use the Lambda proxy as well, as it makes easy to create standard middlewares and integrates well will the serverless framework. Also, regardless the JSON API spec, error reporting and response serialization are a bit of open discussion at the moment. I would love to find an easy way to keep them separated for higher flexibility (imagine an API that can support both JSON and XML based on the client accept header). So, if you have any thought or ideas on this i'd love any input 😉 |
So maybe checking if If I'm open to open shapes of errors as well. There wasn't much concensus on how json apis should return errors in a standard way https://stackoverflow.com/questions/12806386/standard-json-api-response-format Maybe @theburningmonk has some insight here? I'm keen on making some tracing and logging middleware for middy =) |
Hi @DavidWells thanks for the nudge! My personal feeling is that, as a default behaviour, we shouldn't readily return so much error details in the response, they often leak implementation details unwillingly, I have even seen errors that returns the IP address for redis/mongo servers (which wasn't secured... 😞). It's great for debugging our endpoints, for us and for attackers probing our system. Usually I approach error handling in roughly like this:
|
As for handling different content types, keep in mind that we might want to consider binary formats as well. What if you always inspect the content-type in the response, and defaults to JSON if it's not specified, and bundle only JSON handling in middy by default. You can then later introduce XML, proto-buf and other formats as middleware? (in the case of protobuf, you also have to set the |
Great to see this discussion happening :) Thanks @DavidWells for having started it and to @OlzhasAlexandrov and @theburningmonk for the valuable contribution. My current feeling is not to use the JSON API spec by default (even though it might make sense to have some level of support with dedicated middlewares). Also, I would love to be able to have a generic concept of output serialization (which should work also for errors of course). In code I would imagine this like the following: const handler = middy((event, context, cb) => {})
handler
.use(jsonSerializer())
.use(jsonAPISerializer())
.use(xmlSerializer())
.use(protoBufferSerializer()) Every one of those serializer middlewares should check if the Or probably it would be easier to implement something like this: const handler = middy((event, context, cb) => {})
handler
.use(outputSerializer(
[
jsonAPISerializer(),
xmlSerializer(),
protoBufferSerializer()
]
)) This is something supported in many other web frameworks, so maybe we should take inspiration from the APIs of a famous one (i am of course open to suggestions). Thoughts? |
Hey @DavidWells, based also on #94, I was trying to understand better this error case and see if it can be addressed somehow, but I wasn't able to fully reproduce the issue. Can you please post your full code snippet to help me reproduce this case? Thanks |
I came here after dealing myself with the same error pointed out by @DavidWells when implementing my custom error handling middleware. I ended up almost copying his solution to correctly follow the JSON API spec. At least for the lambda proxy integration, the error response should change the body format or the content header, otherwise the response is not valid... PS: Awesome work guys! I LOVE this project |
Hello @jacintoArias and thanks a million for your feedback. Recently we added the http content negotiation middleware to middy. Based on that I am (very very unfortunately) working on a response serializer that should help with having a more cohesive and flexible experience on how we manage responses (including error ones). Regarding the JSON API spec, if you feel as well it's something very common, I would be more for creating a dedicated middleware (e.g. |
In the end is just a matter of specific use cases vs common patterns, guess is better to wait for the community to grow (I am sure it will grow!). Right now I have "middified almost everything in my lambdas". Following @theburningmonk advices above I have created a set of custom errors for my libraries (data layer, services), that break the execution chain and are handled by a set of error middlewares. I love the idea of using
I would be nice to have access to other patterns and use cases from other users (perhaps a gitter channel or is too early?). I would watch the repo and see if I can PR something ;) |
Just stumbled upon a similar problem because at least with |
@DavidWells @jacintoArias Have you tried https://github.com/willfarrell/middy-jsonapi, I've been using it for about 2y now without issue. |
Hi guys, just followed the discussion here, and the @willfarrell middleware seems to be the right way of implementing JSON api specs in your lambdas. |
BTW here's the middleware I ended up writing: |
I altered the
httpErrorHandler
to follow the JSON spec http://jsonapi.org/examples/#error-objects-basics.Should this change get applied across the board? Or should I just use this as my own custom middleware?
Whats the default lambda integration you guys are using? (we typically use
lambda-proxy
as the serverless framework default)Here is my altered error handler for nice errors =)
It looks like:
Before with
body: handler.error.message
(no json response)Love this freakin project! Great work 🎉
The text was updated successfully, but these errors were encountered: