Clojurians Log v2

I was wondering if it would make sense to call the :components key simply :parts to avoid confusing it with the stuartsierra/components. the benefit of having something shorter is also the ability to provide functions like:

(ns some.app.feature)

(defn parts [some typical params]
  {:some-part {:start `(...)}
   :other-part {:start ...}})

then at some entry point namespace - eg tests -, u can assemble a system, like:

(def clip 
  {:executor ... 
   :parts (merge (some.app.feature/parts 1 2 3)
                 (other.app.feature/parts :a :b :c))})

if im reading the description of a system from an edn file, am i supposed to specify the executor there too? i have the impression that this top-level {:executor ... :components ...} structure is unnecessary noise (at this stage at least). i could imagine that we call the "part configuration" of the various subsystems *clip*s. then we can combine multiple clips into a bigger clip. if we start a clip, we get back a system. so interaction with a bigger system would look like:

@(def clip (merge (company.feature-1/clip 1 2 3)
                    (company.sub-system-2/dummy-clip :x :y)
                    (company.db/in-mem-clip)))
  @(def sys (clip/start clip optional-executor))
  (clip/stop clip sys))

we can also carry the executor info with the system config map as meta data:

@(def sys (-> clip (with-meta {:executor non-default-executor}) clip/start))

This seems like a good idea.

I want something more visible than metadata for this. I think when you look at a system (print it, throw it, whatever) it should be very clear that something is changing the execution flow.

I really want users to specify their required executor. You can merge components or parts together separately ofc.

what do u mean by system here, the config or the return value of (clip/start)? isn't the execution flow determined by the dependencies between parts in the 1st place? just by looking at a system, that's not super clear anyway, regardless of the executor. i was just wondering a few minutes ago how can i check who depends on what, because my system is getting hairing already.

this lib is pretty nice for component: https://github.com/walmartlabs/system-viz has anyone looked into adopting it for juxt/clip?

this is a pretty clear view of the system dependencies:

(-> clip :components (#'clip/safely-derive-parts []) first)
=> {:config #{}, :aws/credentials-provider #{:config}, :aws/ssm #{:aws/credentials-provider}}

You're right, I mean system config :) I'll blame morning brain (but really I'm just loose with the terminology). In one sense, you're right. But the sequencing between those dependencies is potentially done in a variety of ways. One major clip goal is to make the system really explicit.

The temporary answer now is that you could write an executor that prints out the order which things are running. Alternatively, there's some functions in the impl namespace for creating the dependency graph.

This seems like something worth exposing as a public API though.

I think, but am not certain, that you could feed clip's dependency graph straight to rhizome.

Maybe even to loom.

Yeah, open to a dependency graph function which returns a data structure like that

I have a strange behaviour with bidi which I can't quite explain

one route works fine locally but not in prod (so after the uberjar/docker magic)

however if in the repl I do (bd/match-route routes "/loans") it actually returns not-found, so it would seem it doesn't work locally either

anyway the question is simply if anyone is aware of potential issues that can occur after uberjar but not during local dev, before I dig further to understand what's going on

Bidi itself is pretty agnostic to all that.

mm yeah makes sense, so I think locally it works thanks to some other magic, the thing which makes it a bit more complicated is that routes are in a cljc file. SPA routes are merged with server only routes in the api.clj ns, but then the routing is done also in the SPA directliy

so well probably some other magic going on there, I'll have a look. if in the repl match-route doesn't work it means the route definition is just wrong I guess