What are best practices for structuring a scalable fullstack project (frontend + backend) on GitHub?

[wilfried-djoum]

🏷️ Discussion Type

Question

Body

I’m currently working on a fullstack project and I’d like to know how you usually organize your repositories.

Do you prefer a monorepo or multiple repositories?
How do you structure folders for frontend and backend?
Any tips for maintainability and collaboration?

Thanks in advance for your insights!

[0xZeroSecurity]

I usually prefer a monorepo for most fullstack projects unless there’s a clear reason not to. You can change backend + frontend in one PR without things breaking out of sync.

[Rajesh-sahu762]

A scalable project is one where new developers can understand it quickly features can be added without breaking things logic is separated cleanly .
Focus on clarity > cleverness.

[jegasape]

Hey! @wilfried-djoum

Great question, and to be honest, there is no real right or wrong answer, it depends on your project and your team., However, I'll give you a rundown of what has worked for me after messing around with different solutions and getting burned a few times.

First off, monorepo or separate repositories. I started off by doing separate repositories for everything, as I thought that was how you're "supposed" to do it. Boy, was I wrong. Every time I changed something in the API, I would have to switch over to the other repository to change something in the frontend, and it was a real nightmare keeping versions in sync. I ended up switching over to a monorepo, and I have to be honest, I don't know why I ever went with separate repositories in the first place.

Now, I know this might be a good option for a large company with a team for each service, but for a small team that's doing everything, I would definitely recommend a monorepo.

The repository structure that I usually follow is:

project/
├── apps/
│ ├── web/
│ └── api/
├── packages/
│ └── shared/
├── docker-compose.yml
├── .github/workflows/
└── README.md

For branching, I keep it simple: protected main, feature branches, PRs with at least one review, and squash merge. Git flow is great on paper, but in reality, it's just too much for most projects.

So, that's my take on it, and I'm sure your case might be different, and some of the above may not be applicable to you. If you want me to go into more detail on a particular point, feel free to ask!

[wilfried-djoum]

Hey!
Honestly, I prefer a single repository. It allows you to limit repo changes every time you make a modification, whether it's on the front end, back end, or pipeline. As you said, it's really relative; everyone has their preferences depending on their team or practices. I'll finish by saying that I have practically the same structure as you, except that I've separated each folder according to its role in the application. For example, in my repository, I have a front end folder, an API folder, a workflow folder, a reverse proxy folder, a Docker Compose file, etc.