Fork me on GitHub
#polylith
<
2021-09-02
>
furkan3ayraktar11:09:04

That is awesome! Congrats! 🎉

tengstrand11:09:49

Thanks! Yes, it’s really cool! I also want to thank you @U2BDZ9JG3, @U055RDVAV, and @U04V70XH6 for your contribution to the project.

🙌 2
james11:09:52

That’s incredible news! 😀

seancorfield15:09:37

Excellent news! Congratulations!

polylith 6
Travis14:09:45

Hi everyone, I just came across polylith yesterday and it has really peaked my interest. I am still trying to understand everything but I think I get the basics. In our case we would probably be producing projects/services that would be deployed into Kubernetes (microservices/streaming services ). One thing I am not sure of is where would something like the kubernetes manifest live for the project ? My first thought is actually in the project folder somewhere but just curious if I am on track there

tengstrand15:09:44

I’m a Kubernetes newbie, so I can only answer you how you should think about it in general. A good guess is that the manifest file should live in the project directory that represents the service it configures. That’s normally how you do it in Polylith, because each project represents a deployable artifact and it’s often good to keep everything that belongs to that artifact in the same directory.

Travis15:09:41

gotcha, that is what i was thinking

👍 2
jholmberg19:09:17

Hi all, I just came across Polylith as well and I'm having my mind bent a little from what I'm used to around DDD and microservice architecture. I love the idea of decoupling components from how their deployed and the idea of "development nirvana" allowing components to run in one place (like on the clojure repl). That fast feedback seems like it really helps with productivity. I'm struggling with one concept. It seems as though Polylith does not have explicit ways to prevent something from being shared. For instance, if I wanted to create a base that was in charge of a "users" domain and another base that was in charge of an "inventory" domain; it does not seem like there is anything in Poliylith that would prevent inventory from modifying a user if the user component was shared with the inventory base. I'm pretty sure I'm just struggling with my old ways of thinking but wondered if this is an issue anyone else has come across. If so, how did you deal with it?

Matt Ielusic19:09:01

I suppose that if you did that, poly deps would show would show that the Inventory component depends on the User component, and then someone might ask probing questions in code review. (I don't think a base would be in charge of a domain? It seems to me that bases are only supposed to expose a service's API.) > It seems as though Polylith does not have explicit ways to prevent something from being shared. I think that's sort of the point? Polylith is supposed to make it easy to share code between artifacts? If you have code that needs to be hard to re-use/share you could write a library that lives in another repo, I suppose.

jholmberg19:09:35

Thanks for your reply @U0295UQ75FG! I think I'm understanding a little better. Whatever packages up an application with components doesn't care if they're not supposed to be used together. That's more something that should get caught in code reviews to prevent your services from getting coupled in a way that's not optimal.

seancorfield19:09:02

@U0CRFMU7R Are you coming from a multi-repo background and so it's the monorepo aspect that causes you concerns?

jholmberg19:09:15

@U04V70XH6 I do come from a multi-repo background with microservices. But I've seen some of the very problems that polylith addresses like frozen libraries and microservices not staying up-to-date with changes. I'm definitely interested in the idea of moving to a monorepo. I think my mental hurdle has to do with the idea of a bounded context from microservice architectures. If polylith addresses that in a different way, I'm open to it. Just trying to understand a little better if polylith has shed the idea of a bounded context for something better.

seancorfield19:09:55

We've had a monorepo for years but we have "rules" around which subprojects can use which other subprojects -- so, for example, our main REST API app cannot depend directly on our billing subproject, it must use the billing-sdk instead -- which we'd see in poly deps since we can ask about specific bricks.

jholmberg19:09:10

@U04V70XH6: Ahh that's very helpful. That's kind of what I was looking for. Thanks!

tengstrand20:09:29

It would be possible to add support for configuring constraints about how a component can be used by other bricks, e.g “component a can only be used by b and c “. We have tried to keep things as simple as possible, but if this is important, then it’s quite easy to add.

seancorfield20:09:00

Having some sort of "rules DSL" that could be added to workspace.edn and used by poly check would be quite nice.

seancorfield20:09:12

(but it sure does add complexity)

tengstrand21:09:03

It will not add much complexity to the poly tool itself, but I’m afraid that people would start to overuse it. One idea is to let it live in a separate branch, so that people could try it out. And when I think about it, it should probably be “interface acan only be used by the bricks b and c”.

furkan3ayraktar05:09:53

I would say that functionality could be easily written by the developers using the Polylith api or ws command. It seems to be very specific use case and people might have different needs.

2
Travis23:09:26

Currently we you use juxt aero a lot for configuration so we can use profiles to change out certain things like dbs in staging vs prod. Where would configuration go in polylith ? I am thinking base since that is defining the running service

seancorfield23:09:42

If the configuration only relates to the running service, I think it belongs in the project, since it's only relevant to the deployed & running service.

2
Travis23:09:19

gotcha, I can see that

seancorfield23:09:24

Then have a development-only configuration in development/resources for when you're working with the REPL.

seancorfield23:09:05

(for our apps, only the default configuration is in resources -- the per-tier configuration is kept elsewhere anyway)

2