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

Trailblazer: A new architecture for Rails

github.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Trailblazer: A new architecture for Rails

#31

Post by rafekett »

disbelief wrote: post #13
johnny99 wrote: post #2

I'm intrigued, and would love to hear of anyone's experience using this, particularly in a production environment. One question: does it have performance implications, one way or another?

JSON rendering performance is a major concern for most of my Rails apps, and I'm wondering the same thing. I've not used Roar ( https://github.com/apotonick/roar ) before which is what Trailblazer uses for JSON serialization/deserialization. It seems to be full-featured, but I'm interested to hear how it performs compared to other gems. I currently use OJ + Jbuilder + a ton of fragment caching and it's not great but…

> JSON rendering performance is a major concern for most of my Rails apps

I've always wondered why this is the case. Faster JSON libraries don't seem to help. Similar frameworks don't have this problem. It just seems the Rails serialization code is slow in and of itself, it's not what it calls out to. Maybe there's a contention issue somewhere?

Re: Trailblazer: A new architecture for Rails

#32

Post by jonahx »

From the sample chapter:

"Some charismatic leaders in Rails core dislike encapsulation. The Fear Of The Class, the freedom of a dynamically typed programming language and the strong will to make it different to Java and its “over-abstraction” has led a generation of developers to unlearn what object-orientation really is about - and neglect this ingenius concept."

I've had similar thoughts myself. It's almost as if, at this point, the renegade, hip thing to do is to start proudly wearing "enterprisy-ness," like a faded, well-worn MC Hammer t-shirt.

Re: Trailblazer: A new architecture for Rails

#33

Post by hardwaresofton »

As some have previously stated, this probably shouldn't be on rails... It seems like it should be built on top of a lighter framework, like Sinatra.

Also, it looks like concepts === components. There is a lot to learn from meteor's approach to this -- While I haven't mastered meteor (still very much learning it), it's the most component-ized framework I've seen (and it's extremely unique), and their approach is good/consistent.

Re: Trailblazer: A new architecture for Rails

#34

Post by Rapzid »

gerry_shaw wrote: post #8
ebiester wrote: post #7

Earlier quoted context omitted.

Say that again after you have to learn a rails app with 1500 line models built "the rails way." Controller -> model breaks down when you reach a certain size. Or worse, giant controllers and models with no clear distinction.

You can go a long way with using simple Ruby objects to break up logic and separate out logic from models. If developers are writing 1500 line models and the lead developer isn't doing anything about it a adding new abstract concepts isn't going to help.

Yeah, and I don't think anemic models are the way to go. That's swinging back the other way too hard. Rails could do with promoting a service/app layer if anything new were to be introduced. A healthy dose of DDD concepts.

Re: Trailblazer: A new architecture for Rails

#35

Post by baddox »

picardo wrote: post #21
jamie_ca wrote: post #19

Earlier quoted context omitted.

Because Rails has 10+ years of development on backend tooling that shouldn't be nixed or reinvented on account of a reorganization of files? Yes, it replaces view rendering completely with Cells, but routing, dispatch, request serialization, activerecord, asset pipeline, rails-provided view helpers and more are all used basically as-is.

The view rendering doesn't need to be done by Rails. I've been using React and Webpack to build the clientside of my Rails apps and have been very happy with that approach. There is nothing that this architecture does that a clientside framework like React cannot do better.

How do you store/version/deploy that, by the way? Do you build your Rails project purely as an API, and a separate project/repo for the React client?

Re: Trailblazer: A new architecture for Rails

#36

Post by juliangregorian »

rafekett wrote: post #28
sbov wrote: post #16

Earlier quoted context omitted.

I've never really understood layer-level grouping. Ideally, the more likely things are going to change together, the closer together you have them. Given that, it's less likely that you'll change the code for all your models than change the view+controller+model code for a given feature.

it's useful in practice for denoising file names. unfortunately rails doesn't do this at all, and every controller file is something like `app/controllers/foo_controller.rb`. in Python, if you had a file `app/controllers/foo.py` you'd be able to `from app.controllers import foo`, which is more useful and does an equally good job of declaring the file is a controller without having to write `_controller.rb` every time…

Or you would just use the class because it's already in the autoload paths. Seeing a lot of opinions from people who don't actually seem to use rails.

Re: Trailblazer: A new architecture for Rails

#38

Post by ehm_may »

You have my compliments and respect for undertaking an endeavor like re-thinking (and actually implementing!) rails architecture, so my apologies if my comments sound harsh or cynical. (I just want to talk about it)

I'm having a hard time understanding the need for this, especially because I'm highly suspicious of building any significant amount of abstraction on top of rails. This is because rails core is fucking insane. Besides the fact that it's in a constant state of flux, the amount of dynamic/meta/runtime fuckery that takes place makes it a living nightmare for security (and performance).

Rails already provides a highly-specific set of "convention over configuration" settings that work for most users with a basic understanding of HTTP. How exactly does this framework make those settings "better" besides re-arranging the basic set of abstractions that base rails provides (and adding more "fuckery" on top of that)?

Who is your target user group? Rails already attracts a significant number of new developers who have never worked with the web before because the abstractions are relatively easy and straightforward to understand. This is what makes rails very impressive and attractive, but, at the same time it locks a whole generation of new web developers into "the rails way" of thinking about the web (and later have to be untaught when they realize performance is actually important).

IMO If a "better" ruby web framework was to come into existence, I would encourage it to be more in touch with the basic abstractions that are already built into HTTP (see https://www.ietf.org/rfc/rfc2616.txt) and not try to over-abstract those basic concepts so that moving among http frameworks (in ruby or other) requires significant domain knowledge.

Are there any performance benchmarks? I could see a project like this unintentionally adding 2-3x performance hits (without realizing it) due to the extra abstractions.

BTW, what the fuck is up with this book? I assume you want to sell it to me in the future so that I can learn how to "properly" use your brand new open-source framework? What the fuck is wrong with a readme and a wiki, especially if you ever considered larger open-source adoption? Are you so self-righteous that you think I should feel entitled to have the pleasure of being able to download "a preview" of your e-book in your fucking readme?

Re: Trailblazer: A new architecture for Rails

#39

Post by tinco »

ehm_may wrote: post #38

You have my compliments and respect for undertaking an endeavor like re-thinking (and actually implementing!) rails architecture, so my apologies if my comments sound harsh or cynical. (I just want to talk about it) I'm having a hard time understanding the need for this, especially because I'm highly suspicious of building any significant amount of abstraction on top of rails. This is because rails core is fucking in…

Don't be an asshole man, the guy made a framework, the readme is plenty fine, and he has a nice book to sell with it. How are you so self-righteous to judge how other people should run their open source software project? How do you feel so entitled that you should get everything this guy makes for free? He is just asking for you to consider buying the book he spent a lot of effort into writing.

BTW, what's up with the crazy assumptions about performance hits? You do realize we're talking about Rails here right?

Re: Trailblazer: A new architecture for Rails

#40

Post by berkes »

gerry_shaw wrote: post #8
ebiester wrote: post #7

Earlier quoted context omitted.

Say that again after you have to learn a rails app with 1500 line models built "the rails way." Controller -> model breaks down when you reach a certain size. Or worse, giant controllers and models with no clear distinction.

You can go a long way with using simple Ruby objects to break up logic and separate out logic from models. If developers are writing 1500 line models and the lead developer isn't doing anything about it a adding new abstract concepts isn't going to help.

In a way a lot of parts in Trailblazer are just that: "simple Ruby objects to break up logic and separate out logic". Not just from models but in the views, controllers and other places too.

Lots of Rails devs go through a process like the following:

* I want to introduce a Subscription, but that is not something stored in the database, rather it creates an Order, Invoice, Account and assigns products to them. Let me create a simple PORO for that.

* Now, where to stick that? Models? For now, that will do.

* I want to introduce a Trial, which is rougly similar to the Subscription just with different parameters.

* I want to introduce an Upgrade, wich can turn a Trial into a Subscription.

... and so on.

Quickly turning your "simple Ruby objects" into an even larger mess then the mess they try to solve. So you'll be adding abastractions, giving them names and common places in your app. And there: you've just built a part of a framework like Trailblazer.

Post reply on HN