3 ms·

I'm somewhat split on the author's opinion here. I also picked up Rails back in the day (I think the first version I installed was 0.8), and I have a bit of a l

I'm somewhat split on the author's opinion here. I also picked up Rails back in the day (I think the first version I installed was 0.8), and I have a bit of a love/hate relationship with it. As a framework for building comventional HTML templated database backed websites I still think it's near unbeatable, especially with the addition of a few common gems. However it so often gets shoehorned into other places - API backends, rich client apps, and massive systems. Places where the Rails conventions rapidly go from everything falling into place to getting in the way and needing to be worked around, or heavily tuned. I completely agree that ActiveRecord is the core of why big Rails applications are complex to work with and often exhibit disproportionally poor performance. It doesn't lend itself well to composition, and results in data persistence being intertwined with business logic. That's fine for early prototypes, and in all honesty will get you to market quickly, but it makes extracting the concepts you discover during development into a coherant API much more complex than I'd like. These days I still use Rails for the aforementioned HTML generating web applications, but it's often acting as an API client to systems built on top of a Grape based backend, with an API built around service objects and a simple data access later.

keithwhor 10y ago
Interesting you bring up the point about API backends. I'm the author of Nodal [1], with the goal of bringing the best design patterns and practices from Rails and Django to the world of Node, focused completely on building a decoupled API layer. There is no view / template logic at all. The project is very lightweight right now (benefits of being a young project with a sole full-time contributor), but I'd be interested to hear your feedback as to what you think is or isn't necessary for continued development. :) [1] http://github.com/keithwhor/nodal http://github.com/keithwhor/nodal
- jon-wood 10y ago
  Interesting, I think I came across Nodal while evaluating options for a side project a while back. Having just taken another look the big thing that seemed to be missing was something to serialize objects to JSON, although that may be because serializing objects is so trivial on JavaScript anyway. There also didn't seem to be much documentation about the operational side of things, most glaring was nothing being said about how the scheduler actually schedules jobs and ensures they get run.
  - keithwhor 10y ago
    Scheduler is actually still a WIP. I've changed the core around significantly in the last few releases, which has changed how the scheduler operates. That's why there's not much around it. ;) We serialize models to JSON automatically in the response layer, and all models have a `.toObject()` method that takes an optional interface (which keys to actually serialize). There is full API documentation but I still have a lot of work to do creating more fleshed-out tutorials. :)
    - jon-wood 10y ago
      The issue I have with just having a toObject or to_json method is that context is everything when serialising. Different access levels, different client types, and just different parts of an API call for different ways of sending data to end users.
      - keithwhor 10y ago
        Which is why you very clearly specify the interface whenever .toObject is called (which fields are exposed). By default, everything is included, but you have complete granular control. It's what allows us to do things like have full GraphQL support. :) http://graphql.nodaljs.com/ http://graphql.nodaljs.com/

keithwhor 10y ago

Interesting you bring up the point about API backends. I'm the author of Nodal [1], with the goal of bringing the best design patterns and practices from Rails and Django to the world of Node, focused completely on building a decoupled API layer. There is no view / template logic at all. The project is very lightweight right now (benefits of being a young project with a sole full-time contributor), but I'd be interested to hear your feedback as to what you think is or isn't necessary for continued development. :) [1] http://github.com/keithwhor/nodal http://github.com/keithwhor/nodal

jon-wood 10y ago
Interesting, I think I came across Nodal while evaluating options for a side project a while back. Having just taken another look the big thing that seemed to be missing was something to serialize objects to JSON, although that may be because serializing objects is so trivial on JavaScript anyway. There also didn't seem to be much documentation about the operational side of things, most glaring was nothing being said about how the scheduler actually schedules jobs and ensures they get run.
- keithwhor 10y ago
  Scheduler is actually still a WIP. I've changed the core around significantly in the last few releases, which has changed how the scheduler operates. That's why there's not much around it. ;) We serialize models to JSON automatically in the response layer, and all models have a `.toObject()` method that takes an optional interface (which keys to actually serialize). There is full API documentation but I still have a lot of work to do creating more fleshed-out tutorials. :)
  - jon-wood 10y ago
    The issue I have with just having a toObject or to_json method is that context is everything when serialising. Different access levels, different client types, and just different parts of an API call for different ways of sending data to end users.
    - keithwhor 10y ago
      Which is why you very clearly specify the interface whenever .toObject is called (which fields are exposed). By default, everything is included, but you have complete granular control. It's what allows us to do things like have full GraphQL support. :) http://graphql.nodaljs.com/ http://graphql.nodaljs.com/