web-dev-qa-db-fra.com

Comment organiser la structure de fichiers de backend et frontend dans MERN

J'ai backend basé sur express + mangouste. La structure du fichier est:

- /models
-- item.js
- /node.modules
-- ...
- server.js
- package-lock.json
- package.json

Et un dossier standard basé sur create-react-app pour front-end:

- /src
-- /assets
--- index.css
-- /components
--- Somecomponent.js
-- /containers
--- App.js
-- /reducers
--- somereducers.js
- /node.modules
-- ...
-- index.js
-- registerServiceWorker.js
- .gitignore
- package-lock.json
- package.json

Je veux l'utiliser de manière appropriée ensemble. Je voulais l'organiser de cette façon:

- /client 
-- /src
...
-- index.js
-- registerServiceWorker.js
- .gitignore
- package-lock.json
- package.json

- /server
- /models
-- item.js
- /node.modules
-- ...
- server.js
- package-lock.json
- package.json

A ce stade je me suis coincé. Je peux le faire si le dossier du client est dans le dossier du serveur ou si le dossier du serveur est dans le client. 1. Mais comment le faire fonctionner quand deux dossiers sont frères? 2. Que devraient être package.json et où node.modules devrait être (si le serveur et le client doivent avoir son propre package.json et ses modules?)

17
Angelzzz

La structure la plus élémentaire serait d'avoir un dossier root contenant les dossiers frontend et backend. Puisque vous parlez de la pile [~ # ~] mern [~ # ~], vous auriez une package.json à l'intérieur de votre environnement backend NodeJS et d'un package.json pour votre côté React. Le serveur dorsal et le client frontal sont deux choses totalement distinctes, alors oui, ils ont tous les deux leurs propres dossiers node_modules. Sur le backend, vous aurez probablement installé quelque chose comme Express pour votre Node runtime, Mongoose pour un moyen plus pratique de parler à votre MongoDB, etc., et sur votre interface, vous aurez votre React comme infrastructure frontale, Redux pour la gestion d'état, etc. De plus, selon ce que vous avez déjà répertorié dans vos fichiers package.json, lorsque vous exécutez npm install séparément , il sera installé dans ces deux dossiers. Si vous voulez installer des paquets supplémentaires, lancez simplement npm install + "the name of the package" (sans le '+' ni les guillemets) à l'intérieur de ce dossier particulier où vous en avez besoin (backend ou/et frontend).

J'espère que cela a été utile. Découvrez les photos, en particulier la 2e.

Structure de l'application
enter image description here

Structure du dossier

enter image description here

UPDATE:

En développement, je suggère d'installer deux choses supplémentaires:

  1. npm i nodemon
  2. npm i concurrently

Nodemon va suivre chaque changement de fichier et avec concurrently vous pouvez démarrer à la fois votre front-end et votre back-end. Par exemple, vous pouvez aller à votre package.json fichier dans votre dossier backend et éditez la section de départ, comme ceci:

"scripts": {
    "start": "node app.js",   // whatever is your backend starting point
    "backend": "nodemon app.js",   // to start the node development server
    "frontend": "npm run start --prefix frontend", // it goes insede of the client folder and starts the React server
    "dev": "concurrently \"npm run backend\" \"npm run frontend\""  // with this command you'll be able to start them both at once
  }

Si vous avez conservé la structure des dossiers, installé toutes les dépendances (y compris les deux supplémentaires que j'ai mentionnés ci-dessus), modifié le fichier package.json sur votre backend, vous pourrez les démarrer tous les deux avec une simple commande:

npm run dev

28
Bigga_HD

En ajoutant à la réponse acceptée, la division de la structure des dossiers à l'intérieur du serveur et du serveur est plus utile si elle est basée sur une logique métier plutôt que sur une logique technique.

Diviser l'ensemble de la pile en composants autonomes qui, de préférence, ne partagent pas de fichiers entre eux constitue le meilleur moyen de rendre votre application plus facile à tester et à mettre à jour. C’est ce qu’on appelle communément l’architecture microservice.

Mauvaise conception: difficile à mettre à jour et à tester:
Bad Design for folder structure

Bonne conception: facile à mettre à jour et à tester:

Good Design for folder structure

7
Saurabh Ariyan