Feature/support api gateway proxy events #52
Conversation
…ure in place, still compile errors. Hi-jacked simple example and needs to be restored.
… the default Runtime and the ApiGatewayRuntime.
…est into a more usable structure.
…-y, so there's no need to a have a Raw vs Haskell-y type.
…eString, requiring the handler to decode it.
…tent types into the body field of the JSON returned in an ApiGatewayProxyResponse.
…SON for a API Gateway proxy response.
… This needs its own custom example though.
…s a parameter to the ApiGatewayProxyRequest.
…of which are optional)
…y fill in the type parameter for the typical case where there isn't one.
| v .: "apiId" | ||
| parseJSON _ = mzero | ||
|
|
||
| -- TODO: Should also include websocket fields |
There was a problem hiding this comment.
Created a card here: #53
Other than adding the fields, is there anything else we need to support websockets from apig?
There was a problem hiding this comment.
So this is a bit of an odd one. The more I think about it, the more I think that this should be a separate event that maybe has some common models (Identity ab RequestContext maybe). But ultimately it makes a bunch of fields optional if we try to do them together. Which makes sense for JSON, but less so here—where we want to strongly type and communicate guarantees wherever possible.
The downside of the separate is a bunch of boilerplate. The record field destructuring is super useful for these types, but it doesn’t seem to compose for reuse very nicely.
There was a problem hiding this comment.
I'll have to chew on this one a bit more before responding more completely
| instance FromJSON a => FromJSON (ProxyRequest a) where | ||
| parseJSON (Object v) = | ||
| ProxyRequest <$> v .: "path" <*> | ||
| (toCIHashMap <$> (v .:? "headers" .!= mempty)) <*> |
There was a problem hiding this comment.
I'm slightly surprised there's no constructor that implicitly provides mempty 🤔
There was a problem hiding this comment.
That’s actually a really good point... I wonder if I missed one (or if PRing one in even makes sense).
There was a problem hiding this comment.
I skimmed the aeson docs but couldn't find anything that required a monoid instance :/ could be worth contributing a new operator/fn?
There was a problem hiding this comment.
Given:
Prelude Data.Foldable> :t fold @Maybe
fold @Maybe :: Monoid m => Maybe m -> m
Does toCIHashMap . fold <$> (v .:? "headers) do what you want?
…structors and header-modifiers to make this easier.
…o fix missing export of genericBinary.
…orted as (non-breaking) versions change.
|
Alrighty, I think I'm finally happy with this interface. I think this is the right balance between "looking like" the AWS examples while still leveraging types, smart constructors, and helpers to hide a lot of the uglier details. |
|
Question: what is the goal of the |
@endgame , It's a good question, and I'm not sure I've got a totally solid answer. I don't think it's strictly a low level handler, otherwise we would not have provided combinators and a plethora of different runtimes to choose from. I also don't think it'll be a comprehensive toolkit, because there's simply too much ground for this to cover. I think either we support all official AWS events or we break all common events out into a separate module(s). And I probably lean further towards the latter. However, I also think that many people literally do not realize that Lambda /= Api Gateway Lambda HTTP APIs. The micronaut + Graal runtime for example, doesn't even support any other events (which seems crazy to me). So this event type is so core many people's thinking of Lambda, that I'm not too afraid to include it here--even if it's one of the very few to ever make it in. In the future, I think one option is to use a separate library, move everything over, and then simply re-export it all here for backwards compatibility. That seems like a manageable approach going forward. Curious if you've got other thoughts or concerns though :) |
Heh, yes. I've had this problem in other contexts, where overly-"helpful" libraries have made it really hard to work with other event types.
Split-when-necessary seems like a fine approach, and if you ever want to pare back the re exports you can do it with a major version bump. One thing I've seen a couple of times: a project starts with |
…orizer value is present.
No description provided.