This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-21
Channels
- # aatree (88)
- # admin-announcements (14)
- # alda (26)
- # announcements (4)
- # avi (6)
- # aws (7)
- # beginners (80)
- # boot (268)
- # braid-chat (58)
- # cider (4)
- # clara (54)
- # cljs-dev (16)
- # cljsrn (27)
- # clojars (13)
- # clojure (123)
- # clojure-chicago (2)
- # clojure-czech (8)
- # clojure-france (5)
- # clojure-hamburg (2)
- # clojure-miami (6)
- # clojure-nl (5)
- # clojure-russia (285)
- # clojure-spain (2)
- # clojurebridge (3)
- # clojurescript (137)
- # code-reviews (14)
- # community-development (6)
- # core-async (8)
- # core-matrix (10)
- # cursive (2)
- # datascript (1)
- # datomic (24)
- # dirac (2)
- # emacs (5)
- # hoplon (4)
- # incanter (6)
- # jobs (7)
- # ldnclj (42)
- # ldnproclodo (2)
- # leiningen (1)
- # mount (60)
- # off-topic (15)
- # om (134)
- # onyx (65)
- # perun (4)
- # portland-or (2)
- # proton (15)
- # random (1)
- # re-frame (24)
- # reagent (7)
- # testing (4)
- # yada (9)
@cfleming: Thanks for the link. I wouldn’t say it’s totally unusable, but it doesn’t seem like it’s suitable for something where you’d need realtime performance unless it’s kept warm.
But also, if one needs consistent API performance while keeping a low monthly cost, Linode and Digital Ocean are damned cheap. For something that’d fall under lambda’s free tier, they’d probably suffice.
I see lambda as more appropriate for something where I don’t necessarily care about realtime performance - say, firing lambdas off events for processing something - or where you need to be able to scale a particular function without having to care about provisioning capacity in advance.
@ricardo: Right, but it’s a bummer that it’s so badly suited to the use case that I wanted to use it for.