Miles more maintainable: building APIs with the middleware pattern
summary
Rails controllers with many before_action filters become tangled — a real controller at GoCardless grows to 12 filters with shared instance-variable state and hurting tests. The middleware pattern replaces filters with single‑purpose classes chained as a pipeline (implemented in a toy 25‑line simple middleware), passing an immutable state hash and returning Rack responses or delegating onward, which makes unit tests trivial. A production gem, Coach (github.com/gocardless/coach), adds middleware dependency declaration, config and boot‑time dependency checks so routes declare they require user and middleware reliably provide it.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 2:26The middleware pattern
- 8:35Pain and maintainability
- 10:00Hard to understand
- 15:12Middleware pattern
- 19:03Simple middleware
- 23:15Refactor
- 33:10Recap
related talks
28mIn a World of Middleware, Who Needs Monolithic Applications
33mRack Middleware as a General Purpose Abstraction
22mRack Middleware as a General Purpose Abstraction
30mThe Power of Middleware - Building Your Own Mini Web Framework on Rack
42mBuilding Better Web APIs with Rails
45mThe illusion of stable APIs
27mHarness the power of functions to build composable rack applications
30mRails Sojourn: One Man's Journey
