I recently migrated a featureset from one Rails project into another, as a mounted engine, and ensuring isolation (but not requiring it!) has been tremendously helpful.
The plugins can rely on all of the Laravelisms (auth, storage etc) and Filament allows them to easily draw app/admin UI.
Different routes can be served by different servers, if the bottleneck is in CPU usage.
Different async tasks can run on different task runner services, if the problem is tasks competing with each other.
Different test suites can run for different sections of the app, if the problem is with tests taking too long to run.
Github and others even allow specific subfolders to be "owned" by different teams.
What else is there? Even slowness of compilation and/or initialization can be alleviated, depending on the language or framework.
Concerns (in the broad sense, not ActiveSupport::Concern) can be separated any number of ways. The important part is delineating and formalizing the boundaries between them. For example, a worker running in Puma might instantiate and call three or four or a dozen different service objects all within different engines to accomplish what it needs, but all of that runs in the same Sidekiq thread.
Inserting HTTP or gRPC requests between layers might enforce clean logical boundaries but often what you end up with is a distributed ball of mud that is harder to reason about than a single codebase.
henning•3h ago
adenta•3h ago
pqdbr•1h ago
Actually, the article isn't even about handling file uploads - it's about deliberately creating a modular admin panel for dealing with file uploads.
It's not modularity for "framework-y" sake, but to easily deploy that admin panel in other applications with literally a one-liner.
giovapanasiti•1h ago