In my rush to try to earn something from my code learning so far, I've had to shelve some of my plans to dive deeper into Ruby on Rails and to lear...
For further actions, you may consider blocking this person and/or reporting abuse
I've just been through a very similar thought process on a new project, and settled on monolithic Rails API and React/Redux SPA for similar reasons. Out of interest are you planning to have the React code within the same repo as the Rails API and deploy them together? Or will the React side be stored in some other repo and deployed separately>
Planning on separate repos. This seems like a project where it'd be convenient to eventually have a native mobile app, so I'm going to try to develop so that the API can be developed and updated separately from any front end/app that may connect to it. But I'd love to hear about others' approaches.
I've heard that rails has not aged that well and is slower than the same application implemented with node.js, can you confirm/deny this?
Great question. I'd love to hear from someone with more knowledge/experience, but this is my understanding:
I don't think a benchmark comparison between Node.js and Rails really works since Rails is a framework built on Ruby; for example, Sinatra doesn't have the same bloat. If I'd have chosen Node.js, I still would have needed to weed through the numerous Node frameworks to pick one for the project (part of why I didn't for this one).
And as far as aging goes, Rails seems to be keeping up with changes in the industry, for example: switching from jQuery to making it easy to implement more modern JS libraries and frameworks using Webpack. Changes aren't as rapid as some of the newer frameworks out there, but it's understandable to try to avoid breaking changes when you have a large number of existing companies using the framework. In fact, while the infatuation phase is over, Ruby's maturity is a benefit in terms of finding plenty of well-maintained, stable, production-tested gems; you can quickly gauge the reputation of each gem.
Rails was designed on top Ruby to rapidly build Minimum Viable Products and powerful web applications while optimizing developer productivity and happiness. It's for getting launched quickly with as few developers as a team can manage on a shoestring budget. It does have issues with performance as it scales, but when using best practices, the app needs to be almost Twitter or Netflix big for it to become a problem.
It seems common for companies to build and start scaling up their apps in Rails and then switch pieces of their services over to something like Node or Java as the need arises, and that seems pretty sound to me. By then they also have teams of developers in place and are looking to optimize their architecture anyway.
Either that or they'll work with Elixir/Phoenix, which seems to be very Ruby/Rails-like, but solving the problems that have been found over time, like performance. It was a close call for me between Rails and Phoenix, and if I'd had prior experience with it, I may have gone with Phoenix on this project.
Other frameworks, languages, and tools are built for different reasons and with different priorities. No tool is the best for every web application, and that's largely why this Day 0 post exists.
I don't dismiss Node and will build later projects with its frameworks because there's a lot it's great for (hence its popularity). I just don't think it's the best tool for this project.
I love your approach to thinking about all this. Any thoughts of open-sourcing the app?
Thanks, and absolutely. The API repo is up (still very early - will start working with the models this weekend after RubyConf). Once the crucial features work, I'll open up one for the React side.