To separate or not to separate frontend and backend?
Tags: webdev, git, productivity
Published: 2020-04-28 05:09:28

---
title: To separate or not to separate frontend and backend?
published: true
description: Discuss whether to separate frontend and backend of an application in different projects, github repositories etc.
tags: discuss, webdev, git, productivity
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/9jc2ly2ydjoy37ycu7d7.png
---
> Just to set the ground here - the **frontend** is the part running in the browser and the **backend** is the part running on the server

There have been some discussions around this topic like:
* [Is it common to separate back-end and front-end into two positions on web development projects?](https://softwareengineering.stackexchange.com/questions/107503/is-it-common-to-separate-back-end-and-front-end-into-two-positions-on-web-develo)
* [Dividing frontend from backend is an antipattern](https://www.thoughtworks.com/insights/blog/dividing-frontend-backend-antipattern)
* [What are the advantages if one separates frontend framework from backend or integrate frontend framework with backend?](https://dev.to/akwetey/why-should-you-separate-frontend-from-backend-or-integrate-frontend-with-backend-89d)
* [Divide or Join: The Frontend Backend Dilemma](https://opensenselabs.com/blog/articles/frontend-backend)

The conclusion is more or less that **it depends**. It depends on the size of the project, the technologies employed, the people' skills working on the project, "established" ways of developing software in the company, politics, whether is open source and so on.

> In the mean time I tend to favour, where possible, a project with both frontend and backend, as it maps better to the agile way of software development, of which now, after many years of trying different approaches, I am a supporter

In this post I will list briefly some aspects after having joining the frontend and backend of a project. The project I've been working on is [www.bookmarks.dev](https://www.bookmarks.dev), and since inception frontend (Angular) and backend (ExpressJS) held separately, i.e. two projects and two git repositories. I guess I was biased back then from all the enterprise projects I had worked on. In enterprise software development the frontends are usually separated from backends, and most likely there are even different people/teams working "separately" on them. I think this is an outdated approach though, as more and more companies are trying the do the agile way.

Anyway, that was the case until recently (2 weeks ago at the time of this writing), when I decided to merge the two projects in one, which is now available at [https://github.com/CodepediaOrg/bookmarks.dev](https://github.com/CodepediaOrg/bookmarks.dev).

Well, here are the **pros** and **cons** after two weeks of "frontbackend". 

## Pros

### One project in IDE (in my case IntelliJ)
It's so much easier to navigate through files, terminals, searches when everything is together.
Just look how nice my terminal overview looks like now:
 ![Terminal overview IntelliJ](https://dev-to-uploads.s3.amazonaws.com/i/v7osspb0gsyfpo1nv44g.png)

#### Debugging
This has become much easier. I am now able to set breakpoints for both frontend and backend in the same window in IntelliJ

### One entry point on [Github](https://github.com/CodepediaOrg/bookmarks.dev#readme)

Since it's an [open source project](https://github.com/CodepediaOrg/bookmarks.dev#readme), it is now easier for potential contributors to join the project. 

### Git history
When I add a new feature I usually modify both frontend and backend, and now with one commit (thank you `git rebase`) I can see in one diff what needed to change for the feature.

> I struggled many times in the past finding the "matchin" commit in backend or vice-versa


### Development of new features (case for agile development)
As mentioned in the point **Git history** above the development of a feature usually touches both frontend and backend.

### [Consolidated documentation (entry point)](https://github.com/CodepediaOrg/bookmarks#readme)
There are some specific things, like the [openapi](https://www.codepedia.org/ama/key-takeaways-when-using-oas-3-to-document-an-expressjs-rest-api), or [wiki pages](https://github.com/CodepediaOrg/bookmarks.dev/wiki) for backend setup but it sort of feels better to have one entry point for all

## Cons
 * I've sort of gave some Github stars away when [archiving the frontend only  part](https://github.com/CodepediaOrg/bookmarks.dev-frontend-only-archive)
 * I still need [to transfer the GitHub Issues](https://help.github.com/en/github/managing-your-work-on-github/transferring-an-issue-to-another-repository) to the new project 


## Conclusion
As the project evolves I will  complement this list, but what is your experience regarding this issue? Please leave a comment below.

For the time being the **pros** outweigh the **cons** for [www.bookmarks.dev](https://www.bookmarks.dev) and I will stick with it. For future projects I guess I will start the other way - joined frontend and backend and split them apart afterwords should it be the case.