[jdminhbg]

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary.

> Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)?

This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD apps, not a general-purpose language for building distributed databases and coordinating space missions.

The problem with these complex software architectures is that they're decoupling Rails from the database, but why in the world would you want to do that? Rails is great because it manages the the meeting point between web requests and relational databases in an elegant, repeatable, commonly-understood way. If you need a complex, general-purpose system that only sometimes will talk to a database for persistence, why in God's name did you use Rails?

[ryanjshaw]

> Similarly, any criticism of overcomplexity

Come on. Nobody is defending "overcomplexity", which is by definition a rather indefensible position. The issue is the frequent arrogance exhibited here by commenters who insist that certain commonly and successfully used design patterns have no place in the world.

[jdminhbg]

Of course I mean defending against the charge of overcomplexity rather than defending overcomplexity itself.

I am sure there are arrogant commenters around, but these commonly used design patterns applied in this case have made his code worse for next to no practical benefit. Besides test speed, there's no reason you'd want to divorce your Employee model from the database it lives in -- the fact that ActiveRecord reflects against the database to decide what attributes an Employee has should be a clue that coupling to the DB is the point of using it in the first place.

[jarrett]

> who insist that certain commonly and successfully used design patterns have no place in the world.

I don't think the architecture skeptics claim as much. I believe you're restating the claim in a more extreme way that it's commonly expressed, thus making it clearly indefensible.

The claim isn't that certain architecture patterns have no place in the world. Rather, the claim is that those patterns aren't a good fit for most Rails apps.

Pretty much any pattern (that's not a commonly-accepted antipattern) has some good use case, somewhere.

[kaonashi]

> but why in the world would you want to do that?

To get your tests to run in < 5ms

> but why in the world would you want to do that?

Build better software faster

[jdminhbg]

Test speed is not the only limiting factor in your ability to produce better software faster. Readability, comprehensibility, and approachability all matter too, and this architectural technique is bad for all of those.

[kaonashi]

> Readability, comprehensibility, and approachability all matter too, and this architectural technique is bad for all of those.

That's a matter of opinion.

[jarrett]

> To get your tests to run in < 5ms

In principle, the current Rails architecture can support that. Rails permits the test environment to use a different database adapter. There's nothing stopping anyone from decoupling the database at that level. I.e. you can pick a super-fast persistence strategy for the test database adapter, if you so choose. If there isn't an adapter you find fast enough, you can even create one. (Such a project would not doubt be well-received.)

Anyway, for my part, I prefer to run my tests against the same kind of DB I use in production. It gives me greater assurances. Especially when a web app can sometimes depend on the peculiarities of a certain persistence layer. E.g., your app has a search engine that runs custom SQL--you really want to test that against the DB.

Would it be nice to run some of my tests without the DB? Absolutely. Some tests just don't need to test anything DB-related. My guess is that Rails' support for that use case will grow organically over time.

[sanderjd]

> why in God's name did you use Rails

Because it is actually a very good, mature application server with lots of sane defaults and good, mature plugins, even if you aren't using a database. Basically, people are interested in using it for more complex applications than you are, because lots of its conventions are still quite good for those applications, even if it makes sense to reject or reconsider some other conventions that don't work quite as well.

[jarrett]

> using it for more complex applications than you are

Are you sure? How complex do you mean? How complex do you presume the parent commenter's apps to be? Could you give an example of one of those more complex apps? I'm wondering if I'm currently building apps of the "simple" or "complex" variety, according to your terminology.

[sanderjd]

It actually wasn't my terminology... If you read the parent of my comment, the self-proclaimed complexity was, literally, "MVPs which are mostly CRUD apps". I think most Rails applications I've used defy that description, and I don't agree with that comment that it is "the entire reason for Rails existing" any more than I would agree that the entire reason for PHP existing is to make personal home pages.

[adamors]

I think that was the conclusion the OP arrived to actually: for a hexagonal application you don't need Rails anymore. Hence the "Rails is gone" in the title.

[jdminhbg]

He clearly needs Rails still, unless he's going to distribute his app through IRB. The post is about pulling Rails out of the domain logic and making it replaceable; I'm saying that's pointless.