3 ms·

RoR enables developers to make a lot of progress on their app in a short amount of time... initially. Most developers have never seen a legacy Rails app, or are

RoR enables developers to make a lot of progress on their app in a short amount of time... initially. Most developers have never seen a legacy Rails app, or are still in the self-deluded "this time it'll be different" phase. So they jump wholeheartedly into the Rails ecosystem and build their app the "rails way". Not knowing the pitfalls, they fall into all of them. A few years later, you have a successful Rails app with (1) slow, data-coupled tests (2) spaghetti code in your models and controllers (3) probably dockerized, relies on heavily outdated linux version and no one can update it within a sprint so it never happens. So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).

swagonomixxx 4y ago
I have personally witnessed "legacy" rails apps (were ~4 years old, Rails 5 was around but we were on Rails 3 IIRC) and they are not really unlike normal legacy apps but they definitely let a lot of crap seep in due to loads of contributors and almost zero ownership on the codebase. I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)
- ravenstine 4y ago
  > random middlewares The whole concept of "middleware" in Ruby server applications was a huge mistake. Your average Ruby developer has no idea how any of that shit works, and it's an unnecessary abstraction over taking request data and passing it through a function, something that should be simple for even a junior developer to figure out. Somehow it was decided that having a standard for the shape of data wasn't good enough; there had to be a demi-standard for modifying request data before it reaches the primary application code. If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.
  - tmh88j 4y ago
    > If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design. That's just the chain of responsibility pattern [1] and I've only seen middleware operate that way. Why wouldn't you want control over the order? [1] https://refactoring.guru/design-patterns/chain-of-responsibility https://refactoring.guru/design-patterns/chain-of-responsibi...
plugin-baby 4y ago
> data-coupled tests I’m intrigued what this means, or how you’d decouple your tests from all data.
- ravenstine 4y ago
  I can't know exactly what the OP means, but I'm guessing they're referring to the tendency for Rails tests to rely heavily on the database and its behavior. This technique is often rationalized for being a partial substitute for end-to-end testing, given that it tests the integration of the app with its services, and that's not wrong per se. It does come with a penalty because constantly building and tearing down the database has consequences in terms of performance and state leaking between test cases. A lot of the time, this reliance on the database is not (or should not) be necessary; it should be possible to test units of the application in isolation, even including the model->controller->view cycle, without needing to include any knowledge about what database or ORM are being used. Just building in-memory data on the fly is safer and faster, and when tests are faster then developers are more likely to run tests frequently and spot issues earlier. Again, as with many things, it's not a Rails-specific problem. It's an issue in many kinds of codebases, and is an issue with the Ruby community in general. I understand the arguments around coupling tests with the data layer implementation, but I just don't agree when it comes to most of the useful tests being performed.
  - neon_electro 4y ago
    Thank you for this excellent response!
ravenstine 4y ago
This describes a lot of my reasoning for why I left Rails for a more frontend/JavaScript focus. I don't think it's necessarily a problem specific to Rails. It's an issue that the Ruby community that they may never see as a true problem. To their credit, having a system that sucks developers into making simple apps that grow into monstrocities seems to have created a ton of job security for Rails developers. In terms of developer happiness, I really beg to differ once any given Rails application is more than a year old. Rubyists love object orientation and metaprogramming, which I personally see as massive mistakes outside of some niches. Ruby applications in 2023 still have long chains of inheritance, and still employ lots of metaprogramming, and still use tons of syntactic sugar, and still think along the lines of classes rather than methods/functions, and still allow for side-effects on mutable objects. I've found that at least 80% of issues typical to Rails codebases are related to those styles of software development. Most of those are unnecessary for writing most apps using Rails. > So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now). That's the true black-pill of senior-level software engineering. Chances are, as a senior engineer, your job is to figure out the mess rather than make sure anything was done appropriately in the first place. In retrospect, I enjoyed my job as a junior and even mid-level engineer more than being a senior engineer because I often got to work on new and interesting problems while senior engineers had to toil over figuring out some incredibly complicated and boring shit created by the previous engineering regime, as well as by the junior engineers as a whole. Because the business will always be pushing for more features and more deadlines, this problem never gets fixed, hence being a senior engineer becomes little more than an exercise in Sisyphean futility. And the pay is just enough that you don't go fishing instead. I'm just glad I only spent around 3 months as a senior Ruby engineer before switching to JavaScript, despite all of JavaScript's faults.
hnzix 4y ago
Rails provides a sensible and productive pattern for MVP but doesn't provide much guidance past a certain complexity level (Service Objects etc). Once the app grows past a certain size, more bespoke architecture needs to be applied and this will live or die on the competence of the team. Spaghetti code is not inevitable but can result from devs who are used to the hand-holding of less complex Rails apps. Dunno where you are pulling docker from, that is completely orthogonal to Rails development.
- ravenstine 4y ago
  I took the Docker comment as a sort of dig at Rails teams throwing tech at problems in an inappropriate way with the goal of overcoming poor decision making. Not sure how fair that is since the use of Docker et al is often an exercise in cargo cult tech.
  - dieselgate 4y ago
    At the very least a docker/containerized app is really nice for development envs especially if there is a variation on hardware/machines used
- phendrenad2 4y ago
  Yeah, dragging in docker is perhaps unfair, but Ruby apps suffer in a docker environment especially because of how much native code Ruby gems like to include (and how incredibly brittle they are under slightly different C++ compilers...)

swagonomixxx 4y ago

I have personally witnessed "legacy" rails apps (were ~4 years old, Rails 5 was around but we were on Rails 3 IIRC) and they are not really unlike normal legacy apps but they definitely let a lot of crap seep in due to loads of contributors and almost zero ownership on the codebase. I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)

ravenstine 4y ago
> random middlewares The whole concept of "middleware" in Ruby server applications was a huge mistake. Your average Ruby developer has no idea how any of that shit works, and it's an unnecessary abstraction over taking request data and passing it through a function, something that should be simple for even a junior developer to figure out. Somehow it was decided that having a standard for the shape of data wasn't good enough; there had to be a demi-standard for modifying request data before it reaches the primary application code. If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.
- tmh88j 4y ago
  > If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design. That's just the chain of responsibility pattern [1] and I've only seen middleware operate that way. Why wouldn't you want control over the order? [1] https://refactoring.guru/design-patterns/chain-of-responsibility https://refactoring.guru/design-patterns/chain-of-responsibi...

plugin-baby 4y ago

> data-coupled tests I’m intrigued what this means, or how you’d decouple your tests from all data.

ravenstine 4y ago
I can't know exactly what the OP means, but I'm guessing they're referring to the tendency for Rails tests to rely heavily on the database and its behavior. This technique is often rationalized for being a partial substitute for end-to-end testing, given that it tests the integration of the app with its services, and that's not wrong per se. It does come with a penalty because constantly building and tearing down the database has consequences in terms of performance and state leaking between test cases. A lot of the time, this reliance on the database is not (or should not) be necessary; it should be possible to test units of the application in isolation, even including the model->controller->view cycle, without needing to include any knowledge about what database or ORM are being used. Just building in-memory data on the fly is safer and faster, and when tests are faster then developers are more likely to run tests frequently and spot issues earlier. Again, as with many things, it's not a Rails-specific problem. It's an issue in many kinds of codebases, and is an issue with the Ruby community in general. I understand the arguments around coupling tests with the data layer implementation, but I just don't agree when it comes to most of the useful tests being performed.
- neon_electro 4y ago
  Thank you for this excellent response!

ravenstine 4y ago

This describes a lot of my reasoning for why I left Rails for a more frontend/JavaScript focus. I don't think it's necessarily a problem specific to Rails. It's an issue that the Ruby community that they may never see as a true problem. To their credit, having a system that sucks developers into making simple apps that grow into monstrocities seems to have created a ton of job security for Rails developers. In terms of developer happiness, I really beg to differ once any given Rails application is more than a year old. Rubyists love object orientation and metaprogramming, which I personally see as massive mistakes outside of some niches. Ruby applications in 2023 still have long chains of inheritance, and still employ lots of metaprogramming, and still use tons of syntactic sugar, and still think along the lines of classes rather than methods/functions, and still allow for side-effects on mutable objects. I've found that at least 80% of issues typical to Rails codebases are related to those styles of software development. Most of those are unnecessary for writing most apps using Rails. > So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now). That's the true black-pill of senior-level software engineering. Chances are, as a senior engineer, your job is to figure out the mess rather than make sure anything was done appropriately in the first place. In retrospect, I enjoyed my job as a junior and even mid-level engineer more than being a senior engineer because I often got to work on new and interesting problems while senior engineers had to toil over figuring out some incredibly complicated and boring shit created by the previous engineering regime, as well as by the junior engineers as a whole. Because the business will always be pushing for more features and more deadlines, this problem never gets fixed, hence being a senior engineer becomes little more than an exercise in Sisyphean futility. And the pay is just enough that you don't go fishing instead. I'm just glad I only spent around 3 months as a senior Ruby engineer before switching to JavaScript, despite all of JavaScript's faults.

hnzix 4y ago

Rails provides a sensible and productive pattern for MVP but doesn't provide much guidance past a certain complexity level (Service Objects etc). Once the app grows past a certain size, more bespoke architecture needs to be applied and this will live or die on the competence of the team. Spaghetti code is not inevitable but can result from devs who are used to the hand-holding of less complex Rails apps. Dunno where you are pulling docker from, that is completely orthogonal to Rails development.

ravenstine 4y ago
I took the Docker comment as a sort of dig at Rails teams throwing tech at problems in an inappropriate way with the goal of overcoming poor decision making. Not sure how fair that is since the use of Docker et al is often an exercise in cargo cult tech.
- dieselgate 4y ago
  At the very least a docker/containerized app is really nice for development envs especially if there is a variation on hardware/machines used
phendrenad2 4y ago
Yeah, dragging in docker is perhaps unfair, but Ruby apps suffer in a docker environment especially because of how much native code Ruby gems like to include (and how incredibly brittle they are under slightly different C++ compilers...)