4 ms·

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

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

Sparkyte 3y 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 3y 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. .
  - Sparkyte 3y ago
    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.
    - david-j-vujic 3y ago
      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.
FrustratedMonky 3y ago
Thank You. I just spent 10 minutes skimming and was thinking I was really missing something.

Sparkyte 3y 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 3y 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. .
- Sparkyte 3y ago
  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.
  - david-j-vujic 3y ago
    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.

FrustratedMonky 3y ago

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