Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is not your application

blog.firsthand.ca

Post reply on HN
Print view View original

1–10 of 32 posts

Re: Rails is not your application

#2

Post by yarinb »

I completely agree! As a "framework-less" Java developer where I had written apps with 100k+ LOC, the application code is always separated from the web layer. When I started Rails I scratched my head for days trying to figure where the application code should reside.

I hope this turns into a best practice.

Re: Rails is not your application

#3

Post by k33n »

Sounds like you shouldn't be using Rails if this is your philosophy. I'm of the school of thought that if you're going to use a framework when building an app, then you should lean on it for just about any task that it will let you. Especially if you're using a well-maintained and widely used framework like Rails. There are multiple benefits to this approach. For one thing, it makes it easier to onboard new team members. There are tons of people who are Rails experts, and are very familiar with its paradigms and features. People like this can very quickly get up to speed with just about any Rails project. A large team can also communicate and work much more efficiently if they are all using the same code structure/helpers/etc. If you're a one man show, it might work just fine for you to build specialized gems for all of your "application" (though the line you've drawn between application and framework seems pretty vague) though there is going to be a fundamental lack of structure to your entire project. It'll make sense to you for a little while until it gets so big that even you don't understand it. It's going to be difficult to perceive test coverage, and in practice, all those little gems are going to vary pretty wildly in structure.

You'd be better off just using Sinatra and including ActiveRecord, and whatever other Rails libraries you want to use.

Re: Rails is not your application

#5

Post by ajdecon »

I'm not typically a Ruby/Rails programmer, but this seems to me like a different take on good advice I was given a while back: "Whenever possible, build libraries, not apps."

If my code does anything at all which might be decoupled from this particular program or webapp, I try to break it out into a library, which I then call from the app I'm working on. This sometimes results in some extra work when working on that project, but it's saved me plenty of times in the long run.

edit: typo

Re: Rails is not your application

#6

Post by [deleted] »

yarinb wrote: post #2

I completely agree! As a "framework-less" Java developer where I had written apps with 100k+ LOC, the application code is always separated from the web layer. When I started Rails I scratched my head for days trying to figure where the application code should reside. I hope this turns into a best practice.

[deleted]

Re: Rails is not your application

#8

Post by generalk »

k33n wrote: post #3

Sounds like you shouldn't be using Rails if this is your philosophy. I'm of the school of thought that if you're going to use a framework when building an app, then you should lean on it for just about any task that it will let you. Especially if you're using a well-maintained and widely used framework like Rails. There are multiple benefits to this approach. For one thing, it makes it easier to onboard new team memb…

  > Sounds like you shouldn't be using Rails if this is your philosophy.

  > You'd be better off just using Sinatra and including
  > ActiveRecord, and whatever other Rails libraries you want 
  > to use.
What seriously? Something doesn't fit inside Rails' neat cutouts so obviously the solution is to get rid of Rails? This smacks of "if you don't like Rails, go somewhere else." Just because you're using a framework doesn't mean you can't do anything outside of it, ever!

I mean, take Rails. It gives you a LOT of convenient stuff that you wouldn't want to throw away wholesale, but if you have a Customer model and a Card model, where do you put the checkout code? It could go in either place.

A great solution is to put it into lib/checkout.rb and write a custom Checkout class that manages how Customers and Carts interact. Not only does this make it super-easy to test outside of ActiveRecord, but it consolidates the code in one common place, and you haven't tossed out Rails for no reason.

Re: Rails is not your application

#9

Post by k33n »

generalk wrote: post #8
k33n wrote: post #3

Sounds like you shouldn't be using Rails if this is your philosophy. I'm of the school of thought that if you're going to use a framework when building an app, then you should lean on it for just about any task that it will let you. Especially if you're using a well-maintained and widely used framework like Rails. There are multiple benefits to this approach. For one thing, it makes it easier to onboard new team memb…

> Sounds like you shouldn't be using Rails if this is your philosophy. > You'd be better off just using Sinatra and including > ActiveRecord, and whatever other Rails libraries you want > to use. What seriously? Something doesn't fit inside Rails' neat cutouts so obviously the solution is to get rid of Rails? This smacks of "if you don't like Rails, go somewhere else." Just because you're using a framework doesn't me…

> if you don't like Rails, go somewhere else

Exactly. Makes perfect sense to me. If you're not going to lean on the framework, why even use the entire stack? You can pick and choose the parts of it you like, and want to use under the context of something like Sinatra which is meant for that sort of thing.

> but if you have a Customer model and a Card model, where do you put the checkout code? It could go in either place.

You can put it in either place. I'm not sure I understand why just because there's some flexibility on where you can put method X you should just work completely outside of the framework.

Edit: But this is a different point than the original debate though. I think the blog author goes way too far in avoiding using the framework.

Re: Rails is not your application

#10

Post by casenelson »

k33n wrote: post #3

Sounds like you shouldn't be using Rails if this is your philosophy. I'm of the school of thought that if you're going to use a framework when building an app, then you should lean on it for just about any task that it will let you. Especially if you're using a well-maintained and widely used framework like Rails. There are multiple benefits to this approach. For one thing, it makes it easier to onboard new team memb…

Working against Rails, or any framework, is definitely going to cause pain. On the other hand, Rails is not perfect and I, like the OP, have been noticing a number of voices lately worrying about building large Rails apps. Which is awesome, because either Rails will adapt or something new will come along to fill the need.

Sinatra + cherry picking rails lib might work great if you've built a few apps like that, but it would nice to package this approach in a framework which guides people down this road.

Personally, I feel that Rails could evolve to the point where the approved path involves using some adapter (like a service layer) to talk to ActiveRecord. I've written about how Java accomplishes this in comparison to ActiveRecord: http://casestatement.tumblr.com/post/11514731433/javas-jpa-f...

Post reply on HN