Radoslav Georgiev - Django structure for scale and longevity

แชร์
ฝัง
  • เผยแพร่เมื่อ 9 ม.ค. 2025

ความคิดเห็น • 58

  • @Trooper266
    @Trooper266 2 ปีที่แล้ว +22

    James Bennett, one of Django’s core developers and author of books about Django, wrote two blog articles explaining why these “service layers” are a bad idea for Django projects. What he wrote matches mine experience 1:1 (I use Django since 1.1 and worked on several large projects).

    • @samucancld
      @samucancld ปีที่แล้ว +2

      Could you share those blogs?

    • @12valmirjr
      @12valmirjr ปีที่แล้ว +1

      I highly recommend the reading, Mr Bennett's argument did make much more sense to me. There's a set of "rules" he adopts that do help keeping code organized.

    • @Trooper266
      @Trooper266 ปีที่แล้ว

      @@samucancld Search for "james bennett Against service layers in Django". I tried sharing the link but YT keeps deleting my comment.

    • @jiffey_faux
      @jiffey_faux 9 หลายเดือนก่อน +1

      Really appreciate your comment. Those blogs were a great read. My instinct from previous jobs is to always separate business logic into a service layer, but he makes a compelling argument for instead utilizing the model manager and query set subclasses. I am excited to have justification for trying this "the easy way" that I've always been discouraged from doing... If a project scales to the point where this becomes a hindrance or inconvenience, there will be so many other more pressing concerns to worry about that it really won't matter.

    • @keinermendoza4631
      @keinermendoza4631 8 หลายเดือนก่อน +1

      Thanks for comment, it's really nice to contrasting new ideas with the "voice" of experienced developers. I don't have much experience but there's something with the idea of putting the core app logic outside the models that makes me noise.

  • @nikkovellios
    @nikkovellios 2 ปีที่แล้ว +8

    Model managers and queryset classes. Those are often the best place for business logic to reside. Consider reporting.
    All you're suggesting is taking all the code that was organized where it belongs and sticking it in one or two big mega files of helper functions, then calling it from where the could should be.
    Testing the API should be done. What if a model field changes? Filter and search fields fail in runtime.

  • @yunir844
    @yunir844 ปีที่แล้ว +2

    I am grateful for this video, because otherwise James Bennett would not have told what are the drawbacks of this solution. I saw its partial usage in the codebase of my colleague and also tried it in my own pet-project, but it becomes just too heavy to keep consistent in the long run. The idea of James Bennett with implementing it in QuerySets and Managers sounds much more reasonable right now for me. But till this video, I didn't know where to put the business logic and did not know about manager/queryset opportunities.

    • @speedcuber-diary
      @speedcuber-diary 11 หลายเดือนก่อน

      Did you use HackSoftware guideline?

    • @yunir844
      @yunir844 11 หลายเดือนก่อน

      @@speedcuber-diary I don't remember that name in my mind, so I think probably no.

  • @liorbm1
    @liorbm1 3 ปีที่แล้ว +3

    Services Pros Provided by the speaker:
    The general unit that holds business logic together.
    Service = A simple, type annotated function.
    Speaks the domain language of the software that we are creating.
    Can handle permissions & multiple cross-cutting concerns, such as calling other services or tasks.
    Work mostly & mainly with models.
    Services Cons by James Bennet:
    In short: Business Logic belongs in "the model", which incudes managers and QuerySets.
    I think it just an extended way to write the models file, and to migrate its complexed logic to another file(s)..

    • @GuitaristManiaaac
      @GuitaristManiaaac 3 ปีที่แล้ว

      no

    • @liorbm1
      @liorbm1 3 ปีที่แล้ว

      @@GuitaristManiaaac Very detailed..

    • @GuitaristManiaaac
      @GuitaristManiaaac 3 ปีที่แล้ว +4

      @@liorbm1 I was just fooling around. Just started learning Django 2 weeks ago, I worked in Spring Boot for the past 3 years and the Service layer was a no brainer there. It is kind of confusing for me that there is no such thing in Django 'by default'. In Django terms it really seems that the service layer is just an extension of the Model layer in another file, but I still think it is a better approach even if it is not supported by default. The model should be an interface, and the service layer should handle the business logic, it is cleaner in my opinion.
      With all these said I am still at the start of my Django learning and things that worked in Spring might not work as well in Django.

    • @aksel58
      @aksel58 3 ปีที่แล้ว

      @@GuitaristManiaaac hm, i have a reverse case - 2 years worked with Django and started to looking closely into Spring because of topic of that video. Why do you moving away from spring boot to django?

    • @GuitaristManiaaac
      @GuitaristManiaaac 3 ปีที่แล้ว

      @@aksel58 Changed workplace and we are using different stack here :)

  • @KrishnaDasPC
    @KrishnaDasPC ปีที่แล้ว +1

    Brilliant explanation. Thanks a lot.

  • @codingelle
    @codingelle 4 ปีที่แล้ว +3

    make sense 🙏, except the selector havent tried that

  • @kurn14nt0
    @kurn14nt0 5 ปีที่แล้ว +2

    Nice pattern, thanks to share!

  • @HorstGassner
    @HorstGassner 3 ปีที่แล้ว +1

    Excellent talk and very helpful! Thanx a lot!

  • @remy8587
    @remy8587 3 ปีที่แล้ว +11

    If you don’t allow to use ModelSerializer in create/update views, then you don’t benefit from any model validation such as CharField’s max_length etc...

    • @yujinyuz
      @yujinyuz 2 ปีที่แล้ว

      I think that’s why they call the obj.full_clean() to still gain that benefit

  • @kaloyanmirchev5006
    @kaloyanmirchev5006 4 ปีที่แล้ว +1

    hah nice there, been exactly on the same conference you mentioned at the beginning :)

  • @JacobKasperek
    @JacobKasperek 2 ปีที่แล้ว +8

    This is quite a good and clean solution when prioritizing scalability - BUT - if you're using Django 4fun and small school/personal projects, this lecture should be considered just a "point of view" of professional developer (as video title suggests). In mentioned guidlines Django and DRF are used as frameworks for simply avoiding manual HTTP, SQL and serializing - this does not take advantage of MASSIVE support for fast and reliable development which both of the frameworks provide (and were meant for). As for professional use, this is a very thoughtful solution, not so much for "fun" projects this approach can take away the "fun".

  • @omarosman7384
    @omarosman7384 3 ปีที่แล้ว +2

    selector: fetch DB
    service: write to DB

  • @gauravbole3789
    @gauravbole3789 5 ปีที่แล้ว +4

    Nice talk , but why not we use query sets and model manager. I think this methods are more optimized then service layer

    • @rocomatic
      @rocomatic 5 ปีที่แล้ว +4

      he answers this in the questions section ~38:00

  • @elcreidoluis
    @elcreidoluis 10 หลายเดือนก่อน

    This was really useful for me

  • @soonshin-sam-kwon
    @soonshin-sam-kwon ปีที่แล้ว +1

    IMHO fat models underrated. Django's ORM is a kind of Active Record. If fat models cannot handle the complexity of business logic in your specific applications, it may means that the Django itself is not suited for your app, especially Active Record ORM. In that case better to choose other framework with other orm approach such as Data Mapper...

  • @spagon
    @spagon 2 ปีที่แล้ว

    Just what I needed.

  • @kaiqiang3947
    @kaiqiang3947 5 ปีที่แล้ว

    very nice talk

  • @adrenaline681
    @adrenaline681 4 ปีที่แล้ว

    Can someone explain what is the downside of using the ModelSerializer inside the CreateAPI?

    • @kennethnwafor719
      @kennethnwafor719 4 ปีที่แล้ว +3

      According to him, it's just a separation of concerns. As the name goes, serializers are for transforming data to and from Python objects and shouldn't handle the other things like creation. You could have a rigorous object creation process that is needed in other parts of the code and so won't be very good to mix it up with serialization logic

  • @felixmorales273
    @felixmorales273 2 ปีที่แล้ว

    Hi, i have a question.
    How are circular dependencies handled when two services use functions between themselves?
    Thanks!

    • @ManuTomeA
      @ManuTomeA 2 ปีที่แล้ว

      The Mediator pattern might be a solution you are looking for

    • @ibtsamahmad9582
      @ibtsamahmad9582 ปีที่แล้ว

      do it like this
      instead of importing like "from app.views import UserView"
      do it like this "import app.views as app_view"
      then use your view with "app_view.UserView"

  • @kevinpaullamadrid9621
    @kevinpaullamadrid9621 4 ปีที่แล้ว +1

    Thank you....

  • @idiannealvespiresdeoliveir8690
    @idiannealvespiresdeoliveir8690 5 ปีที่แล้ว +3

    Where is the source code?

  • @funkindy
    @funkindy 4 ปีที่แล้ว +1

    Anyone else here has hands-on experience that reusing serializers is bad practice? This part is not quite clear for me.

    • @IllevensKO
      @IllevensKO 3 ปีที่แล้ว +2

      I'm a newbie but I already had an experience of changing some little detail in the serializer from which others were inheriting/using and breaking my front end :/

    • @oasntet
      @oasntet 3 ปีที่แล้ว +1

      @@IllevensKO Sounds like you need more integration tests. I don't think a service layer is going to fix that.

  • @augustsbautra
    @augustsbautra 5 ปีที่แล้ว +4

    -None of the boxes [given by the framework] are appropriate for business logic. The exact same situation as Rails.

    • @heraldo623
      @heraldo623 4 ปีที่แล้ว +3

      Django is pretty flexible. You are not required to put all your code inside a Model or View. You can wrap all the Django ORM in a Repository and Unit of Work interfaces. Views are just one more input port for Commands, each can be mapped to an Use Case of the application.

    • @italobarzola631
      @italobarzola631 3 ปีที่แล้ว +2

      What can I do if my service depends on a lot of validations, 10 for example .. Is it convenient to do them all in service?

    • @oasntet
      @oasntet 3 ปีที่แล้ว

      This really just leads to a big, unanswered question for me: why use Django at all, then? Why not just use Pyramid or whatever, where the ORM isn't ActiveRecord and fighting your every attempt to abstract it away? And the cynical answer, to me, is that you can still say you're a Django company and you can recruit Django developers, despite not actually using Django in any meaningful sense.

    • @heroe1486
      @heroe1486 3 ปีที่แล้ว

      @@oasntet And python if we push the reasoning further.

    • @oasntet
      @oasntet 3 ปีที่แล้ว

      @@heroe1486 At the very least, sqlalchemy is much more suited to this sort of use case. It's not ActiveRecord.

  • @yakob-g
    @yakob-g 2 ปีที่แล้ว

    i like this

  • @heroe1486
    @heroe1486 3 ปีที่แล้ว

    Some useful informations but yeah you should maybe choose the appropriate level of abstraction on a per task basis and not as a golden rule although you're losing repeatability. But with such a reasoning we could also just argue that using Django isn't the right choice and neither is python if extrapolating

  • @danilovmy
    @danilovmy 2 ปีที่แล้ว +1

    i work with Django already 10 years. This Talk about escapism. And don't matter which framework Rado don't want to use. It can be Flack, Django, Tornado, FastAPI... And it very easy to say: i don't like abstractions, i take from framework nothing. I don't wane to use SRRO, and DRY - this is abstractions also.

  • @kaiqiang3947
    @kaiqiang3947 5 ปีที่แล้ว

    very nice talk