I love Rails. I've built my wealth on it. That's exactly why I think we need to have an honest conversation about its biggest blind spot. Eileen M. U. gave a brilliant talk at Rails World last year: "The Myth of the Modular Monolith." After 6 years of modularizing Shopify's monolith, she concluded: "You can't solve human and cultural problems by changing your architecture." She's right kinda of about the culture part. But stopped one step short. Rails doesn't just allow tight coupling. It incentivizes it. ActiveRecord makes every model globally accessible from anywhere. Any controller, any model, any job can reach into any table through any association chain. There's no boundary enforcement. No import restriction. No compilation step that says "this module shouldn't know about that one." When your framework makes coupling the path of least resistance, blaming developers for coupled code is like blaming water for flowing downhill. Shopify tried to fix this with Packwerk. It just give you a map not a real solution. Rails Engines? Been there, done that. They are miniature apps that provide functionality to their host applications. They don't enforce real isolation and they weren't designed for progressive extraction. But this isn't a Rails problem. It's a missing tool problem. Look at what Nx did for the Node/TypeScript ecosystem: → Module boundaries enforced at the import level, not via YAML to-do lists → Dependency graph visualization built in → Affected-only CI: only test what actually changed → Clear public API per module, everything else is private by default → A real path from monorepo module to extracted service Nx didn't replace Node. It gave Node developers the guardrails to build modular systems naturally. The right thing became the easy thing. By default. Rails deserves the same. Imagine a Rails-native tool that: • Enforces module boundaries through autoload paths, not opt-in linting • Gives each module a public API (explicit exports) while keeping internals private • Generates a live dependency graph from actual code usage, not manual YAML declarations • Runs affected-only CI based on that graph Not a replacement for Rails. A companion that makes Rails' conventions work at scale. Eileen is right: culture matters. Education matters. Leadership incentives matter. But culture alone didn't give us CI/CD. Tools did. Culture alone didn't give us code formatting standards. Linters did. Culture alone won't give us modular Rails applications. Rails gave us developer happiness for building products. Now we need the same philosophy applied to building organizations of code. The myth isn't the modular monolith. The myth is that we have the right tools for one. Who's building this? 🎥 Eileen Uchitelle — "The Myth of the Modular Monolith" (Rails World 2024) https://lnkd.in/dabvzHQm
Fixing Rails' Blind Spot: Modular Monoliths and the Missing Tool
This title was summarized by AI from the post below.
More Relevant Posts
-
Stop Shifting Elements. Use Two Pointers Instead ⚡📦 Solved LeetCode 283 (Move Zeroes) today. Problem 🔍 Move all 0s to the end while maintaining the order of non-zero elements. Initial thought 🧠 Shift elements or use extra array. Works, but increases time or space complexity. Better approach 🚀 Use two pointers: 1️⃣ One pointer tracks position for next non-zero 2️⃣ Traverse array 3️⃣ Swap non-zero elements forward Mental model 🧩 Partition the array: Left → non-zero zone Right → zero zone Interview takeaway 🎯 When rearranging elements in-place while preserving order, think two pointers + partitioning. Practical insight 💡 Avoid unnecessary swaps. Only move when needed to keep operations minimal. Time: O(n) Space: O(1) #DSA #LeetCode #Algorithms #TwoPointers #JavaScript #CodingInterview #InterviewPrep #ArrayProblems
-
🤔 Stop chaining .select and .map in Ruby. There's a single method that does both — in one pass. filter_map iterates once, selects and transforms in the same block. Cleaner code, fewer allocations, better intent. Available since Ruby 2.7. If you're still on select + map, you're doing double work. Small methods, big difference. #Ruby #RubyOnRails #CodingTips #SoftwareEngineering #WebDevelopment
-
-
Sometimes the heaviest anchors in a Ruby on Rails codebase aren’t our own classes, but the gems we use. Third-party dependencies often start as shortcuts, yet they frequently become a major reason for major framework upgrades to stall for months. Perhaps many of you have felt that hesitation: wondering if a niche library from 2018 will survive the jump to the next Rails version. Historically, we reach for a gem because we want to save a bunch of time and don’t want to reinvent the wheel. Today, with AI, generating a bespoke, internal implementation is becoming trivial. While battle-tested code across multiple projects has its merits, every line you didn’t write (because I bet you didn’t fully vet all the gem’s code before you incorporated it into your code) remains a liability you’re still responsible for when production goes down at some ungodly hour. As it is becoming easier to generate code, is the era of the 'micro-gem' coming to an end, or should we still trust the community more than our own prompts? At what point does the reliability of a battle-tested gem become less valuable than the agility of having no external dependencies to manage during an upgrade?
-
-
"React useEffect & useCallback in 2026: Stop Unnecessary Re-renders (React 19 Guide)" Fix unnecessary React re-renders: master useCallback, useMemo, React.memo, and the new React 19 use() hook with real-world patterns, profiling tips, and pitfalls to avoid. #React #React19 #useEffect #useCallback #useMemo 👉 Read full article: https://lnkd.in/d9ypxQex
-
🚀 Mastering Ruby on Rails Views: Hidden Tricks You’re Probably Missing! 🎨 Most developers treat Rails Views as simple templates… But in reality, they can be your biggest performance booster ⚡ and clean UI engine 💡 Here’s what I uncovered 👇 🔥 Hidden Gems ✔️ content_for & provide for dynamic layouts ✔️ Smart render tricks (collection rendering 🚀) ✔️ capture for reusable UI blocks ⚡ Performance Hacks ✔️ Fragment & Russian Doll Caching 🪆 ✔️ Avoid N+1 queries (use includes) ✔️ Faster queries with pluck 💎 Pro Techniques ✔️ Clean views using Helpers ✔️ Safe HTML with sanitize 🔐 ✔️ Dynamic partials for scalable UI 🧠 Game-Changing Gems ✨ Draper ✨ ViewComponent ✨ Slim / HAML ✨ Phlex 👉 Result? Faster apps ⚡ Cleaner code 🧼 Scalable UI 📈 💬 “Your UI is your first impression — make it fast, clean, and powerful.” If you're working with Rails, this is your sign to level up your Views game today! 🚀 Medium - https://lnkd.in/gJanAewj Google Blogs - https://lnkd.in/gxFHEt7i Personal Site - https://lnkd.in/gUGv_wbt Medium - https://lnkd.in/gJanAewj #RubyOnRails #WebDevelopment #FullStackDeveloper #CodingTips #CleanCode #PerformanceOptimization #DevTips #Programming #SoftwareEngineering #Rails #Developers #Tech 🚀
-
A lot of big tech engineers have only recently discovered the power of claude code and started larger onboarding of their developer crowd to it. In a classic AI trends fashion, it's already getting replaced. The stalwarts of our field are already moving to and finding Codex to give a better experience overall. Personally, I have seen good improvements with codex cli and their VS code extension (which I heavily use for personal projects). GH Copilot has also gotten pretty good to use lately as a harness (along with Opus 4.6), which I think doesn't get enough attention it deserves (I heavily use it for work projects). Claude Code gets some PR and hype, but those shipping lot of code are silently moving to Codex. Even Peter (creator of OpenClaw) prefers codex for coding. Below is a tweet from Evan You, who is the creator of Vite and VueJS.
-
-
The Curse of 'Perfect' Code: A Developer's Delusion 🛠️ Developers these days, always chasing the elusive 'perfect' solution. They build cathedrals for microservices when a simple hut would suffice. It's a true Domain Expansion of over-engineering. You spend weeks perfecting an architecture, drowning in design patterns and abstractions, only to realize the market moved on while you were polishing your golden hammer. Efficiency isn't about complexity; it's about delivering value. Sometimes, the most elegant solution is the one that just *works*, and ships before your competitors even finish their first stand-up. Stop worshipping complexity. True power lies in shipping, iterating, and adapting. Your 'perfect' code is often just cursed code that never sees the light of production. — The King of Curses
-
VoidZero originally planned to charge companies for Vite+. Then they flipped it. Full MIT. Free forever. That got my attention. So I actually installed it. One binary that handles your Node version, package manager, linting, formatting, bundling, testing, everything. The problem it's solving: a standard frontend setup in 2026 still ships with NVM, pnpm, ESLint, Prettier, Vitest, Rollup, and Turborepo all needing their own config files. Vite+ says: just use vp. The thing that broke my skepticism: vp check linted and formatted 15,000 lines in under 350ms. Oxlint alone is 50–100× faster than ESLint. For context, Bun tried this "one tool does everything" angle too. And it's great for backends. But its bundler still lacks React Fast Refresh, which quietly kills it for most frontend teams. Vite+ builds on top of the ecosystem everyone already uses React, Vue, TanStack, SvelteKit so nothing breaks. The Vite Task runner is also a direct Turborepo alternative built-in. Smart caching, dependency-aware execution, no manual config. If you're paying for Turborepo today, that's worth noting. But it IS alpha. No Bun support yet. A command that silently overrides your package.json scripts. Rough edges everywhere. Still. The gap between "vision" and "production ready" is shrinking fast. Worth installing this weekend just to see where frontend tooling is headed.
-
Introducing Shipwright — a claude code plugin that turns a product spec into a fully built, tested, and deployed application. Here's how it works: 1. You write a product spec — what you want built and why 2. (/plan-session) Shipwright breaks it into a structured task plan — granular cards with dependencies, acceptance criteria, and test requirements 3. (/dev-loop) Claude Code executes the plan. Card by card. PR by PR. Each one reviewed, tested, and merged independently. To prove it works, I pointed it at a brand new project from scratch: RiverCaster — a satellite-powered fishing intelligence tool that maps deep water, current speed, and fish probability across multiple rivers using real satellite imagery and live USGS gauge data. The result: → 268 commits → 53 merged PRs → 65,000+ lines of TypeScript, Python, and GeoJSON → 33 unit test files with 90%+ code coverage → 5 end-to-end Playwright test suites (smoke, feature interaction, responsive, multi-river, deep link degradation) → Live at rivercaster.com (http://rivercaster.com/) Total build time: ~3 hours. This isn't spaghetti from one giant prompt. Every PR was scoped, tested, and reviewed — the same way a team of engineers would build it, just compressed from weeks into an afternoon. The insight is simple: AI is fast at writing code. It's terrible at organizing work. So don't make it do both at the same time. Separate the planning from the execution. Give the AI a scoped task with clear acceptance criteria. Let it ship one piece at a time. The tests aren't an afterthought — they're baked into every card. Shipwright is free, open source, and available now in the App Vitals Marketplace on GitHub — a growing collection of Claude Code plugins built by engineers, for engineers. What would you build if the only constraint was writing the spec? #Shipwright #ClaudeCode #AIAssistedDevelopment #BuildInPublic #ShipFaster #OpenSource #AppVitals
-
