This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-09-13
Channels
- # announcements (15)
- # babashka (48)
- # beginners (5)
- # biff (4)
- # calva (3)
- # cider (10)
- # clerk (16)
- # clj-kondo (6)
- # cljdoc (20)
- # cljs-dev (13)
- # clojure (117)
- # clojure-argentina (1)
- # clojure-brasil (5)
- # clojure-europe (40)
- # clojure-nl (1)
- # clojure-norway (111)
- # clojure-uk (5)
- # clojurescript (16)
- # cursive (20)
- # datascript (2)
- # datomic (106)
- # etaoin (2)
- # events (3)
- # funcool (1)
- # graphql (1)
- # helix (8)
- # hyperfiddle (36)
- # leiningen (12)
- # matrix (1)
- # nrepl (1)
- # off-topic (61)
- # other-languages (10)
- # polylith (22)
- # practicalli (1)
- # reagent (28)
- # reitit (11)
- # remote-jobs (3)
- # ring (12)
- # shadow-cljs (109)
- # slack-help (6)
- # solo-full-stack (23)
- # squint (7)
- # xtdb (11)
What are best practices if I have a good amount of images and image sources. Some people say put them in repo, or maybe a submodule, or manage independantly… If I put them in my primary repo, I am concerned this will slow dow push/pull and mess with the develop in prod feature. (or is that moot since it uses rsync by default now?)
develop in prod has always used rsync, the difference is that now normal deploy also uses rsync. either way, both git and rsync will only push images the first time; you shouldn't have any problems there. the main thing is just the first time you clone on a new machine/push to a new server might be slow. Either approach is probably fine. as advantage of putting them in s3/digitalocean spaces etc is that the images will already be in a cdn, whereas if you put them in the repo and serve them with your biff app they'll load a bit slower for users.
though it's pretty easy to use E.g. https://images.weserv.nl/ to use your biff app as an origin for images and then cache/serve them through a cdn. so in conclusion, eh 🤷
Thanks. That was helpful. Good to know there are plenty of options, but the defualt is sufficient!