I gave a talk about "Modularizing with Packwerk" at the local "Ruby Montevideo" Meetup last month

General
1

Hi all :wave:.

Last month I gave a talk at the local Ruby Meetup in Montevideo, Uruguay :uruguay:. The talk itself was in Spanish, but the slides are in English so you can try to follow anyway, haha.

The talk is focused on practical, pragmatic and non-fundamentalist use of Packwerk, including a few patterns to break circular dependencies and extract functionality from God objects, with a focus on architectural/layers violations/todos. Based on my experience applying this at our codebase in quimbee.com last year.

Here’s the Video: https://www.youtube.com/watch?v=TAMMnmuXhE8
And here’s the deck: Modularizing with Packwerk / Modularizando con Packwerk - Speaker Deck

Open for feedback!

1 Like
2

Thank you for putting this together and for sharing it here! I am very impressed by the path you went down and the progress you made!

My Spanish isn’t good enough and the questions are not very easy to hear, so I don’t know if this is a duplicate question…

Your comprehensive guide as to how to remove undesirable code dependencies - it depends a lot on moving code to initializers. That makes sense to me and I have that in some of the techniques I propose as well. However, it is so prevalent in your examples, I am curious if you found that it feels to folks like the domain gets split into two places? Also, did you observe any impact on the app boot time?

Oh, also, your 80/20 analysis and maturity model is great!

3

Hi Stephan,

…I am curious if you found that it feels to folks like the domain gets split into two places?

A bit, yes. In particular, I would like to avoid the need of the initializer code to support dependency callbacks. I feel like it should be possible to do this from the belongs_to declaration itself.

In my slide 32 I feel like, Ideally, I should be able to do this instead of adding the code to the initializer:

class Enrollment
  # This is what I would like to be able to do,
  # indicating that all enrollments related to
  # a specific user should be destroyed if the
  # user is being destroyed.
  belongs_to :user, before_destroy: :destroy_all
end

That new before_destroy option would be great. It would support the same options as has_one/many’s dependent but declared from the “right side” of the dependency. It’s a shortcut to User.before_destroy used from the initializer.

One of the main issues to supporting something like this IMHO is on-demand (re-)loading of classes in development environment. I remember having issues with that but can’t remember the exact problem. I do remember this thread where I got great feedback form the community and finding the on_load Zeitwerk callback which could be useful. But I didn’t enter that rabbit hole at the time. In any case, I didn’t have the time to continue on that path and using the initializer solved the problem.

To be clear, I’m not against keeping has_one/many and their dependent option around. Those are fine for same-pack models.

…did you observe any impact on the app boot time?

Didn’t measure it. But didn’t feel a difference.

Thank you for the feedback!

1 Like