We have our web application built completely on Ruby on Rails. The front end is tightly coupled with the backend. We are in a stage where we want to gradually start separating our frontend from the backend. We want to go ReactJS way with the UI part and we want to follow the waterfall model for the transition.
We have two options:
Use gem called react-rails, and build new components in React. Slowly start converting existing components into React components. Once we have all components converted into React components, take out every React component, separate complete frontend and host it somewhere else.
Host ReactJS somewhere else. Gradually start converting each component to React component, move it to new hosted place and remove them from Rails. The only catch is, React components will be located at a different location than where Rails is. While navigating within the app, it could give a feel of navigating to a different website.
Please share your experience and guide us on which way should we proceed. Our end goal is to have the complete front end in ReactJS and backend on Rails. They communicate via APIs, completely removing coupling between frontend and backend.
Thanks
Use #1 only if you plan on keeping rails in the server rendering mix (not recommended). If not then #2 is your best option to just start from scratch with a complete js solution. It doesn't have to feel like a different site if you create a decoupled react component library and a rendering pipeline to the existing rails app when it needs the new views. Then when you have converted all the view components you can wrap up the app logic and make the switch over entirely.
Another option is you don't even need to host the new react components seperately, the react components can go through a separate build cycle, then cached on the existing server and rendered as needed from rails.
I would actually NOT recommend going away from your Ruby centered system. You can use http://ruby-hyperloop.io to build your react.js components in Ruby. Hyperloop includes a Ruby DSL (HyperReact) for react, and HyperMesh which will give you complete access to your ActiveRecord models in your React components.
The huge advantages are you will deal with one language throughout, you do not need to build APIs just to access your data down at the client, and you can use the existing rails tool chain including test tools.
There is a huge library of React.js components which interoperate fine with HyperReact.
If for whatever reason you feel that it would be better to go the JS route then I would recommend react-rails. It works, is well supported, and handles prerendering (a very important concept.) You can easily integrate with NPM and webpack as well.
Related
I am just trying to get a better understanding of the full stack in development and all the different frameworks etc have gotten confusing in my head and I just want to try and wrap my head around everything. The main question is: What are the main differences between the front end, back end, database, and how do things like say Google Cloud Functions fit into all of this?
For instance, ReactJs is a frontend framework (technically library) that helps you build fast and responsive front ends using components. So with reactjs I could create a front-end to a web page with buttons and logic for moving around and showing data.
So in this case when and why would I add on a backend? For processing large amounts of data or running calculations is a good idea but how does this actually fit in? For instance Ruby on Rails uses the MVC framework so if I added Rails to a ReactJS project would the Reactjs part essentially just become the V (view) of the ruby on rails project? How does this compare to node.js and django? Why and when do I even use all of these?
Next, when adding databases into the mix when should I be using the front-end to use the database and when should I use the back end? For instance in a react app I could send and receive data from a firestore nosql database from the frontend but I could also make a ruby on rails app that creates migrations to alter the schema in lets say a postgresql database. So when and why should I be using each method?
Finally, one of my main questions is how do cloud functions fit into all of this? Do cloud functions just take away the "back-end" portion of the equation? I haven't used them but wouldn't you still have to write functions that take an input and spit back an output? Is the only difference with cloud functions that they are easier to maintain since you don't have to set up your own server?
What would common tasks and their differences be between a front-end and back-end developer?
The front-end talks to the backend. The backend then talks to the database, and relays info back to the frontend. The cloud is just a place to host your front/backend/database. Front-end developers build the User Interface (buttons, forms, screens, etc). Backend developers build the services that the front-end will push/pull data from, which it typically stores/retrieves from a database.
I have started a new project in which I would like to use React and Rails. This project is on the small side and will require some basic interactive UI, hence React. As far as I know there are two ways I could get started with this:
Using the react-rails gem and use the built in view helper
Create a Rails API and React/Flux frontend app
I have a few questions however. In no particular order:
React-rails seems like the simpler solution, but what drawbacks would I be facing?
I come from a Rails and Ember background so the Rails API + React FE solution makes architectural sense to me. But with the react-rails gem I'm confused on how some things should be done. Primarily, how do I handle routing? I suppose I won't have access to any react route helpers and will need to pass paths into the react components as props?
Thanks in advance!
For a small project React-Rails, https://github.com/reactjs/react-rails, is great I have used it in production the last year on 2 sites that get about hundred thousand visitors a month and I haven't had any issues.
That said if you want to use Redux, React-Router or Flux don't use React-Rails go the API route.
My rule is if you are just using React components then use React-Rails.
If you are doing a Redux, Flux app then just make a frontend app.
It depends on how much your server is doing and also your team. If you have a lot of business logic that you want to keep in Rails, then you may want to have that logic running on a dedicated Rails server and expose as APIs.
You can then have a NodeJS server that does nothing but fetch data from APIs and render React to send to the users. The only interaction between react and rails is via the APIs as JSON. This basic setup will scale really well and is a pretty simple mental model.
If the project gets bigger, this means you can have JS-only devs work in JS only and Rails devs work in Rails only. Plus if you want to move away from Rails or React later, there's no added complexity there.
OR
If all your devs are React+Rails and the project is a bit small for multiple servers, then I think using react-rails to serve up your pages is a fine solution.
I've been using Ruby on Rails since a little more than one year now and I've always do it in a casual way, I mean, everything in one place (front & back), using the standard .html.erb file populated by the associated controller method.
Otherwise, today in our project, I have the need to separate the front and the back end for multiples reasons (code maintainability / clarity, better architecture, more reactivity, etc...).
I've done plenty of researches, watch some conferences (1, 2, 3), but didn't find my solution yet. It looks like to be a question that comes often, but what is the best practice/tools to separate the backend and the frontend of a Ruby on Rails app?
I don't feel we need (yet) a huge JS framework like React/EmberJS/Angular/etc...
First I was thinking about something like Middleman/Jekyll and make the communication via JSON and API calls, but it seems like that it's not a good solution for dynamic website.
So is there a frontend framework that works well with a Rails API and which is easily maintainable and upgradable (add feature/extension to it like gems)?
Thanks for your insights.
A friend of mine wrote this great article/tutorial on Rails as a backend API.
http://blog.launchacademy.com/the-basics-of-building-an-api-in-ruby-on-rails/
As well as this tutorial on Rails/Ember.js
https://github.com/diegodesouza/Project-Planner-EmberJS
You can get an idea of how it's done and implement your preferred front end framework.
Hope it sheds some light on this question.
I have a similar setup as one of the commenters on the question.
I'm using Rails mainly for just the project structure, to define some page layouts, and for ActiveRecord.
I then have my JSON APIs defined using the Grape API framework.
I have a SPA, written on AngularJS that lives in the public/ folder. It doubles as my mobile app, made possible by phonegap. If my Angular app didn't double as my mobile app, I could've possibly just used the asset pipeline to serve up the SPA. To compensate for that, I have a separate build task written in Grunt to minify/uglify my JS/CSS assets before I deploy them out to production.
I also use Comfortable Mexican Sofa for my static content pages.
It took some trial and error to get things right, but overall I find that this setup serves me pretty well.
We have a project that is going to have multiple Single Page Apps (eg. a Calendar app, a Budgeting app, etc.) built in AngularJS and using Rails as a back-end. It will also have a large part of the site operating as a normal Rails site - ie. RESTful MVC (eg. resources :users, :events, ...).
In the past, our SPAs have lived on a separate server from the back-end, which was delivered by a third-party (Quickbase) and wasn't under Version Control. Now that we're going to be controlling and developing both the SPAs and the RESTful Rails site/back-end the question is how connected/separate should these components be?
Since the SPA will rely on the back-end for data, does that couple them enough that it should be included as part of the same Git repo?
Or should they be separated for the sake of maintainability, ease of development, modularity, etc. particularly since they could each be seen as standalone pieces of work?
Should the SPAs be kept within the Rails directory structure so that they can be served up by Rails and take advantage of the asset pipeline, etc?
If the SPAs should be kept within the Rails directory structure but should also be separate in version control, how can that be done with them sharing a directory structure?
Not a rails developer but just tossing in my two cents. I do full stack development MySQL -> PHP (Slim PHP framework for routing/RESTfulness), AngularJS. Currently my workflow is to have all the PHP and AngularJS for a project in one Git repo, really this flows from using Grunt though rather than being a fully conscious decision. I use Grunt to run the live reload server and added a bit to the base configuration (from yeoman) to handle the PHP portion so that also causes a live-reload which is nice during development.
Regarding code separation, having a RESTful interface for the backend that is completely decoupled from the front-end is your best route, since this leaves you open to completely re-write the front-end without changing the back end (or vice versa). I'd say anything that breaks this isn't really worth it, if you can't maintain this abstraction you lose the ability to replace one part without rewriting the other.
I would say if you have a piece of the Rails back end code you feel can truly stand on it's own and be used on various projects then perhaps that part should be extracted into it's own repo.
Most of the resources/example about rails and angular on the internet just put them together. AngularJS goes inside of rails under app/assets. This feels reeeaaaly dirty to me. Is it a good idea? What if we decide at some time we won't be using rails and we move to, I don't know, sinatra? How hard would it be to port?
What would be pros/cons of everthing in a single rails app and what would be pros/cons for two seperated apps?
Thank you!
Even when placing Angular (or any other client-side MV* framework) inside your Rails app, you are pretty much keeping the separation of concerns intact. That is, you have a Rails API serving JSON (or similar) data, and a separate Javascript framework using that data to render appropriate views. If you ever wanted to use a different server-side API, you can do so, and still utilize your entire Javascript directory as is.
Placing the client side framework in Rails is simply a matter of convenience. It comes with an organized directory structure and the ability to serve your HTML, which is essentially all you're using it for when it comes to your views. But again, these views aren't really tied to Rails, as they're just HTML and Javascript, so you can easily move them to a different platform when necessary.