This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-06
Channels
- # babashka (19)
- # beginners (68)
- # calva (9)
- # cider (27)
- # clj-kondo (64)
- # clj-on-windows (2)
- # cljdoc (8)
- # clojure (11)
- # clojure-europe (58)
- # clojure-italy (1)
- # clojure-nl (23)
- # clojure-uk (5)
- # clojurescript (9)
- # cryogen (18)
- # cursive (14)
- # data-science (17)
- # emacs (6)
- # gorilla (6)
- # graphql (1)
- # gratitude (2)
- # holy-lambda (10)
- # introduce-yourself (1)
- # jackdaw (3)
- # jobs (1)
- # leiningen (2)
- # malli (3)
- # missionary (33)
- # off-topic (21)
- # pedestal (7)
- # polylith (8)
- # quil (3)
- # random (1)
- # releases (1)
- # remote-jobs (7)
- # shadow-cljs (18)
- # specter (1)
- # sql (8)
What does the request look like when I have an apigateway for my Lambda where something get's posted to? Is there a :body key? And is that already clojure data? (input is json)
Right. Maybe HL should automatically parse the body?
@U01RXDR9F4M @U0510KXTU what do you think?
a generic body parser could get complex since there are a lot of different content-types. I don’t think it’s a big win in the HL feature set compared to other ideas on the roadmap
This is probably important for the consistency. HL already auto deserializes the edn & json. Parsing these content-type in body is probably sufficient for 99% cases.
But I will not include it in next release for sure. To much stuff is already in the Changelog.
And I have to make sure this change will be compatible with the ring specification.
> a generic body parser could get complex since there are a lot of different content-types. I don’t think it’s a big win in the HL feature set compared to other ideas on the roadmap +1 I’m happy with the current behaviour. Maybe add something to the docs on what to expect for some common AWS services.