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

31–40 of 143 posts

Re: Architecture Patterns with Python

#31

Post by ryan-duve »

kelafoja wrote: post #16
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…

Could you explain how repository pattern is a "huge overkill that adds complexity with very little benefit"? I find it a very light-weight pattern and would recommend to always use it when database access is needed, to clearly separate concerns. In the end, it's just making sure that all database access for a specific entity all goes through one point (the repository for that entity). Inside the repository, you can d…

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 it took too long. The decision to use the repository pattern wasn't the straw that broke the camel's back, but I think using patterns that were more complicated than the usecase required was at the heart of it.

Re: Architecture Patterns with Python

#32

Post by sevensor »

natdempk wrote: post #26
pmg101 wrote: post #22

Earlier quoted context omitted.

My experience is that once people have static typing to lean on they focus much less on the things that in my view are more crucial to building clean, readable code: good, consistent naming and small chunks. Just the visual clutter of adding type annotations can make the code flow less immediately clear and then due to broken windows syndrome people naturally care less and less about visual clarity.

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.

Exactly my experience. I call Python a surprise-typed language. You might write a function assuming its input is a list, but then somebody passes it a string, you can iterate over it so the function returns something, but not what you would have expected, and things get deeply weird somewhere else in your codebase as a result. Surprise!

Type checking on the other hand makes duck typing awesome. All the flexibility, none of the surprises.

Re: Architecture Patterns with Python

#33

Post by globular-toast »

fastasucan wrote: post #11
shesstillamodel wrote: post #8

Even though most people might think of web architectures when it comes to this book, we used this to design an architecture for an AI that optimises energy efficiency in a manufacturing factory. Great book!

Is it easy to transpose to other types of architectures, or is it leaning heavily against web development? Thank you for sharing, your project sounds really interesting by the way! :)

One of the key points of the book (and DDD in general) is the web stuff is just a detail at the edge of an application. You should be able to replace the web bit (for which they use flask) with any other entry point. In fact, they do this by having an event subscriber entry point and IIRC a CLI entry point. The whole point is it all uses the same core code implementing the domain logic.

Re: Architecture Patterns with Python

#34

Post by kelafoja »

unculture wrote: post #24
kelafoja wrote: post #16

Earlier quoted context omitted.

Could you explain how repository pattern is a "huge overkill that adds complexity with very little benefit"? I find it a very light-weight pattern and would recommend to always use it when database access is needed, to clearly separate concerns. In the end, it's just making sure that all database access for a specific entity all goes through one point (the repository for that entity). Inside the repository, you can d…

Repository pattern is useful if you really feel like you're going to need to switch out your database layer for something else at some point in the future, but I've literally never seen this happen in my career ever. Otherwise, it's just duplicate code you have to write.

What is the alternative that you use, how do you provide data access in a clean, separated, maintainable way?

I have seen it a lot in my career, and have used it a lot. I've never used it in any situation to switch out a database layer for something else. It seems like we have very different careers.

I also don't really see how it duplicates code. At the basic level, it's practically nothing more than putting database access code in one place rather than all over the place.

Re: Architecture Patterns with Python

#35

Post by kelafoja »

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

Earlier quoted context omitted.

Could you explain how repository pattern is a "huge overkill that adds complexity with very little benefit"? I find it a very light-weight pattern and would recommend to always use it when database access is needed, to clearly separate concerns. In the end, it's just making sure that all database access for a specific entity all goes through one point (the repository for that entity). Inside the repository, you can d…

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.

Re: Architecture Patterns with Python

#36

Post by mosburger »

kelafoja wrote: post #16
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…

Could you explain how repository pattern is a "huge overkill that adds complexity with very little benefit"? I find it a very light-weight pattern and would recommend to always use it when database access is needed, to clearly separate concerns. In the end, it's just making sure that all database access for a specific entity all goes through one point (the repository for that entity). Inside the repository, you can d…

I find repository pattern useful for testing ... it's a lot easier to mock a repository than to mock stuff that SQLalchemy might need to do.

Re: Architecture Patterns with Python

#37

Post by exe34 »

porridgeraisin wrote: post #30
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…

My experience matches this. It's so liberating as well. I find it easier to internalise such code in my head compared to abstraction-soup. As you can imagine, I like golang.

Me three. I'm even happy to refactor code into a form where there's less repetition and perhaps more parametrised functions, etc.

Finding my way around a soup of ultra abstracted Matryoshka ravioli is my least favourite part of programming. Instead of simplifying things, now I need to consult 12 different objects spread over as many files before I can create a FactoryFactory.

Re: Architecture Patterns with Python

#38

Post by exe34 »

DeathArrow wrote: post #28

I see Python at a nice glue language. I grew tired from the forced OOP mindset, where you have to enforce encapsulation and inheritance on everything, where you only have private fields which are set through methods. I grew tired of SOLID, clean coding, clean architecture, GoF patterns and Uncle Bob. I grew tired of the Kingdom of Nouns and of FizzBuzz Enterprise Editions. I now follow imperative or functional flows…

my favourite model is to write as many pure functions as possible, and then as many functions of 1-4 parameters that interact with the outside world, and only then create domain objects to wrap those - it keeps the unrelated complexity out of the domain and then I can also reuse those functions without having to create the entire object that I don't always need.

Re: Architecture Patterns with Python

#39

Post by Pandabob »

sevensor wrote: post #13
Pandabob wrote: post #4

Truly one of the great python programming books. The one thing that I found missing was the lack of static typing in the code, but that was a deliberate decision by the authors.

Haven’t read the book, so I don’t know exactly what position they’re taking there, but type checking has done more to improve my Python than any amount of architectural advice. How hard it is to type hint your code is a very good gauge of how hard it will be to understand it later.

Yup! I'm also hopeful that the upcoming type-checker from Astral will be an improvement over Mypy. I've found that Mypy's error messages are sometimes hard to reason about.

[0]: https://x.com/charliermarsh/status/1884651482009477368

Re: Architecture Patterns with Python

#40

Post by bulatb »

kelafoja wrote: post #16
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…

Could you explain how repository pattern is a "huge overkill that adds complexity with very little benefit"? I find it a very light-weight pattern and would recommend to always use it when database access is needed, to clearly separate concerns. In the end, it's just making sure that all database access for a specific entity all goes through one point (the repository for that entity). Inside the repository, you can d…

In theory it's a nice abstraction, and the benefit is clear. In practice, your repository likely ends up forwarding its arguments one-for-one to SQLAlchemy's select() or session.query().

That's aside from their particular example of SQLAlchemy sessions, which is extra weird because a Session is already a repository, more or less.

I mean, sure, there's a difference between your repository for your things and types you might consider foreign, in theory, but how theoretical are we going to get? For what actual gain? How big of an app are we talking?

You could alias Repository = Session, or define a simple protocol with stubs for some of Session's methods, just for typing, and you'd get the same amount of theoretical decoupling with no extra layer. If you want to test without a database, don't bind your models to a session. If you want to use a session anyway but still not touch the database, replace your Session's scopefunc and your tested code will never know the difference.

It's not a convincing example.

Building your repository layer over theirs, admittedly you stop the Query type from leaking out. But then you implement essentially the Query interface in little bits for use in different layers, just probably worse, and lacking twenty years of testing.

Post reply on HN