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?
- Dividing frontend from backend is an antipattern
- What are the advantages if one separates frontend framework from backend or integrate frontend framework with backend?
- Divide or Join: The Frontend Backend Dilemma
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.
Top comments (0)