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

21–26 of 26 posts

Re: The last Python Architecture you will ever need?

#21

Post by david-j-vujic »

antman wrote: post #20
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

Thank you for the feedback, I’ll give it a try to do something like you suggest.

Re: The last Python Architecture you will ever need?

#22

Post by avocade »

Communicating new ideas is hard, and there’s probably still a lot of work left in that department. I think the focus has been on the tools so far, but as they start to mature the focus could shift to explanation.

I’ve found Polylith a wonderful way of structuring projects over the years. One of the things I really enjoy is having “interfaces” again, instead of relying on anonymous/private functions (in eg clojure) to hide implementation.

Re: The last Python Architecture you will ever need?

#23

Post by david-j-vujic »

lijok wrote: post #3

Am I misunderstanding something or does this look like the worst possible incarnation of a monolith? Everything seems to be sharing everything, so whenever you modify anything, everything is impacted. Which in turn, means that a developer who wants to make any changes, has to understand the whole system in order to not break things or make a mess - which of course leads the cautious developer to write new, duplicate…

Yes, to me it sounds like a misunderstanding. Let's imagine that you have code put in libraries, that you can use in more than one place. For any mainstream project, you would probably have these in separate git repos and published to a code repository (such as PyPI or Clojars).

With Polylith, all of that code lives in the same git repo, and you don't publish them to a repository because you have it "right there". For Python, you reference the reusable code just as any other Python namespace package. Basically the same thing for a Clojure namespace.

Everything isn't sharing everything, but several different services or apps could be using one and the same brick (as it is called in Polylith). A brick is a small isolated part of the code (usually much smaller than a library, that is an entire feature). I hope this has cleared some things up!

Re: The last Python Architecture you will ever need?

#24

Post by david-j-vujic »

jonahbenton wrote: post #8

Microservices are about the data, not the code. Sharing code is really not an issue. Defining data domain boundaries and data change protocols is the challenging issue in application level architecture. See no mention of data here, so...moving on.

Even though you have clear boundaries between microservices, the source code is likely possible to be reused by other services. You probably have common setup (like config loaders, logging and auth) and, depending on the use case, probably also parsers and data reading features that would be duplicated or put in an external libraries.

Yes, Microservices is about boundaries, data and the organizational structure. But there is code that makes these things happen and much of that can be reused.

Re: The last Python Architecture you will ever need?

#25

Post by Sparkyte »

kuchenbecker wrote: post #12
Sparkyte wrote: post #7

Earlier quoted context omitted.

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. .

Microservice works in a purposeful implementation. Otherwise it is safer to build a modular monolith to eliminate REST latency. A process talking to a process is nanoseconds or less, REST is in the high nanoseconds to miliseconds. The volume of processes depends on latency. You can only process so much based on how fast a task's cycle time takes to complete.

Re: The last Python Architecture you will ever need?

#26

Post by david-j-vujic »

Sparkyte wrote: post #25
kuchenbecker wrote: post #12

Earlier quoted context omitted.

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. .

Microservice works in a purposeful implementation. Otherwise it is safer to build a modular monolith to eliminate REST latency. A process talking to a process is nanoseconds or less, REST is in the high nanoseconds to miliseconds. The volume of processes depends on latency. You can only process so much based on how fast a task's cycle time takes to complete.

I agree! In Polylith, the built artifact(s) is an implementation detail and you can decide what to build (a set of Microservices or a monolith) when you are ready for it.
Post reply on HN