CODEWITHSUNDEEP
javascriptnode.jsherokunpm
George Katsanos
George Katsanos

Reputation: 14175

Deploying a Full Stack Node app npm / package.json architecture

I have a repository which contains a backend (Node/Express) and a Frontend client, as such:

├── build
├── config
├── coverage
│   └── lcov-report
├── dist
│   └── static
├── server (node/express server)
│   ├── coverage
│   ├── docs
|   ├── src
│   ├── etc
│   └── package.json
|
├── src (Vue.js : client code)
│   ├── api
│   ├── assets
│   ├── components
│   ├── router
│   └── store
└── static
└── package.json

I have two package.json files, one for the client and one for the server.

  1. I face issues deploying on services such as Heroku as they don't expect two different npm packages in one repository (I think). How is it possible to deploy to Heroku (or others) with this setup?
  2. Would it be wiser to have 1 package.json file for both parts of the application?

Which would be the advantage and disadvantages of having both frontend and backend parts in the same package.json?

Upvotes: 7

Views: 3698

Answers (3)

Yoni Rabinovitch
Yoni Rabinovitch

Reputation: 5261

You can use heroku-postbuild and maintain separate package.json files for your client and server in a single git repo that you push to Heroku.

For example, in one of my projects, the directory structure looks like this:

|-- package.json (for node/express server)
|-- Procfile
|-- www
    |--client
       |-- package.json (for Ionic/Angular client app)
       |-- ...
    |--server
       |--- ...
    |-- server.js (top level node.js/express script for server)

In my top-level package.json, I have: 

"scripts": {
    "start": "node www/server.js",
    "heroku-postbuild": "cd www/client && npm install && npm run build"
 },

In my client package.json I have:

 "scripts": {
    "build": "ionic-app-scripts build",
    ...
 },

And finally in my Procfile I have:

web: npm start

With this solution, Heroku runs my server and builds my client code on every Heroku build.

I think client and server package.jsons should be kept separate for several reasons. For one thing, you really don't want all your server-side code bundled into your client.

Upvotes: 5

Riordan Pawley
Riordan Pawley

Reputation: 31

I had a similar problem deploying to heroku. I use a package called concurrently to start client side and server side via just the start script in the server side package.json. I also use node's built in proxy feature to send any requests from the client to the server by adding a line to the client package.json.

By the way, I use create-react-app for the client side so thats why some stuff looks a little strange.

My folder structure is

Server folder
   Server package.json
   Client folder
      Client package.json

Server package.json:

"scripts": {
  "start": "concurrently \"npm run server\" \"npm run client\"",
  "server": "cross-env NODE_ENV=production node server.js",
  "server-dev": "nodemon --watch ./ --exec babel-node -- server.js",
  "client": "node start-client.js",
  "dev": "concurrently \"npm run server-dev\" \"npm run client\"",
  "lint": "eslint ."
 },

Client package.json:

"proxy": "http://localhost:3001",

I assume Heroku just looks for a start script and runs that. I think having some degree of separation between your server and client is a good idea so I wouldn't recommend trying to fit it all in one package.json

If you want you could probably find a tutorial online by googling with keywords like: heroku concurrently server client

btw, you don't need CORS if you set up like this

Cheers

Upvotes: 1

Alec Fenichel
Alec Fenichel

Reputation: 1317

I have run into similar issues. I have found that the easiest solution is to have two separate Git repositories, one for the backend and one for the frontend. Then there is only one package.json in the root folder of each repository.

You could then create a third repository and use Git submodules to include the backend and frontend repositories. You would use the "combined" repository to do development work, but you would deploy the individual repositories. This offers the most compatibility with deployment tools while allowing you to still maintain a single repository for easy development.

Upvotes: 0

Related Questions