Learn Ruby on Rails Book

Frontend Backend Separation

In the last chapter we are showing the tasks information on the UI. We accomplished it by taking the data from the database. Putting the @tasks value in an instance variable. @tasks value was passed to app/views/tasks/index.html.erb. This index file calls app/javascript/components/tasks/List.js component and passed the tasks as props.

In this case we can see that all React components reside in directory app/javascript/component. All controller code reside in directory app/controllers. The Rails views are at directory app/views and these views are acting as the data carrier layer. The view files take the data from the controller and invoke the right React component and passes this data.

This is the one way to handle frontend and backend code. We will call this Rails monolith architecture.

Another way to design the application is by having pure APIs.

Backend as a pure API

Some companies like to have clear separation between frontend code and backend code. They go to the extent of having two different repositories - one for the backend and one for the frontend code.

In this architecture the backend acts like a pure API. The backend returns just json data. The frontend takes up that JSON data and acts on it.

Let's see what are the benefits and downsides of this architecture.

The biggest issue in such architecture is that frontend code is deployed separately and the backend code is deployed separately. It means the frontend team and backend team needs to spend a lot of time coordinating when to deploy and how to deploy etc. If a feature requires both frontend change and backend changes then merging that pull request and testing that pull request becomes problematic.

In the Rails monolith case pull request reviews are much simpler since both the frontend and backend code are in the same pull request.

In the API case it is much easier to onboard frontend engineers since they do not even need to install Rails on their machine. It makes it easier to hire and scale team.

In the API case developing a feature that requires both frontend change and backend change takes more time since frontend team and backend needs to discuss a lot more often. Same is the case when it comes to fixing a bug. More coordination is needed.

In the case of API the authentication must be using a token and not a cookie. This is not a big issue but something to aware of.

In the case of API architecture for certain cases there might be CORS issue since the frontend code and backend code are served from two different domains.

In the case of API architecture the code can be served as static asset since it does not need to go through an application server. If the application server is rightly configured then this will help only in the case of first hit since after that ideally browser should be caching all frontend code.

Choose design that works best for the team

As everything in software engineering the answer to which design is better is "It depends". It depends on the team composition. If most of the team members are full stack engineers then probably Rails monolith architecture is better. If the team has very specialized frontend and backend engineers then probably API architecture is more suitable.

There is nothing to commit in this chapter since all we had done was learning the basics of frontend-backend separation.