Clojurians Log v2

How would you do “dependency injection” For example, we currently have a simple db protocol (with fn like save, get, find). Then we have separate implementations of this protocol (in memory db and gcp datastore). Code that needs db access simply includes the db namespaces and calls the functions (similar to an interface), without caring about the underlying implementation. (aka we can swap out the implementation from the repl without having to change code). My knee jerk reaction would be to have 3 components in this case 1. A db component, exposing the interface everyone will use for db access. It will also expose a protocol for database implementation. 2. A component for in-mem db implementation, that depends on 1 for the protocol 3. A component for gcp datastore implementation, that depends on 1 for the protocol This solution is 100% biased about what we have in our current systems. Is this the correct way to approach it in the polylith structure? Or is there a better mechanism to deal with

Good morning! I will try to answer your question. To put a piece of functionality into a component has two benefits: 1. The encapsulation and the exposed interface can make the code easier to use and reason about. 2. You get reuse. In your case you benefit only from 1 and in that case I would probably start by putting everything into one component instead, where each implementation of the protocol could live in its own namespace, e.g.: components database src my/top/namespace interface.clj protocol.clj in-mem-clj gcp-datastore.clj Then you would expose the interface for the database access in the interface, and put the code needed for that in the protocol namespace and the different implementations in the in-mem and gcp-datastpre namespaces. Here the implementing code will only be used by one component, so putting it in the same component makes sense to me. You can also split up in-mem and gcp-datastore in sub namespaces when you have the need. And don't be afraid of having long descriptive names, which was the reason I called it database instead of db!

@tengstrand Thank you for replying. this also solves the problem where people can accidentally use the implementation component. I’ve been really impressed by poly tool. we are very likely to move our existing stack to it. Thanks for the hard work and sharing

That sounds cool! If you decide to migrate your existing codebase to Polylith, we would be very interested to hear about your experience, and also happy to help out.

:thumbsup: will def give feedback. We have an interesting case where we have both existing node and clj services

(as well as a some ui stuff)

@tengstrand is there any reason that polylith.clj.core.workspace-clj.definitions/definitions does not also include the doc string of a function?

could be handy to auto generate documentation from the component/interfaces

Just so that I understand your question. Do you ask why the definitions function has a doc string but not function ? I guess there are a lot of missing doc strings in the codebase, not just here. There is a balance how much documentation to put into the code, because it needs to be maintained. That's the reason I have mainly added it where an algorithm or similar has to be explained, or at the top/interface level. Now it's mainly added to help me, so there are room for improvements to support new developers or curious people like you.

Yes, that's true.

I can submit a PR sometime in the future if this is something you are open to

We are looking into this already, so the PR is not required. We will announce when the decision is made, how we will proceed.

No thats not what I’m asking. I’m suggestion, that when you call definitions on a statement, and that statement has a doc string, that you include that docstring in the return definition. example

[{:name ".."
  :type ".."
  :doc "foo bar zoo"
  ...}]

Okay, now i understand, good input. You can add a PR if you want, but otherwise I will add this anyway.