To separate or not to separate frontend and backend?

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:

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, 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.

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:

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

Since it's an open source project, 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)

There are some specific things, like the openapi, or wiki pages 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
I still need to transfer the GitHub Issues 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 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.