Can confirm

fixed it.

Confirm the fix 👍

Or I guess I can just use use-config with an empty map and define a config var in the file.

Although it seems doing that, the :merge [:prod] functionaltiy doesn't work.

This might help! You probably have a repl.clj file that has a function called something like get-sys or get-context (I think my version is a bit out of date, so I'm not sure what it's called these days.) That'll summon up all the config stuff without going through any handlers. It's basically just calling biff/assoc-db on the system atom from your main file. That system atom might be what you want, but if you're going to do anything with the database, the assoc-db makes sure you're working with the most recent version of it.

no need to use get-context; that's just meant for repl usage. I'm pretty sure what you'll want to do is create a "biff component" function, like use-aws, and stick it in your app's component list somewhere after the use-config component. the contents of your config are merged into the map that gets passed to all the component functions. so you can do something like this:

(defn use-aws [ctx]
  (let [access-key (get ctx :aws/access-key)]
    ...
    ctx)

thanks for the replies! Yeah @U7YNGKDHA I think I'll do this since it seems more consistent with the design of biff in general. What are the advantages of this componentized approach?

the biggest reason I went with this is because it means you can easily move components between app code and library code without making changes. I.e. all the biff/use-* components are just regular functions that operate on only their input arguments; they don't depend on any global vars, which is necessary since they're kept in library code. even for your own custom components that you have no plans of moving into a separate library, I think it still makes sense to stick with "pure"-ish components for a few reasons: • it's consistent with the design of biff's default components ¯\_(ツ)_/¯ • when you're debugging something, you know the entire "world" is contained within the context map; no need to think about any global vars • it's easy to create mock/alternate versions of stuff for E.g. testing. just pass in whatever you want, no need to rebind global vars or anything. • another one I just thought of that might be the most important: it keeps your functions' dependencies more explicit. if a function needs access to the system map/stateful resources, you have to pass those things to the function explicitly. you won't get any surprise "utility" functions that are secretly making database calls.

thanks for the breakdown 🙂

yeah, you can just call xt/start-node directly. biff/start-node is just meant to make a couple cases (filesystem storage and jdbc storage) more convenient.