Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Architecture Patterns with Python

cosmicpython.com

Post reply on HN
Print view View original

91–100 of 143 posts

Re: Architecture Patterns with Python

#91

Post by ddejohn »

kelafoja wrote: post #35
ryan-duve wrote: post #31

Earlier quoted context omitted.

TL;DR, YAGNI I had a former boss who strongly pushed my team to use the repository pattern for a microservice. The team wanted to try it out since it was new to us and, like the other commenters are saying, it worked but we never actually needed it. So it just sat there as another layer of abstraction, more code, more tests, and nothing benefited from it. Anecdotally, the project was stopped after nine months because…

Could you give me some insights what the possible alternative was that you would have rather seen? I am either now learning that the Repository pattern is something different than what I understand it to be, or there is misunderstanding here. I cannot understand how (basically) tucking away database access code in a repository can lead to complicated code, long development times, and the entire project failing.

Your understanding of the repository pattern is correct. It's the other people in this thread that seem to have misunderstood it and/or implemented it incorrectly. I use the repository pattern in virtually every service (when appropriate) and it's incredibly simple, easy to test and document, and easy to teach to coworkers. Because most of our services use the repository pattern, we can jump into any project we're not familiar with and immediately have the lay of the land, knowing where to go to find business logic or make modifications.

One thing to note -- you stated in another comment that the repository pattern is just for database access, but this isn't really true. You can use the repository pattern for any type of service that requires fetching data from some other location or multiple locations -- whether that's a database, another HTTP API, a plain old file system, a gRPC server, an ftp server, a message queue, an email service... whatever.

This has been hugely helpful for me as one of the things my company does is aggregate data from a lot of other APIs (whois records, stuff of that nature). Multiple times we've had to switch providers due to contract issues or because we found something better/cheaper. Being able to swap out implementations was incredibly helpful because the business logic layer and its unit tests didn't need to be touched at all.

Before I started my current role, we had been using kafka for message queues. There was a huge initiative to switch over to rabbit and it was extremely painful ripping out all the kafka stuff and replacing it with rabbit stuff and it took forever and we still have issues with how the switch was executed to this day, years later. If we'd been using the repository pattern, the switch would've been a piece of cake.

Re: Architecture Patterns with Python

#93

Post by d0mine »

ryan-duve wrote: post #29
BerislavLopac wrote: post #15

Some parts of this book are extremely useful, especially when it's talking about concepts that are more general than Python or any other specific language -- such as event-driven architecture, commands, CQRS etc. That being said, I have a number issues with other parts of it, and I have seen how dangerous it can be when inexperienced developers take it as a gospel and try to implement everything at once (which is a c…

> And don't even get me started with dependency injection in Python. Could I get you started? Or could you point me to a place to get myself started? I primarily code in Python and I've found dependency injection, by which I mean giving a function all the inputs it needs to calculate via parameters, is a principle worth designing projects around.

Here’s 1% that gives 50% of result. Replace:

    class C:
        def __init__(self):
            self.foo = ConcreteFoo()
with:

   class C:
        def __init__(self, foo: SupportsFoo):
            self.foo = foo
where SupportsFoo is a Protocol. That’s it.

Re: Architecture Patterns with Python

#94

Post by maleldil »

tayo42 wrote: post #74
maleldil wrote: post #70

Earlier quoted context omitted.

Annotations can and should be checked. If I change a parameter type, other code using the function will now show errors. That won't happen with just documentation.

In some cases don't you need to actually execute the code to know what the type actually is. How does the type checker know then?

It doesn't. There are cases where the type-checker can't know the type (e.g. json.load has to return Any), but there are tools in the language to reduce how much that happens. If you commit to a fully strictly-typed codebase, it doesn't happen often.

Re: Architecture Patterns with Python

#95

Post by lpapez »

tzcnt wrote: post #82
DanielVZ wrote: post #25

Wow this book is a goldmine for architecture patterns. I love how easy it is to get into a topic and quickly grasp it. Having said that, from a practical and experience standpoint, using some of these patterns can really spiral out into an increased complexity and performance issues in Python, specially when you use already opinionated frameworks like Django which already uses the ActiveRecord pattern. I’ve been in c…

This has been my experience in working with any kind of dogmatic structure or pattern in any language. It seems that the architecture astronauts have missed the point: making the code easier to understand for future developers without context, and provide some certainty that modifications behave as expected. Here's an example of how things can go off the rails very quickly: Rule 1: Functions should be short (no longe…

Bonus architecture points if those functions behind an interface are never mocked in tests.

Re: Architecture Patterns with Python

#96

Post by sevensor »

pansa2 wrote: post #88
zahlman wrote: post #77

Earlier quoted context omitted.

>So far off from what actually happens I disagree strongly, based on 20 years of using Python without annotations and ~5 years of seeing people ask questions about how to do advanced things with types. And based on reading Python code, and comparing that to how I feel when reading code in any manifest-typed language. >Reading Python functions in isolation, you might not even know what data/structure you’re getting as…

> using the wrong language IMO this is the source of much of the demand for type hints in Python. People don't want to write idiomatic Python, they want to write Java - but they're stuck using Python because of library availability or an existing Python codebase. So, they write Java-style code in Python. Most of the time this means heavy use of type hints and an overuse of class hierarchies (e.g. introducing abstract…

I’d say I use type hints to write Python that looks more like Ocaml. Class hierarchies shallow to nonexistent. Abundant use of sum types. Whenever possible using Sequence, Mapping, and Set rather than list, dict, or set. (As these interfaces don’t include mutation, even if the collection itself is mutable.) Honestly if you’re heavily invested in object oriented modeling in Python, you’re doing it wrong. What a headache.

Re: Architecture Patterns with Python

#97

Post by frankc »

DanielVZ wrote: post #25

Wow this book is a goldmine for architecture patterns. I love how easy it is to get into a topic and quickly grasp it. Having said that, from a practical and experience standpoint, using some of these patterns can really spiral out into an increased complexity and performance issues in Python, specially when you use already opinionated frameworks like Django which already uses the ActiveRecord pattern. I’ve been in c…

I love this book but yes, you really need to understand when it makes sense to apply these patterns and when not to. I think of these kinds of architectural patterns like I think of project management. They both add an overhead, and both get a bad rap because if they are used indiscriminately, you will have many cases where the overhead completely dominates any value you get from applying them. However, when used judiciously they are critical to the success of the project.

For example, if I am standing up a straight-forward calendar rest api, I am not going to have a complicated architecture. However, these kinds of patterns, especially an adherence to a ports and adapters architecture, has been critical for me in building trading systems that are easy to switch between simulation and production modes seamlessly. In those cases I am really sure I will need to easily unplug simulators with real trading engines, or historical event feeds with real-time feeds, and its necessary that the business logic have not dual implementations to keep in sync.

Re: Architecture Patterns with Python

#98

Post by sevensor »

maleldil wrote: post #94
tayo42 wrote: post #74

Earlier quoted context omitted.

In some cases don't you need to actually execute the code to know what the type actually is. How does the type checker know then?

It doesn't. There are cases where the type-checker can't know the type (e.g. json.load has to return Any), but there are tools in the language to reduce how much that happens. If you commit to a fully strictly-typed codebase, it doesn't happen often.

You can actually annotate the return type of json.load better than that:

    JSON = float | bool | int | str | None | list[“JSON”] | dict[str, “JSON”]

Re: Architecture Patterns with Python

#99

Post by E_Bfx »

lijok wrote: post #41
DanielVZ wrote: post #25

Wow this book is a goldmine for architecture patterns. I love how easy it is to get into a topic and quickly grasp it. Having said that, from a practical and experience standpoint, using some of these patterns can really spiral out into an increased complexity and performance issues in Python, specially when you use already opinionated frameworks like Django which already uses the ActiveRecord pattern. I’ve been in c…

Strict architectural pattern usage requires understanding the domain, and understanding the patterns. If you have both, navigating the codebase will be intuitive. If you don't, you'll find 1000 LOC functions easier to parse.

That's the problem, if you are working in a compagny which have mostly junior (1 or two year of programming), it is better for you to not implement to complicate pattern otherwise your day will be fill of explaining what a Factory is.

Re: Architecture Patterns with Python

#100

Post by _dain_ »

zahlman wrote: post #77
natdempk wrote: post #26

Earlier quoted context omitted.

So far off from what actually happens. The type annotations provide an easy scaffolding for understand what the code does in detail when reading making code flow and logic less ambiguous. Reading Python functions in isolation, you might not even know what data/structure you’re getting as input… if there’s something that muddles up immediate clarity it’s ambiguity about what data code is operating on.

>So far off from what actually happens I disagree strongly, based on 20 years of using Python without annotations and ~5 years of seeing people ask questions about how to do advanced things with types. And based on reading Python code, and comparing that to how I feel when reading code in any manifest-typed language. >Reading Python functions in isolation, you might not even know what data/structure you’re getting as…

>I'm concerned with what capabilities the input offers, not the name given to one particular implementation of that set of capabilities. If I have to think about it in any more detail than "`ducks` is an iterable of Ducklike" (n.b.: a code definition for an ABC need not actually exist; it would be dead code that just complicates method resolution) I'm trying to do too much in that function. If I have to care about whether the iterable is a list or a string (given that length-1 strings satisfy the ABC), I'm either trying to do the wrong thing or using the wrong language.

You can specify exactly that and no more, using the type system:

    def foo(ducks: Iterable[Ducklike]) -> None:
        ...
If you are typing it as list[Duck] you're doing it wrong.
Post reply on HN