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 learn front end frameworks like Angular and React. When marketing freelance work to non-coders, the most common request seems to be to make something fast, pretty and cheap, which means focusing on static or WordPress sites.
But I'm finding that trying to reach out to potential clients the traditional way is extremely inefficient, especially when conversion rates as a newbie freelancer are basically nonexistant. And solutions for non-technical folks to manage their clients and improve their sales are expensive when it might take several months to actually earn anything.
So it seems to make sense to go ahead and put together an app that will allow me to keep track of and reach out to leads, as well as managing proposals and project documents, and provide clients with access to materials relevant to them. Once the basics are there, I'll look at integrating an invoicing API like FreshBooks to get more out of the app.
And since it's been a while since I've blogged about what I'm learning, this seemed like a great opportunity.
Over the next few weeks I'll be building a freelance dashboard app, using Rails 5.1 for the API backend, and React.js on the front end.
To follow along, it's a good idea to be comfortable working with your terminal and console, have a basic understanding of how a simple Rails app works, and to have a working knowledge of JavaScript. But I'll try to keep things simple just in case.
You can either wait for the next post to start building, or feel free to dig a bit deeper into why I went with this stack below:
Why Rails?
I'm setting aside for a moment the fact that I love working with Ruby, since it's not always going to be the best tool for the job.
For one, Rails is pretty fast and easy to set up compared to other options. Given that I intend to use this toward trying to make some income soon, being able to get something up quickly and iterate improvements is a huge advantage.
If I wanted to build the back end and front end in the same application, Rails makes that easy, too. Starting with 5.1, Rails includes Webpack and makes it easy to create apps that use front end frameworks and libraries like Angular, React, Vue, or Ember rather than jQuery. I've played around with that a bit, but I think I'd still rather separate out these two key parts into an API and a front end app.
Rails is also well-known for being a great framework for building RESTful APIs. Rails 5 even provides an API mode that makes getting a JSON API up and running even smoother.
And I have some basic experience building applications with Rails. While I want to learn new things, having some familiarity with the back end will help get this built quicker, especially since I'm picking a front end framework I have no experience with.
If I didn't go with Rails, I would have considered:
- Phoenix - Phoenix is built on Elixir, and the framework was recently brought to my attention as a more performant alternative to Rails. I definitely want to play around with the pair some, but possibly on a different project. Plus, the performance issues with Rails are generally more of a problem when it's a lot bigger than I expect this to get.
- Node.js - When working with JSON and a JavaScript front end framework, a JavaScript back end would seem like a convenient option. I've only played around with Node in small pieces, like building Twitter bots. I want to explore Node more in the future, but Rails' benefits edge out for this project.
- Sinatra - Sinatra is another Ruby-based option, one that's supposed to be great for tinier applications where Rails might just get in the way. I'm expecting this app to be a little larger than one I might use Sinatra for, though I'm eager to try it out on a project one of these days.
Why React?
React has gotten a lot of attention lately between concerns about licensing issues (which it seems were ultimately much ado about nothing) and its parent company Facebook constantly ending up in the headlines.
It seems most companies that have gone with JavaScript front end frameworks have landed with either Angular or React. From a pragmatic perspective, there are more jobs out there for either one than for, say Vue.
React is also a more mature framework than Vue, while having fewer breaking changes than Angular.
And React also has the benefit of React Native. If I wanted to implement a native mobile app for this web application, which I eventually do, React Native makes it much easier.
If I didn't go with React, I would have considered:
- Vue.js - Vue, like Ruby, is a joy to use. I've tinkered with it before to build a simple Pokémon-based monster battle game. If I wasn't going with React, I would have definitely gone with Vue to have the most flexibility with my front end.
- Angular - The other pragmatic approach, Angular is used by a lot of companies I know. It's also frequently paired with Rails.
Other Considerations
I considered breaking this project up into microservices to make individual features easier to develop and maintain, and initially started it that way. However, it's been brought to my attention that microservices should be left to situations where teams of people will be working on different services, so this project will take a monolithic approach.
And since I'll be attending RubyConf this week, posts about this project may be interrupted by posts about the conference.
This should be a fun project to work on, and I look forward to showing you along!
Top comments (6)
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.