How to Fail at Solidus
summary
Solidus works well for high‑volume, large‑catalog, or niche payments but fails when teams over‑customize or fork extensions instead of upstreaming fixes. Key specifics: prefer use deface for admin, override templates for storefront; put in‑repo gems for early integrations; prefer module prepend for core changes and write unit/integration/acceptance tests that cover public and private APIs. Upgrade regularly — minor upgrades take days, not months — and follow the official security patches supported 18 months policy. Embrace Rails conventions and the extension ecosystem.
AI-written summary · about
chapters (21)
- 0:00Start
- 6:15Figure out what you need for launch
- 6:47Build incrementally
- 10:11Embrace Rails
- 11:41Don't fork your extensions
- 12:35Don't build everything as an extension
- 13:47Okay, sometimes build extensions
- 14:51Get familiar with testing Rails applications
- 16:30Don't modify everything
- 16:54Use configuration endpoints
- 17:46Views, partials, and overrides
- 22:38With great power...
- 23:41Pay attention to the upgrade schedule
- 25:5418 Months
- 27:48Upgrading as feedback
- 29:46Shape the platform
- 31:48Community
- 32:12Join the Slack
- 32:23Ask questions
- 32:59Come to our meetups
- 35:12SOLIDUS CONF 7
related talks
24mSolidus Internals, an adventure through less known features
21mRails Upgrade Mastery: Best Practices for Large-Scale Enterprise Applications
41m(Re)Building a large scale payments system on Rails
32mRails Sustainable Productivity
27mScaling Ruby Applications: Challenges, Solutions and Best Practices
41mE-Commerce is hard
36mWorking Compassionately with Legacy Code
28mUpgrading Rails: The Non-Technical Parts