Hi Sven,
I'm pretty sure that the purpose of Stuart's component library is precisely
to capture these dependencies in your application, but to do so in a
uniform, safe way which isolates the coupling to a small number of
declared, explicit cases of mutual knowledge.
In the case of the design you're presenting, it seems your problems might
stem from incompletely implementing this philosophy (or possibly
misinterpreting the example code).
The first part seems correct to me, where you have constructed a system map
and declared the dependencies. The second part is where the problem appears
to be:
(start [component]
(let [db-conn (get-in web-app [:database :db-conn])]
(assoc component :server
(run-server (make-handler web-app db-conn) {:port
port}))))
There are a number of issues here. First, this code is (or is supposed to
be) the "start" part of the Lifecycle protocol for a WebApp record,
represented as 'component' in this code. So, just fixing that, your code
should be:
(defrecord WebApp [database scheduler]
component/Lifecycle
(start [component]
(let [db-conn (:db-conn database)]
(assoc component
:server (run-server (make-handler component db-conn)
{:port port}))))
...
)
The next thing is that you have, inside your web-app, a new thing called
server, which you're handling all by yourself, bypassing the Component
library. Secondly, run-server looks like a combination constructor (of a
server) and starter. Third, whatever is returned from make-handler could be
another component, it's hard to know. You've also apparently got a cyclic
dependency (web-app has a server, and server has a dependency on the return
from make-handler, which uses web-app) which breaks the Component paradigm.
You can solve this by promoting "server" and "handler" to components, and
giving them each their own place in the system map. You'll have to resolve
their dependencies and split out constructors from starters.
Lastly, it's not clear (from your code) how web-app, server and handler
depend on one another, and why. This is exactly the kind of hidden coupling
Component is designed to address. The answer will be in the APIs each
implies by calling functions using the other.
Without any other information, it seems that this might do it:
(component/system-map
:database (db db-uri)
:scheduler (component/using (scheduler) [:database])
:web-app (component/using (web-app)
[:database
:scheduler])
:handler (component/using (new-handler) [:web-app :database])
:server (component/using (new-server port) [:handler]))
Regards,
Fergal
On Fri, Aug 8, 2014 at 12:16 PM, Sven Richter <sver...@googlemail.com>
wrote:
> Hi,
>
> I am trying to integrate Stuarts component library into my application. I
> am not sure if I use it correctly or do something else wrong or just have a
> wrong mindset. So I will explain how I am currently using it and the
> problem I see with it.
>
> I have three components: database, a scheduler and web application (note
> that my example is simplified to get faster to the point). These components
> are built like this:
>
> (component/system-map
> :database (db db-uri)
> :scheduler (component/using (scheduler) [:database])
> :web-app (component/using (web-app)
> [:database
> :scheduler] ))
>
> And in my web-app I do something like this:
>
> (start [component]
> (let [db-conn (get-in web-app [:database :db-conn])]
> (assoc component :server
> (run-server (make-handler web-app db-conn) {:port
> port}))))
>
> And make-handler is a middleware that associates the database component
> into the request map.
>
> Now as I added the scheduler to my system it occured to me that I will
> have to associate the scheduler into the request map too to access it and I
> might have to do that for every other component that is coming along the
> road.
> So basically I am tying my web-app to to all these components and I am
> tying some components to other components (like scheduler component to the
> database component).
>
> And by tying this things together this way they do depend on each other
> and I cannot move them anymore. This came to my mind as I started thinking
> about microservices.
>
> So let's say I want to convert the scheduler into a restful microservice,
> it's hard to pass in a database connection into it via HTTP, so it seems
> like it's not decoupled enough. Does that make sense?
>
> Am I using it wrong? Is it ok to pass all kind of dependencies into the
> request map and shove it around in the web application? Any other
> suggestions / remarks?
>
> Best Regards,
> Sven
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Fergal Byrne, Brenter IT
Author, Real Machine Intelligence with Clortex and NuPIC
https://leanpub.com/realsmartmachines
Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014:
http://euroclojure.com/2014/
and at LambdaJam Chicago, July 2014: http://www.lambdajam.com
http://inbits.com - Better Living through Thoughtful Technology
http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne
e:fergalbyrnedub...@gmail.com t:+353 83 4214179
Join the quest for Machine Intelligence at http://numenta.org
Formerly of Adnet edi...@adnet.ie http://www.adnet.ie
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
