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

11–20 of 53 posts

Re: Trailblazer: A new architecture for Rails

#11

Post by rmchugh »

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.

the author argues based on his experience refactoring legacy Rails apps that these problems are so common that they must stem in some way from the framework. I'm not sure how true this is, but my experience is that Rails doesn't give you a lot of help in defining where this extra logic should go. There are a lot of blogs and the like with differing suggestions about how to structure your Rails app, suggesting that this is a real problem and that there is no real consensus on how to fix them. Personally I'm happy to see a framework which builds on the best features of Rails while also trying to offer some solutions for applications that have outgrown the simple MVC structure.

Re: Trailblazer: A new architecture for Rails

#12

Post by rmchugh »

bithive123 wrote: post #6

The documentation would benefit from some clear examples of how the new architecture provides benefits over the existing ones. The given examples are opaque and its superiority is merely asserted, with references to concepts such as "cells" which are not defined.

the sample chapter of the book is more detailed: https://leanpub.com/trailblazer

Re: Trailblazer: A new architecture for Rails

#13

Post by disbelief »

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 better than anything else I could find.

Re: Trailblazer: A new architecture for Rails

#14

Post by disbelief »

Trailblazer looks interesting, and there are a lot of good ideas in here. One issue I have with it after reading the documentation is that the code is organized around "Concepts" and at the core of each Concept appears to be a single Model. All of the Form, Presenter, and other Operation objects live within a Model's namespace where often the @model is implicit. This works well if your business logic only applies to CRUD operations on individual Models, but in reality that is rarely the case.

I tend to use a service object abstraction based around concerns, or "business stories". My service objects map to specific scenarios or pieces of business logic that often utilize multiple underlying Models and/or other entities (eg. third party interactions services).

It wasn't clear to me whether such a scenario is discouraged with Trailblazer, or maybe not even possible.

Re: Trailblazer: A new architecture for Rails

#15

Post by christiangenco »

Huh, this is interesting. I've been getting more into Meteor[1] lately, and I see a few things here that mirror my experience there:

* Concept-Driven directories (ie: having your model, views, controller, etc. for everything Comment related in the same directory). Meteor still hasn't figured out what directory structure it wants (you could make up your own and things would still work), but I've seen this in several places.

* having an object for each view (I didn't like this about Meteor at first, but it's really just stripping out logic that would have been in the view and putting it somewhere else. It actually makes it a lot easier to debug layout vs. code errors by having the view be as simple as possible)

* I was going to say use of monads, but a) I'm not sure that's what the "call style" and "run style" actually are, and b) Meteor doesn't really use monads, now that I think about it

I'm sure nothing here is unique to meteor either, but it's interesting to read about stuff like this with the added perspective of another framework.

1. https://www.meteor.com/

Re: Trailblazer: A new architecture for Rails

#16

Post by sbov »

christiangenco wrote: post #15

Huh, this is interesting. I've been getting more into Meteor[1] lately, and I see a few things here that mirror my experience there: * Concept-Driven directories (ie: having your model, views, controller, etc. for everything Comment related in the same directory). Meteor still hasn't figured out what directory structure it wants (you could make up your own and things would still work), but I've seen this in several p…

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.

Re: Trailblazer: A new architecture for Rails

#18

Post by jamie_ca »

disbelief wrote: post #14

Trailblazer looks interesting, and there are a lot of good ideas in here. One issue I have with it after reading the documentation is that the code is organized around "Concepts" and at the core of each Concept appears to be a single Model. All of the Form, Presenter, and other Operation objects live within a Model's namespace where often the @model is implicit. This works well if your business logic only applies to…

You can definitely compose operations, and have an operation that deals with multiple database models. The sample chapter from his book goes into a little bit of detail about it near the end, but TLDR you use a Twin object that has a reference to both of your dbmodels for defining (or delegating) validation and form building.

Re: Trailblazer: A new architecture for Rails

#19

Post by jamie_ca »

picardo wrote: post #17

This "architecture" changes so much about Rails that I don't know why it's trying to build on Rails at all. If you don't like the Rails Way, just create another framework.

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.

Post reply on HN