This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-13
Channels
- # bangalore-clj (1)
- # beginners (40)
- # boot (22)
- # clara (19)
- # cljs-dev (265)
- # clojure (160)
- # clojure-dev (6)
- # clojure-italy (5)
- # clojure-russia (47)
- # clojure-spec (10)
- # clojure-uk (63)
- # clojurescript (88)
- # core-async (8)
- # cursive (54)
- # datomic (48)
- # emacs (32)
- # garden (3)
- # graphql (29)
- # hoplon (54)
- # jobs (1)
- # klipse (4)
- # luminus (5)
- # lumo (21)
- # mount (5)
- # off-topic (16)
- # om (2)
- # pedestal (10)
- # play-clj (1)
- # portkey (32)
- # re-frame (21)
- # reagent (48)
- # rum (1)
- # spacemacs (4)
- # sql (3)
- # unrepl (5)
@spieden As you may have noticed portkey is very very young. We share the goal of “transparent local dev -> serverless deployment”
for my use case it really doesn’t matter, as step functions state machines are long running
we have a tree-shaker, for now it doesn’t cover clojure.jar, but with time, love and care it could be robust enough to remove unneeded stuff from clojure and yields fastest startups
if you wat to experiment you’ll have to dig in the code to use deploy!
rather than mount
(which has api gateway stuff)
so the tree shaking only covers the clojure code i’m guessing — are all bytecode jars on the classpath included?
basically kryo and clojure are left untouched (plus a couple of classes and namespaces), everything else is shaken
hadn’t encountered kryo before. only JVM slimming i have previous experience with is a little ProGuard
so have been tossing at @cgrand this puzzle of a parquet->avro conversion which shrinks from 90MB jar to 5MB, but as said, there are some things to cover still :)
loading resources/classes based on runtime information is the basic dilemma, more actual use of portkey would help to see what is most important to cover
Compared to ProGuard which shake classes, we shake an object graph rooted at the closure we want to deploy to Lambda
hmm, your portkey.core/as-doto*
is very similar to our bean-dip lib except w/ reflection =) https://github.com/uwcpdx/bean-dip/
spieden: it’s only called during macroexpansion and that’s true than we could certainly get away without reflection at all
ah i see. i didn’t think of that approach for some reason — just went purely on naming convention and let *warn-on-reflection*
catch missing methods
The restriction to vars is specific to mount
and temporary. deploy!
can turn any function even a closure into a lambda.
starting from a live graph of objects gives us an edge over ProGuard (especially when it comes to clojure code) as we have more information
The restriction to vars is specific to mount
and temporary. deploy!
can turn any function even a closure into a lambda.