5 ms·
I've been using Rails for a decade now, across many jobs, and one thing I've experienced fairly consistently is the worst Ruby web apps I have ever dealt with a
by bascule 10y ago
I've been using Rails for a decade now, across many jobs, and one thing I've experienced fairly consistently is the worst Ruby web apps I have ever dealt with are the ones that weren't written in Rails.
I've both seen and spent a lot of time rewriting overgrown Sinatra monstrosities with assorted non-AR ORMs. These apps were generally riddled with XSS since they didn't handle escaping correctly, often had unmaintainable code that sometimes was thousands of lines long crammed into a single file, and lacking any sort of basic structuring principles mixed parameter handling with business logic all over the place.
I've seen several attempts to "build a better Rails" that's "more OO", but even frameworks that solve the problems I've just described in the previous paragraph have one huge drawback: Rails is a lingua franca for web development in Ruby, and whatever incremental gains you get from having a better framework are heavily outweighed by the costs of making people learn a new framework-per-project, the lack of features and documentation, and the lack of the library ecosystem that surrounds Rails.
At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel, which just left me wishing I was dealing with AR (the devil you know...)
ORMs need massive feature sets to jam the proverbial square peg of relational databases through the round hole of objects, and AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in and mature enough to even have a story around database concurrency, even if most Rails developers are getting database concurrency wrong with AR (e.g. http://www.bailis.org/papers/feral-sigmod2015.pdf http://www.bailis.org/papers/feral-sigmod2015.pdf ) At least AR has any story around things like optimistic and pessimistic locking and lets you build apps where you can read an object and persist your changes without silently clobbering another requests's database writes with your locally cached copy of stale data.
tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby.
- eropple 10y ago> AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in Have you never worked on a system big enough to need a service layer?
- bascule 10y agoI've been using service objects / operations in my apps pretty consistently for half a decade, but that's a red herring. That statement is about using AR to query and manipulate data, which is orthogonal to a service layer. Service objects aren't going to fix the lack of optimistic/pessimistic locking in DataMapper.
- eropple 10y agoI don't know what you mean by "service objects", but my point is that ActiveRecord requires you to have a line to the database in order to actually populate a database. This is really shit for a SOA; you should not require a connection to the user database to be able to make heads or tails of an object from your authn/authz service. It is so completely unacceptable that I consider it completely disqualifying (to say nothing of AR's other problems; if I had to use an ORM, which I don't because DALs are fairly trivial in Ruby, I would use Sequel). This is why I use Virtus and ROM.
- neon_electro 10y agoCould you point to any resources for someone who has been learning stock Rails/ActiveRecord to learn more about the approach you prefer?
- bascule 10y agoOh, so you're talking about SOA / "microservices" and Claims-Based Identity (or rather, Claims-Based Identity is what you should be using). Well, an ORM is totally the wrong way to go about expressing user identities in a distributed system. As it were I wrote the AuthN/AuthZ library Square uses to solve this problem: https://github.com/square/rails-auth https://github.com/square/rails-auth The objects we build for representing user identities are POROs. No need for every app to have a database connection to a shared user service, or to go through an ORM. I'm somewhat confused what alternative you're even proposing here: are you doing something weird like Marshalling ORM objects between services?
- 10y ago
- busterarm 10y agoI used Sequel once on a major project and as nice as it was, there was major pain. Pain I wouldn't have had with ActiveRecord. I seriously would have gotten the job done in half the time, with less problems had I just used Rails...and I've written my own ORMs before - I have somewhat of a clue.
- bdcravens 10y agoI'm having the opposite experience, but I think that's because I'm working on a legacy database that really doesn't follow conventions. Even when overriding defaults in AR, I still found myself trying to hammer what I was doing into a AR-shaped block, whereas Sequel feels like it lets me craft a resultset as I desire regardless of what I'm starting with. But like I said, it's a legacy database and it was originally driving an app where writing raw SQL was the SOP, some of which really leans of higher-level SQL engine features for function and performance.
- vidarh 10y agoI'm curious what pain you experienced with Sequel, as I have the exact opposite experience.
- forkerenok 10y agoYour nickname rings the bell. Aren't you https://github.com/tarcieri https://github.com/tarcieri ? If so the "tl; dr:" sounds strange considering your celluloid-based eco-system. Edit: which I consider, at least to date, a bit orthogonal to the Rails ways.
- Freaky 10y ago> At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel ... At least AR has any story around things like optimistic and pessimistic locking That's rather dating your "at points". DataMapper hasn't seen an update since 2011, and Sequel's shipped with optimistic and pessimistic locking since early 2010.
- justinwr 10y ago"tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby." But... wasn't this the underlying point of Solnic's opinion piece? Due to Rails "well deserved" domination in the web framework space, POROs never had a chance of contributing to friendly and just competition across the Ruby community. We simply ended up with shitty alternatives because no one was given the proper chance to be BETTER Rubyists. They just kept eating the gluten and feeling the allergy pains, so to speak. Ah well... EDIT: shrug quoting...