Pack It Up

Why Packwerk Can't Save Your Messy Rails App (But You Can)

2024 was a year of packwerk retrospectives (big and small)...

"The final nail in the coffin for packwerk!"

Ever since these talks I felt I should do some retrospecting too...

Hi, I am Stephan

• Lead Developer Productivity teams at Gusto
• Teams working on builds, dev envs, Typescript, GraphQL, Rails, Kafka, and ...
• Modularity

Why Packwerk Can't Save Your Messy Rails App (But You Can)

Packwerk on a slide

• add the packwerk (or pks) gem
• mark folders as packages by adding a package.yml file
• Selectively, set enforce_dependencies: true
• Accept some dependencies between packages (via package.yml config)
• See other dependencies (violations) in package_todo.yml files

Back to those Retrospectives!

Non-autoloaded files get missed by packwerk - hiding real dependencies

• Yes. But fixable* with pks

Privacy checks created architectural debt

• Privacy enforcements, naively "fixed" without question created architectural debt

Package boundaries created bad dependency structures

• Enforcing undesirable package boundaries leads to ... undesirable outcomes

Technical modularity didn't solve the real pains (tight coupling, flaky CI, difficult onboarding).

• Even with all the work... what fraction of engineering years went into improving the monolith vs adding to it?

Violation lists only ever grow

• Enforcement configuration in a file does not create the organizational conditions to actually enforce anything

Domain-based packaging conflicted with functional realities

• Drawing useful boundaries is difficult and takes learning and iteration

Conclusions - Some Hightlights!

Like many other tools in the Rails ecosystem, Packwerk is a sharp knife, and it must be wielded with care. Be intentional about how you use it, and how you fix the violations it raises.

https://shopify.engineering/a-packwerk-retrospective

We cannot keep hiring developers and failing to train them on how to write Rails the Rails way. [...] If we don't train new hires why we use Rails, how to write Rails, how to organize code, how to write tests, how to use the features of the framework, how to avoid sharp knives and how to follow Rails conventions we're doing ourselves a disservice.

https://www.youtube.com/watch?v=olxoNDBp6Rg

The myth of the modular monolith is that architecture cannot fix human and culture problems but fixing human and culture problems can improve our architectural operational and organizational challenges

https://www.youtube.com/watch?v=olxoNDBp6Rg

[Modularity is] not a technical issue. It's a social, incentives, organizational, and educational issue.

https://bsky.app/profile/baweaver.bsky.social/post/3lbgw6tedd22v

So... What does all this mean for you?

Feel disempowered?

Were all of these messages directed only at the top levels of engineering leadership??

THE TAKEAWAY

• When the youtube page about it is sooo long, there is a skill that's important

THE TAKEAWAY. Take 2

• Don't use it is a "sharp knife"?!?

• How are we supposed to learn?

What is our hammer? What is our tool?

Packwerk is a tool to shape application architecture

Do you feel comfortable with your ability to argue for a better application architecture?

... and which tools to use?

THE TAKEAWAY. Take 3

• You should play with and learn from packwerk to get better at application architecture

Let's try!

• Functions
• Classes
• Modules
• Packs
• Gems
• Apps

Function

def process_purchase(customer_id, product_id, amount, quantity)
  # Charge customer
  customer = Customer.find(customer_id)
  customer.charge(amount)

  # Update stock
  product = Product.find(product_id)
  product.update!(stock: product.stock - quantity)
end

Class

class PurchasingService
  def charge_customer(customer_id, amount)
    customer = Customer.find(customer_id)
    customer.charge(amount)
  end

  def update_stock(product_id, quantity)
    product = Product.find(product_id)
    product.update!(stock: product.stock - quantity)
  end
end

Module

module Purchasing
  def self.charge_customer(customer_id, amount)
    customer = Customer.find(customer_id)
    customer.charge(amount)
  end
end

module Inventory
  def self.update_stock(product_id, quantity)
    product = Product.find(product_id)
    product.update!(stock: product.stock - quantity)
  end
end

Pack

# packs/purchasing/app/services/purchasing/charge_service.rb
module Purchasing
  class ChargeService
    def call(customer_id, amount)
      customer = Customer.find(customer_id)
      customer.charge(amount)
    end
  end
end

# packs/inventory/app/services/inventory/stock_service.rb
module Inventory
  class StockService
    def call(product_id, quantity)
      product = Product.find(product_id)
      product.update!(stock: product.stock - quantity)
    end
  end
end

THE TAKEAWAY. Take 4

• Packwerk → Gradual Modularization

• The only tool in our toolbelt that has "learning an architecture" ... and "learning architecture" built in

Gem

# purchasing-gem/lib/purchasing.rb
module Purchasing
  class Engine < Rails::Engine
  end

  class ChargeService
    def call(customer_id, amount)
      customer = Customer.find(customer_id)
      customer.charge(amount)
    end
  end
end

# inventory-gem/lib/inventory.rb
module Inventory
  class Engine < Rails::Engine
  end

  class StockService
    def call(product_id, quantity)
      product = Product.find(product_id)
      product.update!(stock: product.stock - quantity)
    end
  end
end

App

purchasing-app/
  app/
    controllers/
      charges_controller.rb
    models/
      customer.rb
  config/
    routes.rb

inventory-app/
  app/
    controllers/
      stock_controller.rb
    models/
      product.rb
  config/
    routes.rb

THE TAKEAWAY. Take 5

• It all depends

A retrospective is the reflection of a

• a specific person or group
• in a specific context
• at a specific time
• after specific work
• to decide on specific actions!

What can you take away from these retrospectives?

THE TAKEAWAY. Take 6

• All tools create an opportunity for value creation -- All tools cost something

• Think! Is the tradeoff worth it for you?

THE REAL TAKEAWAY

• Don't let others do the thinking for you

• Keep learning and growing

I am still Stephan

Thank you very much!