WingNews logo WingNews GitHub [2]

david-j-vujic's comments

david-j-vujic | 2 years ago | on: The last Python Architecture you will ever need?

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.

david-j-vujic | 2 years ago | on: The last Python Architecture you will ever need?

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!

david-j-vujic | 2 years ago | on: The last Python Architecture you will ever need?

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.

david-j-vujic | 2 years ago | on: The last Python Architecture you will ever need?

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.

david-j-vujic | 2 years ago | on: Just Use Dictionaries (Python)

I haven’t used those tools, but I guess you would use the data types already defined in them and what is returned from the functions in there?

If you were about to pass on the result from a calculation to somewhere else, a dictionary or list would probably be a good idea. You probably wouldn’t want the entire system be aware of a Pandas specific data type.

david-j-vujic | 2 years ago | on: Just Use Dictionaries (Python)

Sounds like a good balance between the approaches!

I usually would prefer having everything behind the endpoint (such as Pydantic schemas & FastAPI) as simple dicts and lists.

david-j-vujic | 2 years ago | on: Just Use Dictionaries (Python)

I agree on that it is a good idea to use patterns that the teams have agreed on.

Would you do the same if you were about to make changes in a code base with only dictionaries and lists in it? :)

page 1
more