REST vs. SOA: thoughts from a member of the unwashed masses

Posted by amy on November 27, 2007

I have no recollection of how I ended up here:

On the REST front, if you’re claiming that it’s harder than the alternatives, to me that’s just a sign that you don’t understand it. Is REST simple? No, but neither is SOA. However, unlike SOA, which is fairly wishy-washy, noncommittal, and loose, REST’s constraints provide real, actual guidance for developers, and those same constraints also provide opportunities for significant flexibility, extensibility, performance, scalability, and serendipity. SOA’s contracts come with no rules or constraints, and thus can easily result in a system that’s extremely brittle, tightly-coupled, and virtually impossible to upgrade. SOA itself isn’t inherently bad, as it’s certainly a step above the “every application for itself” mode of development that’s so widely practiced. Unlike REST, though, SOA doesn’t go nearly far enough to provide real, useful guidance to the poor developer who has to actually write the stuff, make it work, and keep it running.

The author was responding to this guy:

This is the reason I am against dynamic languages and all of the fan-boy parts of IT. IT is no-longer a hackers paradise populated only by people with a background in Computer Science, it is a discipline for the masses and as such the IT technologies and standards that we adopt should recognise that stopping the majority doing something stupid is the goal, because the smart guys can always cope.

And that guy was responding, in turn, to this guy, who said that REST was like dynamic languages because both are loosey-goosey and flexible and don’t enforce contracts and type-checking.

The SOAP/WSDL/WS-* SOA view of the world is like a statically typed programming language, i.e. C++ or Java — everything is pre-defined, contracts govern everything, nobody can interact without following formal rules … and ideally, everything violating the rules (and policies) will get caught before even going into production.

So the chain is: 1) REST is very flexible compared to SOA, and that presents the danger that things that don’t work will be put into production. 2) REST is too complicated to be implemented by ordinary dumb programmers, and should be avoided. 3) REST is easier than than SOA because it provides very strict constraints.

So is REST easier or harder than SOA? Is it looser or stricter?

I just implemented my first REST API. I don’t see how anyone could say that it is ‘harder than the alternatives’, or that it doesn’t constrain developers very much. So I agree with the first quote, above. REST seems like a great idea to me. Anything that allows me to mostly avoid the complications of this many standards is good.

And also, obviously, I’m a big fan of dynamic languages now. I think I’d rather look at someone else’s crappy Ruby code than someone else’s crappy Java code, because at least there’s less of it. But I am, arguably, a Ruby fangirl right now, and given that I don’t have a CS degree, I guess I also count as one of the unwashed masses. And as a member of the masses, I can attest that no programming language in the world will stop us from doing something stupid. So we may as well enjoy ourselves while we’re doing it!

Popularity: 22% [?]

Amy’s guide to choosing and using rails plugins (With Bonus Checklist!)

Posted by amy on November 19, 2007

Last week a student asked for advice about rails plugins: where to find them, how to evaluate them, and how to use them. I promised a blog entry on the subject, since it’s been on my topic list for three months and I’m behind on blog entries anyway. so here it is.

Where to find plugins is one of the main rails plugin directories. It has a stars and comment system for the listings, but given the number of rails developers out there in the world, there is surprisingly little community activity, so you have to take both the stars and the comments with a grain of salt. (And many of the comments are of the “I installed your plugin and it does not work. How do I fix it?” variety.) Nevertheless, it is the largest plugin directory I know of. And here’s the ruby-on-rails core plugin repository.

After that: google is your friend.

When should you look for a plugin?

Lots of people use acts_as_authenticated or restful_authentication as their starting points for user authentication, so it’s a good idea to become familiar with them yourself, even if you plan to roll your own auth code, because people frequently talk about general auth issues in the context of those plugins.

If you have to implement something that every single web 2.0 site out there has, it’s worth looking for a plugin. DHH wrote the quintessential web2.0 plugin, acts_as_taggable, although there’s also the popular acts_as_taggable_on_steroids. Rick Olsen aka technoweenie, who is a busy plugin bee, provides attachment_fu, which is an easy way to provide gravatars and other image upload/processing capability to your app. will_paginate is the current pagination code flavor of the week (You know not to use rails’ built-in pagination, right? It’s getting yanked out in rails2 anyway). There are a bunch of tutorials on adding star ratings to your app with one of the rateable plugins and some CSS.

Some plugins are more general-use and are meant to make your life as a rails developer easier and more fun. Sexy migrations, for example, DRY up migrations, and were such a popular plugin that they’ve been integrated into rails 2. Annotate-models is a plugin Dave Thomas wrote that adds some comments to your model objects telling you what precisely their database tables look like, so you don’t have to dig around in schema.rb. There are some plugins to improve active record finds, which are generally useful. There are helper plugins, builder plugins, markup plugins, and just plain silly plugins (acts_as_enterprisey).

When you first start using rails, you can go a little plugin-crazy. OMG, I never have to write any code again! you think, and get lost in an orgy of plugin downloads and installations.

Don’t get too excited yet.

I just had a discussion with Robert Oliver of OCS Solutions, rails fellow-traveler and current collaborator on a client project, about the value of plugins. He doesn’t use ‘em much. (“And I don’t use capistrano, either!” he says. “I am a rails heretic! Burn me at the stake!”* ) Anyway, so Robert says plugins are rarely exactly what you need, and it’s too much trouble to put them in and then rip them out when you discover they’re not precisely what you wanted. I say that if they save you time when you start out, and later you have to modify them to suit your purposes, it’s still saved you time, as you probably would have had to modify whatever you wrote yourself too. He says, yeah, but it’s easier to mod your own code than it is to mod other peoples’ code.

Robert has been developing in rails longer than I have, and the more I think about it, the more I think he’s probably right, and that I am only now coming out of the newb over-reliance on plugins phase. Some of the advantages of publicly available plugins fade as you get more familiar yourself with how to make things happen in rails. Rather like scaffolding, which seems awesome at the beginning, and then you realize that the generated code is not that useful. (Note that the advantages of the plugin format for your own code re-use remain after the first flush of newb plugin-love fades.)

For a rails newb, though, plugins do serve some important purposes. Their very lack of documentation and YMMV nature forces you to read the code. sometimes repeatedly. Not all plugin code is worth a damn, of course, but, especially for some of the plugins put out by rails-core members or other luminaries, a lot of it is good stuff. Complex good stuff, full of ruby idioms, metaprogramming, and other stuff the newbie rails developer thinks of as magic. After a while, when you’ve looked at similar magic sixty different times, it starts to become slightly less magic. Oh yes, you think, when you see something like ActiveRecord::Base.send(:extend, Technoweenie::AttachmentFu::ActMethods), there they are mixing themselves into your models for you. And, of course, generous use of plugins is an excellent way to convince non-technical clients that you are a total rails ninja. Hey, look ma, I implemented full-text search in 20 minutes!

Bonus Checklist for choosing and using rails plugins

  • Who wrote it? Are they a big name in the community?
  • Or: do big names use it and talk about it?
  • What kind of documentation, both original and blogged/forum’ed can you find about it?
  • What do people say about it?
  • What’s the code look like?
  • Is it really worthwhile for you to use it, or should you just review it for a general approach to the problem you’re trying to solve and then write your own code?
  • Does it have tests? Do the tests run?
  • Do you really need what the plugin gives you, or are you just putting it into your app because you can? (does every single thing on the web really need to be friendable? )
  • Any glaring security issues? SQL injection, passwords in the clear, unescaped html, etc.?
  • Read the readme. It may be thin. But it should tell you at the very least the steps you need to take to get going with it, which might include generating some code, running a migration, adding a line or two to a model class, etc.
  • You have to read the code. Did I mention that? Look at the code. Don’t use a plugin whose code you haven’t looked at! And also, read the code.

Further Resources

Geoffrey Grossenbach’s Nuby On Rails offers an excellent two-part tutorial on plugins: Part 1, and Part 2.

There’s a whole short cut (or whatever it’s called — you know, one of those mini-e-books) about Rails Plugins. It looks pretty good, but i’ve only skimmed it on Safari. If you plan to write your own, check it out.

On the Proliferation of Crappy Plugins

Dear readers: please think twice about releasing your own plugin into the wild just so you can check off the ‘wrote plugin’ item on Working With Rails. Please make a plugin you release generally useful, reasonably well-tested, secure (don’t leave your plugin finder methods vulnerable to sql injection, for example), and documented. If it’s similar to another plugin already out there, be sure to point out how yours is different in a way that helps people choose between them. Plugins are a fantastic way to re-use code on your own projects, but not all such code really wants to be free. Is this a heretical anti-Open-Source comment that I should not be making? I am not sure. Anyway, I am sure that someone will turn around and suggest that I quit littering the internets with my crappy blog posts.

robert says: “as for capistrano.. Do you really want anyone who has the source to be able to deploy your app? That’s dangerous! Use custom scripts.. They’re easier to write than capistrano tasks and you must have access to the servers to run them!”

Popularity: 22% [?]

Database Constraints, Stereotypes, Rails, Culture, Talmud, Gender, MINASWAN, Religion. But ABSOLUTELY NO BONDAGE PLAY

Posted by amy on November 02, 2007

This post started out with a plan to compare constraints in software to bondage play, and suggest that DHH is a top who likes to constrain others (“opinionated software”) but is extremely uncomfortable being himself constrained (by, say, the database). I was going to suggest that DHH maybe needs to get a little bit more confident and comfortable being a ‘bottom’.

Now, that would have been a wildly, wildly inappropriate post, don’t you think? So it’s lucky for me that as I was writing it, I realized that not only was it inappropriate, it was completely unfair. So this post is still about rails culture, and still about database constraints, but I am not, I repeat, NOT arguing one way or another about DHH’s predilections in bondage play (assuming he has any, and if he does, not that there’s anything wrong with that ), about which I am, and hope and plan very much to remain, ignorant.

That out of the way, how did this all come up? Yeah, my mind’s a little twisted. But here you go:

My friend and partner-in-teaching-crime* (well, boss in teaching-crime, technically, and is teaching really a crime? To my students: do not answer that!) John complained recently about the difficulties of writing a migration to turn a plain HABTM join table (two foreign keys, no primary key, nuthin’ else) into a join table with state, linking two other tables with the :has_many :through association. Unfortunately, as he describes, ActiveRecord won’t let you add a primary key column to an already-existing table, so he had to migrate all the data over to a new table.

Couldn’t you just drop down to “execute ‘db-specific sql here’”? I asked.

Yeah, but you wouldn’t be database-agnostic, of course. John likes to be agnostic. He has historical reasons for that, just like I have historical reasons for thinking that ads comparing servers to who won’t give blow jobs are kinda offensive. But anyway, I don’t have those reasons that John does to prefer agnosticism. I figure that in most cases, people are sticking with the database they’ve got, so database agnosticism isn’t that important to me. The ORM is one of Mr. Spolsky’s leaky abstractions, and while that’s no excuse to start poking extra holes through just for the fun of it, I don’t have any need to pretend that the holes that exist aren’t really there.

In any case, I drop down to the database to put in foreign key constraints.

[Aside: John said in email:

"There is a distinction to be made between this narrow case of
agnosticism (fiddling with keys) and the general case. The narrow case
is easier to disregard. In the general case, it is very difficult to
argue against agnosticism, because the primary driver is: You get to
know less. That is frequently (more frequently than not) beneficial,
right? In the general case, I would rather write
user.find_all_by_last_name rather than the raw SQL. etc."

I agree wholeheartedly, and in that sense I too am in favor of database agnosticism. But obviously we have different levels of allegiance to the idea, because I would never have put in the effort to come up with a database-agnostic migration from a HABTM to a has many through relationship, and he did. Maybe it's just that I am lazier than he is, though...]

So this post was going to be about how it is the rails way not to use foreign key constraints at all, but to rely on ActiveRecord and your own unit testing to maintain data integrity. (hah!) And I was going to say “that’s freakin’ insane and evidence of all that is wrong with the whole culture of Rails.” But while it would be fun to see what this temporarily did to my site stats, (assuming it got dugg or reddited or something) it wouldn’t be fair.

I found very little evidence that not using foreign key constraints is considered to be a best practice by most people in the rails community. The main thing is this caboose posting, from last year. This was mostly a complaint about how big of a pain in the ass foreign keys are, especially where fixtures are concerned. But it actually only at the end claims that foreign keys are not needed, if you are using ActiveRecord Associations correctly. And even then, it’s a weak claim, about foreign keys in the development database:

The time thing sold me on not using foreign keys in development. I’m sure there are a number of arguments that can be made for using foreign keys etc etc, but it’s just stuff that gets in the way in a framework like rails. Do we test w/ foreign keys in place before milestones(what I’m leaning towards)? Do we test w/o the fks in place(obviously not :])? Maybe somebody can come up with a better way to handle them, but I don’t really think you need fks if you’re using rails associations correctly. If you are forced to use them though, the above approach might be a good place to start.

Okay, I found one other posting, from a guy who gave up his foreign key constraints (and wept) because they were too hard to use with fixtures. But most people in the comments of that post seems to think the problem there is not foreign key constraints, but fixtures, and that dropping the reliance on fixtures would be the smarter thing to do. Or fixing the fixtures, or whatever.

DHH has nothing to say on the matter that I could find. In AWDR, Dave Thomas explicitly advocates the use of foreign key constraints (2nd Edition, p. 324). Mostly what I found on the web about rails and foreign key constraints was a bunch of people talking about how they do use them and you’d be crazy and irresponsible not to. Yes, people differ on when in the development process they put them in (in fact, right this minute I have a development database with a near-complete lack of foreign key constraints, my rather pathetic excuse being that the client’s requirements are so changeable right now that we can hardly keep up with the foreign keys themselves…), how they use them with fixtures, and other details, but I really found very little evidence that anyone in the rails world seriously advocates putting into production web applications backed by databases without foreign key constraints. Relational database technology is mature, it’s well-tested, and it’s logical. I trust it much more than I trust either my own code or DHH’s. Database constraints are easy to use and good for you, just like flossing. And that appears to be the majority view.

So the evidence wasn’t there, and I had to rethink this post entirely. And so it’s become, in part, a post about stereotypes, and about culture, and about the ways that people confuse technologies, creators, fans, and users.

Rails is a technology. The technology exists in the context of a culture. The culture is greatly influenced by the fact that a single, very opinionated, um, strong personality developed the technology. Certain kinds of people are attracted to the opinionated personality, and become involved in the technology and its culture because of that. This is great for adoption of the technology. But then you get the fanaticism: rabid pro-Rails trolls who jump down the throats of people they perceive to be deviating from the One True Way of DHH. And equally rabid anti-rails trolls, screaming “Twitter”!

Now, is all this clash of personalities and hue and cry integral to the development of the technology, or is it epiphenomenal? (Is that a word?) I’m not sure. The anthropologist in me says it is, and that the culture of rails in some sense IS rails — drives its development, ensures or prevents its success, etc. The Marxist in me thinks perhaps the structure of rails itself is responsible for the culture surrounding it: the culture reifies the framework. And the poststructuralist in me suggests that, however determined things appear to be, however narrow and defined and boundaried and opinionated and one-true-wayed things appear, there’s always space for something else to arise.

There’s the One True Way of DHH. There are rabid fanboys. We talk of drinking the kool-aid, and we laugh at video advertisements comparing the separation of concerns, database-agnosticism, and ease-of-use of Rails to PHP, Java, et. al. “With rails, I can build a blog in 10 minutes,” we say. With rails, we never have to code again! Let’s just go to the beach instead! There was the Twitter developer scaling scandal, and the CDBaby switched-back-to-php-from-rails scandal, and a bunch of scandals I haven’t even heard of, no doubt. There’s the rails bandwagon, the rails hype, rails lets crappy developers wreak havoc quickly, rails is too slow, and rails is not ruby.

And that’s all fine and part of the fun, and part of the DHH Is Opinionated and So We Are Opinionated – ness of Rails culture.

But then there’s the technology, and lots of quiet, not-so-opinionated, flexible people who are using Rails because it’s a pretty good, pretty easy framework that helps them get their work done. There’s plenty of that too. And there’s no need to decry the partisan atmosphere of rails culture with a great big rending of garments about how the culture really has to change if it’s going to achieve more popularity, and it’s scaring people off because it seems too hyped, and badly executed rails projects are giving rails a bad name and how can we police that, and so on.

Let’s just all get on with our work, using rails, or not, as the work dictates. And in a mild-mannered matz-y way, talk about what we are doing, and why, and how, and what we like, or don’t, about it.

For me, rails is a web framework, not a religion. I know that not everyone feels or acts that way, and that’s fine for them. They can wave their hands and argue about what constitute a ‘scale’ for the purposes of determining if a fish is kosher, or if one should use foreign key constraints. Me, I’ve got to get dinner on the table.

* Max would like it noted that he thinks there’s something very trite about the expression “partner-in-crime”. He’s right, of course, but I think I’ll leave it in anyway, to annoy him.

Popularity: 24% [?]