The last Python Architecture you will ever need?

The last Python Architecture you will ever need?(davidvujic.blogspot.com)

32 points by david-j-vujic 2 years ago | 25 comments

usrbinbash 2 years ago |

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,
    composable, LEGO-like bricks, which can easily be shared across
    teams and services. The choice of bricks determines what each
    artifact does and how it's exposed.

Okay, sounds neat, but ... doesn't that pretty much describe a Microservice? A somewhat-self-contained building block that exposes an interface?

And if it doesn't, isn't this just describing a module/package/library?

Sure, I mean, the idea of having all these libraries in one repository is neat, but...where is the difference from having all of them externally, in their own repos, and leaving the rest to the build pipeline?

Again, this is just based on what I found in 10 minutes of lazy skimming, so if anyone wants to point out something important I overlooked or didn't understand, I'm happy to be corrected.

FrustratedMonky 2 years ago | |

Thank You. I just spent 10 minutes skimming and was thinking I was really missing something.

Sparkyte 2 years ago | |

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.

kuchenbecker 2 years ago | | |

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

lijok 2 years ago |

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 code for the piece of shared functionality that they want, defeating the whole purpose.

Happy to be corrected, I hope I'm wrong.

david-j-vujic 2 years ago | |

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!

jonahbenton 2 years ago |

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.

david-j-vujic 2 years ago | |

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.

_a_a_a_ 2 years ago |

Can't see what it actually does that's special. 'Watch the videos' isn't as helpful as writing it down.

codethief 2 years ago |

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?

tengstrand 2 years ago | |

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

avocade 2 years ago |

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.

xwowsersx 2 years ago |

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.

david-j-vujic 2 years ago | |

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

david-j-vujic 2 years ago |

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/

antman 2 years ago | |

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

david-j-vujic 2 years ago | | |

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

xorcist 2 years ago |

There is something to be said for questions like "what is the best way to organize code, many small codebases or one big one?". Code can have many properties. It can be easy or hard to read, to extend, performance, scalable and a number of other things.

But poly- or monolithic is a way to describe how the code is organized. It must never be an end goal in itself. That way lies madness.

mkranjec 2 years ago |

As far as I understand this is Python specific.

Most monorepos I work with do not use a single language but many. It's pointless to use multiple tools for the same thing instead of one that works with all languages, like nx for example.

infecto 2 years ago |

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?

david-j-vujic 2 years ago | |

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.

ptx 2 years ago | | |

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

Polylith addresses these challenges by introducing simple, composable, LEGO-like bricks, which can easily be shared across teams and services. The choice of bricks determines what each artifact does and how it's exposed.