5 ms·

In my opinion, Rails is only really great if you have a very tight correspondence between your routes, your models, their JSON, and the database tables. When yo

In my opinion, Rails is only really great if you have a very tight correspondence between your routes, your models, their JSON, and the database tables. When you start separating those apart, that's when you start to suffer a lot with rails.

LargeWu 8y ago
Curious why you think that, or why that problem is specific to Rails. I've worked on some massive rails apps, and never experienced that pain. Or, at least not any more pain than any other large app.
- village-idiot 8y ago
  I’m curious why you wouldn’t agree. Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Overriding that or removing part of it can get painful. I don’t think it’s a problem, nor do I think it’s specific to rails. All technologies work best for the cases they were designed for, that’s how design works. Rails was designed for CRUD apps, and it’s brilliant at that. The trick is knowning when you’re not making a CRUD app.
  - LargeWu 8y ago
    > Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Rails assumes some very basic, predictable, and consistent naming conventions by default. Beyond that, it has virtually no assumptions about what data feeds into a particular route or controller. For instance, if I have a controller named 'dashboard#index', at /dashboard, that controller doesn't care if I have a Dashboard model, or UserDashboard, or if I have a 'dashboards' table in my db, or a collection of 50 other random models that all combine to create a dashboard on the fly. If I have a 'people#update' route, it makes no assumptions that I have a Person or People model or db table. I can put whatever I want into that controller action with zero penalty. Generally speaking I am going to align my controller, model, and route names, but that's more for readability and maintainability concerns, not for the benefit of the framework.
- FrancoisBosun 8y ago
  In an app, I can import a picture either through attaching an image or pasting a URL in a field on the UI. That URL field does not exist in the DB, but in order to benefit from ActionView's helpers, I had to declare the field on my model, even though the value in that field never goes to the model. The controller takes the field's value and does the right thing with it. This is a very simple example of a common task that the separation between UI and backend fails.
  - LargeWu 8y ago
    Obviously I have no insight into your implementation, but I"m not sure why you would "have to" declare the field on your model. There are probably a lot of different ways handle this situation. For instance, you probably don't have to use the ActionView helpers. There's nothing preventing your controller and view from just passing non-model parameters back and forth. Rails has never made the promise of giving you every a solution for every situation in the wild right out of the box, and I don't understand why people seem to think it does. No framework could ever do that. What it does is abstract away the common stuff that makes up probably 95% of most web apps, and gives you the ability to roll the rest on your own.
beat 8y ago
Why don't you have a tight correspondence, though? Is it something intrinsic in the problem space, or you just want to do it the way you think of it? In a number of cases, I've found that the Rails Way was smarter than my original assumptions.
- village-idiot 8y ago
  ... because not everything needs it? If you’re mostly writing CRUD apps, you’re correct. But the world is not all CRUD, even if you’re only looking at the web space.
  - beat 8y ago
    So at some point, you have to ask yourself if the headache of working around something Rails doesn't do well is worth throwing Rails out completely over. Can it be tossed off to a microservice and routed away in nginx or whatever? Does it really not suit the Active Record pattern? If you need a screwdriver, then stop complaining about how much your hammer sucks and get a screwdriver instead. Or ask yourself if a nail could work in the same situation.
    - village-idiot 8y ago
      Yeah, that was my point.
  - Daishiman 8y ago
    So what exactly are those correspondences that don't match? Because in a decade of web dev I have not really seen a satisfactory counterexample. Fundamentally everything lives in a request-response cycle and almost everything you load comes from a DB or as a file asset.

LargeWu 8y ago

Curious why you think that, or why that problem is specific to Rails. I've worked on some massive rails apps, and never experienced that pain. Or, at least not any more pain than any other large app.

village-idiot 8y ago
I’m curious why you wouldn’t agree. Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Overriding that or removing part of it can get painful. I don’t think it’s a problem, nor do I think it’s specific to rails. All technologies work best for the cases they were designed for, that’s how design works. Rails was designed for CRUD apps, and it’s brilliant at that. The trick is knowning when you’re not making a CRUD app.
- LargeWu 8y ago
  > Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Rails assumes some very basic, predictable, and consistent naming conventions by default. Beyond that, it has virtually no assumptions about what data feeds into a particular route or controller. For instance, if I have a controller named 'dashboard#index', at /dashboard, that controller doesn't care if I have a Dashboard model, or UserDashboard, or if I have a 'dashboards' table in my db, or a collection of 50 other random models that all combine to create a dashboard on the fly. If I have a 'people#update' route, it makes no assumptions that I have a Person or People model or db table. I can put whatever I want into that controller action with zero penalty. Generally speaking I am going to align my controller, model, and route names, but that's more for readability and maintainability concerns, not for the benefit of the framework.
FrancoisBosun 8y ago
In an app, I can import a picture either through attaching an image or pasting a URL in a field on the UI. That URL field does not exist in the DB, but in order to benefit from ActionView's helpers, I had to declare the field on my model, even though the value in that field never goes to the model. The controller takes the field's value and does the right thing with it. This is a very simple example of a common task that the separation between UI and backend fails.
- LargeWu 8y ago
  Obviously I have no insight into your implementation, but I"m not sure why you would "have to" declare the field on your model. There are probably a lot of different ways handle this situation. For instance, you probably don't have to use the ActionView helpers. There's nothing preventing your controller and view from just passing non-model parameters back and forth. Rails has never made the promise of giving you every a solution for every situation in the wild right out of the box, and I don't understand why people seem to think it does. No framework could ever do that. What it does is abstract away the common stuff that makes up probably 95% of most web apps, and gives you the ability to roll the rest on your own.

beat 8y ago

Why don't you have a tight correspondence, though? Is it something intrinsic in the problem space, or you just want to do it the way you think of it? In a number of cases, I've found that the Rails Way was smarter than my original assumptions.

village-idiot 8y ago
... because not everything needs it? If you’re mostly writing CRUD apps, you’re correct. But the world is not all CRUD, even if you’re only looking at the web space.
- beat 8y ago
  So at some point, you have to ask yourself if the headache of working around something Rails doesn't do well is worth throwing Rails out completely over. Can it be tossed off to a microservice and routed away in nginx or whatever? Does it really not suit the Active Record pattern? If you need a screwdriver, then stop complaining about how much your hammer sucks and get a screwdriver instead. Or ask yourself if a nail could work in the same situation.
  - village-idiot 8y ago
    Yeah, that was my point.
- Daishiman 8y ago
  So what exactly are those correspondences that don't match? Because in a decade of web dev I have not really seen a satisfactory counterexample. Fundamentally everything lives in a request-response cycle and almost everything you load comes from a DB or as a file asset.