Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The last Python Architecture you will ever need?

davidvujic.blogspot.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: The last Python Architecture you will ever need?

#11

Post by codethief »

Like many others here I gave up after a while. The author fails to address any of the questions I had when reading:

- How many deployment artifacts do we have? How many nodes/machines running different processes?

- How do we ensure clear separation of domain boundaries (something which microservices excel at) while still staying flexible when those boundaries change (something which a monolith excels at)? Essentially: How do we prevent chaos?

- When changing one of the LEGO bricks, who is responsible for updating their usage downstream? What is the contract here?

Re: The last Python Architecture you will ever need?

#12

Post by kuchenbecker »

Sparkyte wrote: post #7
usrbinbash wrote: post #6

Okay, I gave it 10 minutes and tried to find out what "Polylith" is about, skimming reading material found by following down links starting at the PyPi page. What I found was 10 minutes of LEGO-bricks analogies. What I didn't find, is an answer how this is supposed to be that much different from Microservices or libraries. https://polylith.gitbook.io/polylith/ Polylith addresses these challenges by introducing simple…

Pricely my thoughts too, I think this is just what people do anyway. Talked about from another's perspective. Like marketing an idea. Reinventing the wheel. Typically not the most ideal option either.

Build modules not micro services and deploy your module as a microservice, sidecar, cli, lambda, library dependency, etc as appropriate for the situation. Those interfaces are best as a thin shim on top of the core functionality.

Microservice is a particular interface. If you have GRPC or REST errors being thrown from a function, you're probably letting the interface leak into your program. .

Re: The last Python Architecture you will ever need?

#15

Post by david-j-vujic »

infecto wrote: post #5

I am not smart enough to full understand what this does? I just don’t full understand the use. Does someone have a good rundown of how this would help me?

The main usage is to be able share and reuse code in a very simple way. The code lives in a monorepo, and that means you won't need to extract shared code into external installable libraries. You just pick-and-choose the code needed for each microservice or app. The tooling is useful for visualization, deployment and when adding new "bricks" with templating.

Re: The last Python Architecture you will ever need?

#16

Post by ptx »

david-j-vujic wrote: post #15
infecto wrote: post #5

I am not smart enough to full understand what this does? I just don’t full understand the use. Does someone have a good rundown of how this would help me?

The main usage is to be able share and reuse code in a very simple way. The code lives in a monorepo, and that means you won't need to extract shared code into external installable libraries. You just pick-and-choose the code needed for each microservice or app. The tooling is useful for visualization, deployment and when adding new "bricks" with templating.

If different microservices running different versions of their dependencies and being developed in different repos are seen as problems, what would you say the advantages of microservices are, since you say that "microservices are great"?

I though the point of microservices was mainly that they could be developed and deployed completely independently (in different repos, by different teams, in different languages, with different dependencies).

(Also you can scale them independently, I guess, but you can often do that just by changing the config of your database or app server.)

Re: The last Python Architecture you will ever need?

#17

Post by tengstrand »

codethief wrote: post #11

Like many others here I gave up after a while. The author fails to address any of the questions I had when reading: - How many deployment artifacts do we have? How many nodes/machines running different processes? - How do we ensure clear separation of domain boundaries (something which microservices excel at) while still staying flexible when those boundaries change (something which a monolith excels at)? Essentially…

Hi! This blog post, which I wrote recently, may clear up some question marks: https://medium.com/@joakimtengstrand/understanding-polylith-...

Re: The last Python Architecture you will ever need?

#18

Post by david-j-vujic »

ptx wrote: post #16
david-j-vujic wrote: post #15

Earlier quoted context omitted.

The main usage is to be able share and reuse code in a very simple way. The code lives in a monorepo, and that means you won't need to extract shared code into external installable libraries. You just pick-and-choose the code needed for each microservice or app. The tooling is useful for visualization, deployment and when adding new "bricks" with templating.

If different microservices running different versions of their dependencies and being developed in different repos are seen as problems, what would you say the advantages of microservices are, since you say that "microservices are great"? I though the point of microservices was mainly that they could be developed and deployed completely independently (in different repos, by different teams, in different languages, wi…

Good point! From my experience, having different versions of third-party dependencies is a trade-off when having code in several repos. I've been in organizations where teams have needed to coordinate upgrades of things like logging & error handling tooling, to utilize the tooling across the services. If this would live in one and the same repo (and ideally in one reusable part of the code) it wouldn't be such a big thing.

Services living in a Polylith repo are deployed independently, that's a big part of the tooling support and how code is structured according to the achitecture.

Re: The last Python Architecture you will ever need?

#19

Post by david-j-vujic »

xwowsersx wrote: post #13

Docs need to be drastically streamlined. I went through page after page and still don't have a clear idea of what polylith does or what motivation there is to drive me to continue parsing the docs.

This is useful feedback, thank you! I will try to clear up the Python specific docs (that part of Polylith is on me).

Re: The last Python Architecture you will ever need?

#20

Post by antman »

david-j-vujic wrote: post #14

I have tried hard to write docs that explain the architecture and the usage of the tool primarily in the Python space. You will find it here, and if you prefer videos there are links in there too: https://davidvujic.github.io/python-polylith-docs/

ok what could be up front and center is a before anf after example of something intuitive.

After many clicks i found this https://davidvujic.github.io/python-polylith-docs/examples/ which does not help me

Just a before and after example with online comments of the advantages or something

Post reply on HN