@stuartsierra: Phew... it finally clicked. Both the production/development distinction as well as the web example helped a lot. Part of the problem was that I was caught between my previous MO, where I would start in core.clj and call out to web.clj and db.clj etc. to manage state and procure dependencies, and the 'component' way. My mistake was that after starting a couple of things via the 'component' library, I wouldn't know how to interact with individual components from my global state in core.clj (and in the other files). It was only after I realized that components call out to other parts of the app (and pass down dependencies), and not vice versa, that everything clicked. It also took the better part of a minute for me to get around the defroutes macro not taking any arguments (such as the db component) and that I had to use routes instead. I guess defroutes by way of its "def" suggests a top-level usage.

I think the following part of the documentation is crucial (I'd read it, but only now do I understand it): > First and foremost, this framework works best when all parts of an application follow the same pattern. It is not easy to retrofit the component model to an existing application without major refactoring. > > In particular, the 'component' library assumes that all application state is passed as arguments to the functions that use it. As a result, this framework may be awkward to use with code which relies on global or singleton references.

My code is now running with 'component'. I think next I'm also going to put the handler in its own component, like @sveri does in closp. Anyway, thanks a lot for the library and for the explanations. 😃

@francoiswirion: Funny, that was one of the things that struck me too. And it was the first time I understood why macros should be used as least as possible. Especially in libraries used by other developers as part of the API.

@sveri: Good point.