Search
⌘K
    to navigateEnterto select Escto close

    Frontend backend separation

    In the last chapter we showed the tasks information on browser. We accomplished it by taking the data from the database, creating @tasks instance variable and passing this instance variable to app/views/tasks/index.html.erb.

    This index file calls app/javascript/components/tasks/List.js component and passed the tasks as props.

    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 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 the frontend code and the 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 the 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 the backend code are in the same pull request.

    In the pure 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 to scale the team.

    In the pure 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 pure API, the authentication must use a token and not a cookie. This is not a big issue but something to be aware of.

    In the case of pure 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 pure 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 the 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.

    Previous
    Next