In the last chapter we are showing the tasks information
on the UI. We accomplished it by taking the data from the database.
@tasks value in an instance variable.
@tasks value was passed to
This index file calls
In this case we can see that all React components reside in directory
All controller code reside in directory
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.
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.
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.