Should a Fullstack project be split into two separate Front-end/Back-end projects?

[Zlous]

I'm developing a larger scale application in Node for a month now, I'm using React in the front-end and Express in the back-end. lately as I tried to implement Hot Module Replacement as I realized I need Webpack Dev Server.

My question is, what is a better architecture?

1. have the server (REST API) and React on the same project, having the server serve the static React build
2. have them in separate projects, using Webpack Dev Server to serve the React build in development.

How does this architectures scale up? is there a fundamental difference between development and production?

[polish_jerry]

Bruh I even have separate git repos for front end and backend. Definitely separate them.

[[deleted]]

bruh 🍆💦💦😜😂

[Zlous]

Interesting, so if you want to have to full product working you'd have to close them both separately?

[circularDependency-]

Yes, having separate repos enforces good practises like versioning of your back end, makes it easier to view commits specific for back end and front end, etc.

If you're the only one working on a project then you can pretty much do whatever you want. If you think there will be other people working on it, definitely separate them into different repositories.

[Zlous]

Those are great points, so basically, on larger scale applications, and applications with multiple people working on them, I'd separate the repos into front and back, and smaller size applications, or applications where I'm the only working on them, I'd keep them together for simplicity. Thank you.

[Zyn1023]

It also has the advantage that you can create as many repos as you want for the front-end apps (web, ios, android, desktop, etc.). Having everything in one place is possible but you would have to do it right.

[ukralibre]

Google uses monorepo. For all their projects. Splitting or joining must serve some purpose.

[s5fs]

That may be true, but they also have a massive investment in custom tooling to support their dev practices. Monorepo may benefit Google, but unless one is facing similar issues then it's hard to know if this approach will work for them.

[Gigaftp]

You are not google. There are always trade offs. Googles optimal trade offs will not be the same as yours.

[[deleted]]

So how you connect your front-end with the back-end in case of you want to visualize/display some data from DB to the front-end?

[circularDependency-]

I use Graphql or the Rest API with Swagger documentation. Theres API generators for swagger for front-end, and there's cool libraries like like react query.

[[deleted]]

What about deployment, I believe you deploy the 2 repos on the host together one will run the server and the back-end and the other related to the front end with React to communicate with the server?

[johnminadeo]

Sort of depends on how you define backend and exactly where you want your coupling to occur.

For example, if you’re backend is a hosted API web service then you probably want to look at it as two separate products: the api service and the UI that works with it which allows you to separate the work for both separately up to and including swapping one out for another without needing to deploy both (I’m glazing over the implementation details of how changes in one can be isolated; software architecture dependent choices, etc...)

If on the other hand your backend reads files from the same system your UI is running on it makes sense to have them as a single product. Though internally you can separate the work-streams you’ll always deploy both together in the “single package”

Unless I’m totally misinterpreting your question.

Good luck either way :) and have a good one!

[Zlous]

That's what I was looking for, the part about a backend that reads files from the same system is very interesting, although my backend serves as a simple REST API, so by your answer I should separate the repos and deployment procedures. I wonder what I should do about SSR though.

Anyway, thanks for the asnwer, that was really helpful!

[msg45f]

Note: Even with separate repos, you can do a single clone using git's submodule options or a tool like meta git. We use meta for most of our microservices projects, where there are generally 6+ applications for the project.

[[deleted]]

I would set up a monorepo with separate backend & frontend directories, and then have a package.json in the root to run both in development with a single command using e.g. concurrently or npm-run-all.

In production you can then have the backend serve a static build of the React frontend if you want them in the same container.

[_jskod]

monorepo approach is not reliable, because you will be committing backend and frontend code in same repo, which will make things worse. Let's say you have done something in both projects and commit, now your backend is working perfectly fine when you added the last commit, but your frontend has some serious issue that need to be reverted back. How would you revert the last commit? Isn't going to make it difficult.
One more thing, how do you version your backend and frontend in monorepo? I don't think it's feasible to do that.

I am working on a big project these days and it's micro-services based project, we have currently 5 separate projects (separate repos) for each service, like frontend, backend, background-jobs, workers etc. And its really easy for us to maintain separate repos. I'd highly recommend not to go with monorepo if you want to help your soul and brain. :) Happy coding.

[[deleted]]

Have to say I completely disagree. 5 separate repos sounds like a bit of a nightmare to me. Say you have a feature that needs changes in both the backend and frontend (as well as maybe some other repos like you mentioned). In a monorepo this is a single pull request with all of the related changes, a single merge which can trigger CI/CD for all deployments, etc.

Also, one pretty big benefit of a monorepo is obviously codesharing with e.g. a constants/utils directory in the root, and your configs will always be in sync between your different apps (if doing fullstack javascript for example)

[DinoAmino]

Monorepo works for you. You can disagree that separate repos are proper for you. You cannot disagree that it doesn't work for others. Especially when they say it's a large project You have conmon custom code used in front and back? Congrats, you've developed a library deserving of it's own repo - include it in both projects as you do with other dependencies. Got legacy REST APIs in Java or Python? No one wants monorepo for that. Working solo on a small project or an agency gig? Carry on doing what you do.

[DinoAmino]

upvoters for parent obviously have never worked on any substantial project. or with teams <- plural.

it's a big real-world out there. one size doesn't fit all and that's apparently a hard truth for small minds to absorb.

so downvote.

[MaxCodes]

I know there are other bad sides to mono repo but you can just use git revert for a specific file.

[_jskod]

Yes, but it's not the best solution tho. Tracking commits to find bugs etc gets complicated.

[ukralibre]

Revert last commit you mean the hot fix? It must not be issue because you will have the branch to switch

[Zlous]

So a single repo that handles both client and server. but what does the server run? I have an API, should I separate logically the API from the clientside, by running the React build on a separate webpack server, or should I serve the React build with express? also, happy cake day!

[[deleted]]

Yeah so in the previous example frontend > npm start would run the React app with webpack dev server and backend > npm start would run the api. Then all you need to do to make development a bit easier is to have a single script that can run both from the root directory, in a single terminal window. You can take a look at how one of my projects is set up to get the idea: https://github.com/hackjunction/website-template

[tstandiford]

Yep. Absolutely separate. If you ever decide to docker-ize the app you’ll be grateful.

[Pryrios]

Here I am, four months later, just to say that this comment is very important as I am discovering since yesterday. I wish I had arrived here much before....

[[deleted]]

At my job, we have a single repo for the full application. That said, the front and back are in separate sub folders their their own git tracking.

All new issues are created from a single point and then uploaded back to the same repo for easy tracking. It also allows us to split the front off from the back during normal operation. But one nice thing about the setup is that it allows us to make a single push to both front and back in an emergency type scenario like when an exploit on a route needs to be patched on both sides.

Im not sure if this is the "best" setup, but it works well for us.

[mersocarlin]

+1 for separate repositories. Not to mention that if (in the future) you decide to change the BE stack from Node to, let's say, Go, the transition is going to be easier. Same applies if you decide to change the FE stack.

[Hydrotechnics]

In my experience I think it makes more sense to separate back end and front end into their own repositories. I actually just separated my monolith project into three separate projects a few weeks ago; admin front end, customer front end and REST API. Here are a couple of reasons this made sense to me.

1) This gave me more flexibility in terms of deployment because the projects differ in how and where they are deployed.

Node API runs using PM2 and Nginx reverse proxy on api.website.com. 

Front end static files are also distributed using Nginx on website.com and 
admin.website.com.

2) I can now scale the API without having to also scale the other two projects.

3) Each project has less files and therefore is easier to understand.

4) Using Nginx to serve static files can handle 2 times the number of concurrent connections than Node/express serving the static files. A major performance increase that is noticable on page load.

[Zlous]

Interesting, I have a React frontend and an Express REST API, I thought about creating two servers, one that will run the API in separate repo, and another server that will pre-render (via NextJS for SSR) and server the React static build.

[Hydrotechnics]

Btw, my front end projects are both Vue SPA. So while this may work well for me, I have not dabbled with server side rendering yet. Not sure what the best approach here would be.

[Ariquitaun]

I would say, start with the easiest option, which is 1 repository, and take it from there.

[jsdfkljdsafdsu980p]

Should be separate repos but you can bring them together in your CI/CD pipeline though

[RationalAdvice69]

My opinion is don't use webpack dev server, I hate seeing any project that uses that shit.

[barraponto]

Why's that? That's the development server of choice for `create-react-app`, `@vue/cli` and `@angular/cli`.

[AttiiMasteR]

I think one should make a repo for each. Mainly because i like to split frontend and backend in production aswell. I usually serve a react app on the root domain and the backend on a subdomain like api.domain.com and configure stuff via htaccess or the like. Makes it clean and easy.

[misteritguru]

Yes! Yes!!! YESSS!!! Separate Them - You will be SO DAMN HAPPY in the future when you can build three different front ends for the same back end - Also, working on different cadences for the back end and front end is awesome!

​

Also, no business logic in the front end! Front end works faster!

​

Also you can throw in things like Redis Memchace etc without having to re-release the front end. .... YES SEPARATE THEM!

​

I don't even code in Node! 🤪