polylith

https://polylith.gitbook.io/ and https://github.com/polyfy/polylith
tengstrand 2021-04-18T02:16:57.152900Z

An alternative is to support more than one top namespace @pavlos, e.g. not only se.examplebut also <http://se.example.se|se.example.se>, <http://se.example.de|se.example.de>or maybe se.example and de.example, and so on, with the limitation that the bricks need to be unique across the whole workspace. The drawback is that it would complicate the code, the number of tests that needs to be created, the documentation, and so on, so I need to understand the use case better to understand if it’s worth to pay that price. We have earlier rejected ideas like “sub workspaces” that could support having both an se/user component and a de/user component. We try to keep things as simple as possible, but at the same time try to listen to the user needs!

👍 1
seancorfield 2021-04-18T02:34:51.153400Z

What is the largest single Polylith workspace you’ve worked with so far?

seancorfield 2021-04-18T02:35:32.154200Z

Both in terms of the number of bricks — the “width” — of the repo and in terms of the number of lines of count — the “depth”?

tengstrand 2021-04-18T19:39:50.159800Z

Yes, that will be interesting to follow!

furkan3ayraktar 2021-04-19T11:52:05.160400Z

70 components and 7 projects as of today! 28K loc

👍 2
1
2021-04-21T15:55:23.163400Z

Keep posting! This is great

tengstrand 2021-04-18T04:44:46.154300Z

@furkan3ayraktar’s Scrintal project had 68 bricks last time I asked, and 7 projects. I don’t remember exact how many lines of code, but it’s not huge, maybe something between 10,000 and 20,000 loc.

pavlosmelissinos 2021-04-18T08:25:42.157700Z

@tengstrand I agree that having multiple top namespaces would complicate things a lot. I was thinking more along the lines of having an additional, optional map in workspace.edn to manually override interface/api namespace discovery. Or a single vector that would also absorb :projects ? Not sure which one is better... I created a https://gist.github.com/PavlosMelissinos/6194866cd48354a1ae73a4c8594f1e46, based on the polyfy/polylith repo Not saying it's a sound idea, mostly looking for opinions. It's a good exercise in software design for me regardless 🙂

tengstrand 2021-04-18T13:57:03.157800Z

Hmm. I’ve looked at the gist. If we take Suggestion A as an example. Firstly, there is no magic about the core namespace for a base. You are free to use any namespace after e.g. se.example.my-base you want, e.g. se.example.my-base.api . I don’ know if I understand what you want, or what problem you try to solve. Am I correct if I say that you want to “move” e.g. the my-base base from se.example.my-base to e.g. <http://se.example.my|se.example.my>.base ?

pavlosmelissinos 2021-04-18T15:49:19.158Z

> you want to “move” e.g. the `my-base` base from `se.example.my-base` to e.g.  `se.example.my.base` > yes, that's correct > there is no magic about the `core` namespace for a base [...] > You are free to use any namespace [...] > Oh ok, I didn't realize that, sorry. So it's solved for bases but what I'm describing is still the case with components, right?

tengstrand 2021-04-18T17:26:31.158200Z

When you “So it’s solved for bases”, then I still don’t get what you mean. I also need to understand why the base or component can’t live where they already live, under the top namespace and what the use case is, so it would be great if you could try to clarify that one more time!

pavlosmelissinos 2021-04-18T17:59:14.158400Z

Ok let's ignore bases for a minute. The namespace of a component's interface has to be under: &lt;top-namespace&gt;.&lt;component-ns&gt;.interface component-ns can be something like user-input or user-config but it can't be user.input or user.config Is this statement correct?

tengstrand 2021-04-18T18:30:47.158600Z

Yes, that’s correct. As it is now, the pattern is &lt;top-namespace&gt;.&lt;component-interface&gt;.interface . What you need to do is to put the implementing namespaces under e.g. se.example.invoicer.&lt;any-ns-except-interface&gt;.&lt;optional-sub-namespaces&gt; and the interface under e.g. se.example.invoicer.interface.&lt;optional-sub-interface-namespaces&gt; . With this pattern you are free to organize both the implementing code and the interfaces wherever you want. Will this solve your problem?

pavlosmelissinos 2021-04-18T18:34:15.158900Z

All of the implementing sub-namespaces have to be part of the same component though, right?

tengstrand 2021-04-18T18:42:14.159100Z

Yes.

tengstrand 2021-04-18T18:46:51.159300Z

So if you have two components e.g. invoicer1 and invoicer2 that implements the invoicerinterface, and want to share code between them, then that code needs to go into a separate component and be accessed through that component’s interface.

pavlosmelissinos 2021-04-18T21:07:29.160100Z

Thanks, that clears it up a bit for me. It feels to me like polylith makes too many assumptions about namespaces but it's hard to get my point across without a non-contrived example. I'll try to think of one before I take up any more of your time 🙂

👍 1