Frontend–Backend VS Full-stack Development: “Divide and Conquer” or “Join Together”?
In our experience, there are two opposite approaches to software development. Neither can be called unique, and each has already been described many times. However, I would like to compare both approaches to explain why software companies prefer one over the other.
I’m referring to frontend–backend and full-stack development. As frontend–backend development is more common for large projects, most of our customers that have accepted this approach have been pleased with it. Thus, I was so surprised to find out that some companies refuse to use it.
First, let’s take a glance at the history of programming to understand the background of each approach.
Divide and Conquer
From the very beginning of programming, a single person could write a complete software program from start to finish. Such programs had only one layer and needed only one computer to run. Connecting computers into networks changed software development.
Typically, modern software systems include client-side or frontend (everything clients see on a web browser, smartphone, desktop, etc.) and server-side or backend (the aspects that enable the components to communicate with each other to fill the frontend with data, such as applications, server, database, etc.).
Creating backend requires Java, Hibernate, SQL databases (MySQL, PostgreSQL, etc.) or NoSQL databases (MongoDB, Neo4j, Couchbase, etc.) and frameworks such as Spring MVC, JSF, etc. This list is not exhaustive — each project requires certain technologies depending on its specification.
Software systems may have many layers and tiers (multi-tier architecture), each of which uses complex technologies. Thus, programming has evolved into a process that requires teamwork. To create a software system, specialists in each technology type are needed. Programmers are now divided into frontend and backend developers, and each developer is an expert in the technologies they work with.
Example: A team contains two frontend developers and three backend developers. Integration on both sides is implemented via API (Application Programming Interface). Each developer is an expert in their stack and can execute any challenging task on their own side; however, they also need to be informed about required and executed changes on the opposite side.
In some cases, dividing development into frontend and backend can be inefficient. The main reason for this is poor communication. Frontend developers are not always fully informed about changes in the backend and API, or vice versa. Because they are experts in a narrow field, developers cannot check what’s wrong. Finding mistakes takes time from developers on both sides.
Thus, frontend-backend integration requires effective communication. When distributed development teams are working in different time zones, this issue becomes a real problem.
Example: A backend developer and a frontend developer are in time zones that have a difference of eight hours or more. The backend developer has made some enhancements and sent an email to the frontend developer describing all changes, but has missed one parameter that was changed. The frontend developer tries to implement the changes but fails because they are lacking this piece of information. The time difference doesn’t allow the frontend developer to connect to the backend developer immediately, so the former writes an email to describe the problem. The next day, the backend developer sees the mistake and sends the missing information. The frontend developer then succeeds in implementing the changes.
This example shows how one minor mistake can delay the result by one day. And what if there are multiple mistakes? They may delay progress by several days.
This problem created demand for developers that are acquainted with technologies used on both sides; that is, full-stack developers. If a mistake appears, a full-stack developer can check both sides, frontend and backend, and find and fix the mistake themselves. Thus, the development avoids these delays.
Besides the above, all projects involve periods in which there are no or fewer tasks for one side (client or server), and many tasks on the other side. In this case, a full-stack developer can switch to any task. On the contrary, a frontend developer cannot undertake backend tasks, and a backend developer can’t execute frontend tasks; without tasks to complete, these developers will be idle.
This new tendency to have one full-stack developer instead of a frontend and a backend developer appears not only to be time efficient but also cost effective. However, full-stack developers have less expertise in each technology compared to dedicated frontend or backend developers.
So, Separate or Unite?
Of the two approaches to development above, both are good, and neither is definitely superior. Let’s consider the main features of each approach, and their pros and cons.
Frontend–backend development. The separation of development into frontend and backend was driven by changes in programming: application architecture is now primarily multi-layered, and each layer requires solid knowledge in the technologies used because the technologies themselves are complex.
For a large project with a plentiful budget, a team can be gathered with experts in every field, including designers, web developers, mobile developers, backend developers, database developers, etc. Backend and frontend should be able to react quickly to each other’s requirements in order not to maintain the speed of the development progress. However, when two or more people work together, problems may arise from poor communication or misunderstanding of goals, scope, terms, etc.
Thus, the main plus of separate development is that an expert in each required technology can be hired. The minuses of this approach arise from the integration between frontend and backend and communication issues, which may cause bugs, progress delays and even development failure.
Full-stack development has recently become more popular. This is partly because the line between frontend and backend is very thin, but mainly because frequent problems in development arise from miscommunications between front- and backend developers. A full-stack developer can identify problems and inefficiencies in integration before they happen, and thus help avoid such issues. The developer can also solve problems without other developers’ help. In addition, a full-stack developer can undertake any urgent task and is never idle due to lack of work.
Thus, the main plus of united development is that fewer miscommunications arise and any developer can solve any task, whether it is frontend or backend. The minus is that it’s not always easy to find a jack of all trades: a full-stack developer cannot be an expert in all the required technologies.
One other approach is possible: hybrid development. Here, the team includes frontend and backend experts for challenging tasks and full-stack developers for frontend and backend integration. In this case, miscommunication is almost impossible because full-stack developers can solve problems themselves. At the same time, if a task requires solid knowledge of a specific technology, each expert can undertake and execute it in the best way.
In some projects, we have already tested this approach and found it to be efficient. For example:
Project A: The full-stack developer we hired was not an expert on both sides. However, he had knowledge of all the required technologies and understood how to integrate both sides. Where integration problems arose, the full-stack developer was aware of his responsibility and was thus unable to blame anyone for issues except himself! 🙂
Project B: The team contained several full-stack developers and one frontend developer. The frontend developer was 100% expert in frontend technologies and had about 10% knowledge of backend technologies. The full-stack developers were 100% expert in the backend technologies used and had 30–50% knowledge of the frontend technologies. Thus, the full-stack developers could execute all backend tasks and most frontend tasks. Difficult frontend tasks that required solid knowledge and experience could be implemented by the frontend developer.
So, among the pluses of hybrid development, I would highlight that a full-stack developer makes the team more universal and agile; frontend and backend developers may execute difficult tasks, while the full-stack developer implements integration. The main minus of this approach is that it is not that easy to find a qualified full-stack developer, though such a specialist can be ramped up.