polylith 2022-02-07 | Slack Archive

Stefan07:02:47

Had a great experience last Friday that I’d like to share. We have a few servers that cooperate and coordinate to perform tasks. The way two of those were split was not very intuitive, but that was never important enough to address. Last Friday this did become a problem (for technical reasons). And then we realised that, since we have migrated everything to Polylith a few months ago, it was now trivially easy to merge the responsibilities into one server (instead of two separate ones). Something that felt like a huge change mentally was just an hour of work, including updating CI/CD etc. Awesome! 😎 And of course if we want to split it again later using different division of responsibilities, it will be just as easy. So thanks Polylith team (@tengstrand @furkan3ayraktar @james) for all your work on this! 🎉

🙌 2

tengstrand07:02:39

Thanks for the nice words, which makes me really happy! I also remember that aha moment!

james08:02:00

That’s awesome! Thank you for sharing it with us! 😎

furkan3ayraktar12:02:43

This made my day 🙃. Thanks for sharing!!

Ferdinand Beyer09:02:35

Hi everyone! Apologies if that was already asked here (and I am pretty sure it was). Instead of using :local/root, the development project adds all “bricks” to extra-paths. That also means we need to repeat all deps in extra-deps, e.g. we can’t just pull in all deps from the bricks’ respective deps.edn files. This feels a bit odd, having to repeat myself. I’m pretty sure there is a good reason for this choice?

tengstrand11:02:01

This is how we do it for the development project in the example, but for all other type of projects we use the :local/root syntax. The reason we don’t use the :local/root syntax for development is that it’s not supported in a good way by Cursive. If you don’t use Cursive in your organisation, you should be fine to use the :local/root syntax also for the development project.

👍 1

Ferdinand Beyer14:02:07

Ah, okay, that makes sense. Thanks!

👍 1

pez15:02:49

Noobish question. How do you generally approach versioning of components? I'm working with a library project in a monorepo (non-Polylith). The library is a local/root dependency, like Polylith components are. I feel the need to add versioning in order to change things with more confidence. I have a feeling Polylith people has a take on this that I should consider.

tengstrand15:02:44

Hi Peter! One way of doing this is to add the version number in the interface, e.g. top-ns.invoicer.interface.v1.my-function . From the interface.v1you will expose and delegate to all functions that is part of the v1 interface. When creating v2 you need to put all functions that is part of interface.v2 there. You will end up with some code duplication in the interface, but the implementation code for the v1 code can be reused.

tengstrand15:02:05

The implementing code may go into top-ns.invoicer.v1 and top-ns.invoicer.v2 as “top namespaces”.

pez16:02:47

Thanks, @tengstrand. This is awesome!

pithyless16:02:48

^ 💯 this. Add a new namespace and refactor with confidence. The new namespace doesn't even have to match the old one (e.g. if you're refactoring the component by changing its api contract). You can build it isolated in confidence, test it against the prior namespace if appropriate (e.g. if you want to ensure feature parity), and enable it piecemeal by changing other parts of the system to use the new namespace over the old one. And you'll have documentation which part of your codebase is using the new version of the component and which is still using the older one.

🙏 1

pez17:02:24

@tengstrand So, when I want to create v2, i can copy top-ns.invoicer.interface.v1 to top-ns.invoicer.interface.v2 and as I implement v2 functions I update the v2 interface? It will keep pointing to all v1 stuff that is not changing.

tengstrand17:02:12

Yes, that’s the idea.

tengstrand17:02:37

Another idea is to just add the new functions to top-ns.invoicer.interface.v2 but that may be harder to use, because then people need to require both v1 and v2 and it will get worse and worse for every new version that is added!

2022-02-07

Channels