This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-08
Channels
- # announcements (22)
- # aws (4)
- # babashka (25)
- # beginners (78)
- # calva (9)
- # cider (22)
- # cljdoc (2)
- # cljsrn (2)
- # clojure (27)
- # clojure-australia (7)
- # clojure-europe (22)
- # clojure-nl (15)
- # clojure-uk (26)
- # clojurescript (20)
- # datahike (3)
- # datomic (15)
- # events (1)
- # helix (5)
- # honeysql (4)
- # kaocha (1)
- # malli (1)
- # meander (1)
- # off-topic (84)
- # pathom (14)
- # re-frame (3)
- # reagent (28)
- # reitit (6)
- # sci (1)
- # shadow-cljs (78)
- # tools-deps (30)
I assume what and how many lambdas one should configure is mostly function of the processing power of that lambda. E.g given a webserver where all routes are relatively the same (simple gets, puts, etc..) it would be approprate to simply have one lambda given instances of it are created on demand. Where it would make sense to have two different lambdas, is when they handled vastly different loads. E.g i wanted to spin one up with twice the ram. Given that, is it reasonable that all my websocket handlers (connect, disconnect, default, custom) with a similar load, all go to one handler function and i just use polymorphic dispatch?
I think the more common pattern would be to put all your lambdas behind an API gateway api, and then just let API gateway handle the routing. That way you avoid having a dispatch lambda that invokes other lambdas
@USDPTD3FY I agree, i plan on using API gateway protocals/fns to route to a single lambda.
this is what i'm using to guide my understanding of how to think about lambdas https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html