3 ms·

The service I'm working on right now has about 25 packages. From the language's perspective, each package is a "module" with a "public" API. But from the micros

The service I'm working on right now has about 25 packages. From the language's perspective, each package is a "module" with a "public" API. But from the microservices architecture's perspective, the whole thing is one module with only a few methods.

rcxdude 1y ago
But why would users of the module care about the dependency packages? You could still have a module with only a few methods and that's the interface.
- dijksterhuis 1y ago
  i’ve seen devs do stuff like this (heavily simplified example) from submodule import pandas why? no idea. but they’ve done it. and it’s horrifying as it’s usually not done once. microservices putting a network call in on the factoring is a feature in this case, not a bug. it’s a physical blocker stopping devs doing stuff like that. it’s the one thing i don’t agree with grug on. HOWEVER — it’s only a useful club if you use it well. and most of the time it’s used because of expectations of shiny rocks, putting statements about microservices in the company website, big brain dev making more big brain resume.
  - jakewins 1y ago
    True - but most languages make it much easier than Python to disallow this kind of accidental public API creation. Python inverts the public API thing - in most (all?) other mainstream languages I can think of you need to explicitly export the parts of your module you want to be public API. You can do this in Python as well, but it does involve a bit of care; I like the pattern of a module named “internal” that has the bulk of the modules code in it, and a small public api.py or similar that explicitly exposes the public bits, like an informal version of the compiler-enforced pattern for this in Go
- closeparen 1y ago
  If “everyone would just” restrict themselves to import only the package you meant to public API, sure, it would work. But everyone will not just.
  - rcxdude 1y ago
    I'm not sure why you would bother, though. If you need the package, just import it directly, no? (besides, in many languages you can't even do that kind of thing)

rcxdude 1y ago

But why would users of the module care about the dependency packages? You could still have a module with only a few methods and that's the interface.

dijksterhuis 1y ago
i’ve seen devs do stuff like this (heavily simplified example) from submodule import pandas why? no idea. but they’ve done it. and it’s horrifying as it’s usually not done once. microservices putting a network call in on the factoring is a feature in this case, not a bug. it’s a physical blocker stopping devs doing stuff like that. it’s the one thing i don’t agree with grug on. HOWEVER — it’s only a useful club if you use it well. and most of the time it’s used because of expectations of shiny rocks, putting statements about microservices in the company website, big brain dev making more big brain resume.
- jakewins 1y ago
  True - but most languages make it much easier than Python to disallow this kind of accidental public API creation. Python inverts the public API thing - in most (all?) other mainstream languages I can think of you need to explicitly export the parts of your module you want to be public API. You can do this in Python as well, but it does involve a bit of care; I like the pattern of a module named “internal” that has the bulk of the modules code in it, and a small public api.py or similar that explicitly exposes the public bits, like an informal version of the compiler-enforced pattern for this in Go
closeparen 1y ago
If “everyone would just” restrict themselves to import only the package you meant to public API, sure, it would work. But everyone will not just.
- rcxdude 1y ago
  I'm not sure why you would bother, though. If you need the package, just import it directly, no? (besides, in many languages you can't even do that kind of thing)