I really like the folder structure as can be seen here when dealing with a React frontend and a some backend with express:
root
├── backend
| ├── node_modules
| ├── public
| ├── src
│ │ └── Server.ts
| ├── package.json
| └── tsconfig.json
├── frontend (created using create-react-app)
| ├── node_modules
| ├── public
| ├── src
│ │ └── Index.js
| ├── package.json
| └── tsconfig.json
I think that having separate packages with individual node_modules
is reasonable since the frontend and backend are basically completely different things, e. g. they need different node modules. Also, this modular approach is visually appealing to me and the repository looks tidy.
However, I encounter a problem with this structure when I need to share content between the frontend and the backend. I added a shared
folder under the root-of-project which contains its own project with its own tsconfig.json
, package.json
and so on. This approach is a mix of the approaches here and here. For the backend, this works totally fine: having set up the tsconfig.json
appropriately (using TypeScript Project References and aliased imports), I can reference the file root/shared/src/myFile.ts
like this:
import { myFunction } from @shared/myFile;
I created the React frontend using create-react-app
. It's ok for me that alias imports don't work, so I would have to use (inside the src folder in frontend):
import { myFunction } from '../../shared/src/myFile';
Sadly, these imports from outside the src
directory are not supported by create-react-app
and I don't want to use eject
since I have no experience with webpack and don't want to maintain all the configuration files on my own (that's why I used create-react-app
in the first place).
I know I can move the shared content to the frontend's src
directory. But this would mean, I had to add the tags needed for using Project References in TypeScript, e. g. setting composite
to true, in the frontend's tsconfig.json
which seems odd to me and feels more like a hack. I'd like to have a separate npm project with my shared content.
Since create-react-app
does not inherently support imports from outside the src
directory, I thought that maybe I'm getting the big picture wrong. Isn't the folder structure I use right now a valid way of how to setup a React project with a backend? What mechanism does create-react-app
provide to link files between the frontend and the backend? I could also think of having a root project with a src
folder and inside of that the two folders backend
and frontend
. But this means, that we'd have one shared node_modules
folder in root.
It's my first project with React and I'd love to get to know some best practicese for this kind of architectural problem. Some links to trustful resources where project structures for full-stack React development are explained would be really helpful. Thank you
Architecture is a tricky one, everyone has a different opinion and every option has pro and cons.
Personally I believe its best to separate the backend and frontend into sperate projects and keep them that way. Now as JavaScript/React/Node encourage component-based approaches a really nice way of sharing code between them is Bit.dev.
https://bit.dev
I am currently using it to share components and functions between three web apps and a few Node microservices.
A good structure for React app can be found here, this one works well and scales nicely:
https://hackernoon.com/fractal-a-react-app-structure-for-infinite-scale-4dab943092af
As for Express, there are so many ways to structure the project but personally recommend a folder for your Routes, a folder for your Controllers, this is where the logic for Routes live. Then go from there. Check this link out:
https://www.freecodecamp.org/news/how-to-write-a-production-ready-node-and-express-app-f214f0b17d8c/
Depending on what your building you may not even need a full backend you can check out the JAMStack here for more info:
https://jamstack.org
I would consider separating them though as the project scales it makes it much easier to manage. You can release your front end on something like Netlify and then use something like AWS or Azure to host your Node/Express server.
I think it's perfectly reasonable to want to share code between your front and back end. It's one of the reasons we code in javascript instead of Ruby or PHP.
You can accomplish exactly what you want by using yarn instead of npm and yarn workspaces: https://yarnpkg.com/lang/en/docs/workspaces/. At the top level you set up three modules/packages in your package.json (make sure you name the workspaces correctly in their respective package.json files):
Once you do, you can import shared code in your CRA app or your back end simply like this:
The only drawback is that you can't import react components from the shared directory into frontend as long as you are using CRA. This won't affect you now since you only have one react app. Should you need to share react components among multiple projects, look into some on the suggestions above like bit.dev.
This is not the only way, but it's among the simplest and most straight forward.
Having separate sub-projects for frontend and backend makes perfect sense due to vastly different dependencies. Mixing it up increases disk space consumption in production deployments and goes against security guidelines. Your folder structure is reasonable (except for
public/
subfolders I'm unsure about, maybe I'm missing something).The approach
import { myFunction } from @shared/myFile;
is fine. Just don't use CRA.For a project with a single frontend and a single backend there is no need for a
shared\
top-level folder because the frontend is the only source of 'UI truth' (e.g. the source of types and components related to UI) that is consumed by the frontend and the backend is the only source of 'API truth' consumed by both frontend and backend. With this arrangement only@backend/api_shared_stuff
needs to be shared.Some links to trustful resources where project structures for full-stack React development are explained would be really helpful. On the one hand, usually project authors have to explain plenty of other things and on the other hand keep the documentation (typically a README) reasonably concise. You may find that providing a justification/explanation why the subdirectory structure is this and not that was not the top priority.