Introducing Mutations: Putting SOA on Rails for security and maintainability
developer.uservoice.com
Introducing Mutations: Putting SOA on Rails for security and maintainability
1–10 of 27 posts
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#2I heard DHH hates SOA, but the only reference I can find to this is an old interview from 2006. Anyone have a link to anything recent?
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#3I'm glad to see rails devs are finally coming to their senses and exploring other patterns for building applications. SOA, command objects, etc. have been a pretty common pattern in "enterprise-y" frameworks for awhile. This is making rails look more like grails, which I think is a good thing.
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#4I'm a big fan of this pattern. We use a smaller contextual form process that includes ActiveModel::Validations and provides some simple defining methods, and does a very similar thing. Since most services / mutations are generally bound to a form, it's just called BaseForm, and its children are LoginForm, TweetForm etc.
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#5I almost fell off my chair laughing when I saw "Rails" and "Security" and "Maintainability" in the same sentence.
A quick search here itself on HN will show you how immature and security-hole ridden Rails is. Built for, and by, HIPSTERS!
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#6I heard DHH hates SOA, but the only reference I can find to this is an old interview from 2006. Anyone have a link to anything recent?
DHH "hates" SOA probably because he's never worked at an Enterprise Organization ever in his life and instead surrounded himself with bicycle riding Hipsters carrying their typewriter with them to code "retro".
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#7I almost fell off my chair laughing when I saw "Rails" and "Security" and "Maintainability" in the same sentence. A quick search here itself on HN will show you how immature and security-hole ridden Rails is. Built for, and by, HIPSTERS!
Really? Did you read the article? It argues that using this pattern can reduce security risks because conformity of input data is more thoroughly tested before passing off to ActiveRecord.
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#8I almost fell off my chair laughing when I saw "Rails" and "Security" and "Maintainability" in the same sentence. A quick search here itself on HN will show you how immature and security-hole ridden Rails is. Built for, and by, HIPSTERS!
Stupid hipsters with their stupid bicycles.
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#9Looks like typed function to me.
Re: Introducing Mutations: Putting SOA on Rails for security and maintainability
#10Having transitioned from Django to Rails nearly a year ago, this post reminded me of django forms[1]. When I used django, I didn't think much about them, but moving to Rails, I felt something was missing. Why do validations live only/primarily on the model? Doesn't it make more sense to do validation higher-up the chain to filter mistakes and potentially harmful input?
Also a good point about the `attr_accessible` concept. It always felt like a bit of a crippled way to perform authorization. That said, I'm not sure this comment is completely valid:
> attr_accessible suffers from context blindness: you’re frequently going to have an end user UI and an admin UI. You want admins to have access to more fields.
Whilst it's not the most elegant, you can (and should) define `attr_accessible :x, :y, :z, :as => :admin`
but you have to remember to use something like `MyObj.create({x: 'a', z: 'b'}, :as => :admin)`