How to build a timeline like Facebook or Twitter - Delegated Type Pattern & Multi-table inheritance

Поделиться
HTML-код
  • Опубликовано: 4 июл 2020
  • 👨‍💻 Check out the discounted, early-release version of my test-driven development course: tddwithlaravel.com
    Hey guys!
    Today I'll teach you how to properly build timelines like Facebook, Twitter and Hey.
    Here's a more detailed blog post, with examples in Ruby: mateusguimaraes.com/posts/und...
    Follow me on twitter to keep up to date with videos: / mateusjatenee

Комментарии • 20

  • @aschmelyun
    @aschmelyun 4 года назад +6

    Great video! I definitely need to use this pattern more in my projects.

    •  4 года назад

      Thanks man! Glad it's helpful for you 😁

  • @VitorJustin
    @VitorJustin 3 года назад +1

    Great content, Mateus!

  • @arielmejia9680
    @arielmejia9680 3 года назад +1

    Thanks Mateus, all your videos are great, this code is readable and clean, definitely I would apply this pattern in the future, but there is another scenario where I can use it? as I see it fits perfectly with polymorphic relationships, but I cannot imagine another use case, thanks great content!

    •  3 года назад

      Thanks Ariel! Thanks for checking my stuff for so long now!
      It works mainly when you want to combine data from different tables. Notifications, timelines, etc.

    • @arielmejia9680
      @arielmejia9680 3 года назад

      @ thanks & trust me your content is wonderful! :)

  • @adamrashid2624
    @adamrashid2624 10 месяцев назад

    Can you take us through an e-commerce site with these patterns...

  • @AmitErandole
    @AmitErandole Год назад

    Mateus, is there a repo where we can browse this code? It's a little confusing to see how the Feedable class and table relations are setup. Because you don't show migrations here

  • @sigmundavila7252
    @sigmundavila7252 4 года назад

    Really informative video!!! Thank you so much. I have a question though. How can you get the specific data for each account. Sample
    In my current setup, I have the following models
    --------------------------------------------------------------
    -Timeline
    --id
    --timelinable_id
    --timelinable_type
    --create_by_id
    --created_at
    -------------------------
    -Account
    --id
    --name
    -------------------------
    -Task
    --id
    --title
    -------------------------
    -Property
    --id
    --location
    -------------------------
    -Calendar
    --id
    --start
    --end
    --notes
    -------------------------
    User
    --id
    --name
    --------------------------------------------------------------
    My scenario: When I view the profile of account_id 1, I want to see all the data that are linked to account_id 1.
    So when I
    -create a new account -> insert to Timeline
    -create a new task -> insert to Timeline
    -create new property -> insert to Timeline
    Hope that you can help me. Im creating a CRM.
    Thank you.

    •  4 года назад +1

      Hi, Sigmund! I'm a bit confused.
      What data do you want to see exactly when fetching account 1? Are the other models in a relationship to account? If so, you just to have to fetch them. In case you want to display a timeline, you can query the timeline model eager loading all the other models.

    • @sigmundavila7252
      @sigmundavila7252 4 года назад

      ​@ thank you for your response.
      Things I wanted to achieve is something like this:
      - Lets say User A (Sales person) created new Account with an id of 1
      - After creating the account, User A created a new Property for account 1
      - Then User A create a Task for account 1
      Now User A view the profile of account 1, since I don't have account_id into my Timeline table how can I get all the timeline data that are related to account id 1?
      Thank you,
      Sigmund

    • @sigmundavila7252
      @sigmundavila7252 4 года назад

      @ thank you for your help. Really appreciate man.

  • @owensoft
    @owensoft 4 года назад

    Polymophic relationships for high volume data will not work. You will end up with a 50 classes and apis to handle every case of the polymorphic relationship. All you need is one table and a couple indexes. Code complexity increases exponentially as the requirements increase.

    •  4 года назад +2

      Sorry, seems like I've missed your comment. Seems like 50 classes is a bit exaggerated, unless you're working on a really HUGE application and in that case you'll probably have another solution in place.
      I've worked on apps with a lot of data and polymorphic relationships in a proper-indexed database worked just fine. I also cannot see a lot of classes being timelineable. Could you expand on that?

    • @owensoft
      @owensoft 4 года назад

      ​@ The solution in the video does not scale. The code literally explodes relative to the amount of columns and data that you have to implement. It suffers from the "simple things are easy but hard things are impossible" problem.

    •  4 года назад +1

      @@owensoft I might be missing something here, but the solution would slow down once you start adding new classes, which results in more queries being made. I don't think it's that bad, though. How many classes do you imagine would be used on a situation like this one?
      AFAIK Hey and Basecamp use the same approach. Not sure what Twitter and FB use, but probably a very specific solution due to the amount of data they handle.
      I've used the same solution in a very heavy application and didn't have many issues regarding scaling. I think it's a pretty great starting point.

    • @owensoft
      @owensoft 4 года назад

      @ such is the same with most tutorials I have watched. Great starting points but no goal of completion.

    •  4 года назад +3

      @@owensoft and I completely disagree with you. How is what HEY and Basecamp use not completion? I don't see most of us working on apps that deal with more data than HEY, for instance, that receives hundreds of thousands of e-mails every day. Not everything has to be scaled to be twitter-level.
      Most likely you'll have a few timelineable classes, which a database can handle just fine.