I have developed a node.js application and it is working fine locally.
Now, after that I deployed the application in Heroku I am getting some HTTP 404 errors in the browser console.
My understanding is that the reason for this issue is caused by the node package.json modules. In fact, the outer package.json is installed successfully but the node modules mentioned in the client folder is not installed.
Q: Any idea about what is necessary to modify (or to do) to make the client node modules as installed?
The image below depicts my folder structure.
Each time you push your code to Heroku, Heroku will look for the package.json file in the ROOT of your project. Heroku will then install those dependencies.
In your case, because you have multiple package.json files, Heroku isn't seeing the ones nested in sub-folders of your project.
The best option you have is to list all dependencies in your top-level package.json file. You could also create your own Heroku Buildpack to customize the Heroku deployment procedure, but I strongly recommend AGAINST doing this (it will be a nightmare to maintain over time).
Another option in your case (which might be good depending on how large your team is) would be to move your client-side code into it's own Git project, and have that deployed separately to a static hosting provider like Amazon S3, or something similar. This would then let you deploy your backend project directly to Heroku, while not having to worry about any front-end logic at all.
Related
Two questions, all related to bundling. First server, then client.
Typically, I wrote my Express server code, using an app.js file to setup my express server, setup logging, routes, etc. I also ran tests against the functions associated with the routes.
When deploying my server code to AWS, I would push the code and a git hook would build the project by doing an npm install, run my task runner to bundle client files and to copy files to their dist directories.
For my client side code, I used to use browserfy, then moved to webpack to bundle all my client code to a single bundle or main.js.
I'm looking at using rollup now and appreciate its' ability for tree shaking.
As I'm now setting up a new project, I have a few questions/concerns:
Should I also bundle on the node/server-side? Is it more efficient for the server to run against an optimized, tree shaken, server bundle? Or once node interprets my unbundled app.js, it's pulled into memory along with all the require files and would run similar to the same bundled/tree shaken version.
I currently deploy code to an aws server via a git push. That push triggers a full build server side, moves client files to dist directories and starts the nginx and node servers. Should I instead run the build process locally and only push dist files to the server? Thinking about a CI/CD process, I'm thinking no... but it could happen... But is it worth it? Depends a lot on answer 1, and maybe some hybrid approach.
Maybe someone could outline their production deploy steps at a high level? I can also talk more on mine if interested.
I am following Ben Awad's wonderful tutorial to build a fullstack
app using Next.js, Express, Typescript, and GraphQL. Everything works smoothly locally, but I have run into a barrage of issues trying to deploy to Heroku. I would really like to deploy both server and client to Heroku as one app, and have Express serve the frontend files as well as be the backend.
monorepo
- web
- package.json
- server
- package.json
package.json
To my understanding, this is possible using Next's custom server option, which I have integrated in my server.js file. My problem is when deploying to Heroku, it doesn't detect React as a dependency for the backend so while the deploy succeeds, the app crashes when I try to access it in the browser. I have tried a few things to resolve this issue - having two copies of React in frontend and backend, respectively, only leads to more problems (understandably so). I have tried keeping one copy and using npm link to point to the module, but it only works locally. I've tried changing the webpack config as well but it doesn't seem to register. I tried defining the custom server as a util in the frontend and import it in server.js, but the import is always undefined, which makes sense so I moved it back.
I'm still new and have many misconceptions about how Next.js works, especially when coupled with a custom server, so I might be doing something fundamentally wrong. Is there anything I'm missing, or is it better to split the app into two Heroku apps and push one subtree into each?
The source code can be found here, but I will be probably rolling back because it has become very messy.
I know there are other ways to do this I just don't want to give up quite yet.
I'm running a NodeJS app on Openshift using Jenkins for building deployments (and I'm pretty new to both Node and cloud-based servers). My app depends on a package that has a binary component, so I can't just check it into git - it fails when it's executed on the server. I'm wondering what's the best way to deploy these sorts of dependencies. I see that there is an $OPENSHIFT_DEPENDENCIES_DIR (as well as $OPENSHIFT_BUILD_DEPENDENCIES_DIR), but I can't find any information about how (or if) these can be utilized for node modules. It would be great if I could keep all my dependencies on the server and out of my source tree.
Thanks!
Update: I forgot to mention that I need to apply a patch to the package in question, which is why I can't just rely on it being auto-installed via package.json. Plus, it seems awfully redundant/slow to rebuild all your dependencies on every deployment.
I'm also new to nodejs. I've been playing with nodeJs for about 6 months from now. As for my personal experience nodejitsu is the best cloud-hosting service for nodejs. As I said so due to the following reasons.
You can simply install jitsu command line in your terminal
Your app can be deployed with all the dependencies and databases using the package.json file
They support all the types of sockets either
A very good alternative for jitsu is heroku But sometimes heroku fails with Socket.IO and stuff.
I have a project that consists of several nod.js backend applications. The apps are using the same modules (which a placed outside of each ap folder in shared location). The aps they are to be deployed on differnt environments (servers), some code is for test, some for debug as usual.
If I choosed a platform (for example PaaS nodejitsu) for one of my apps, how I'm supposed to send there only production code for one of my apps? I deployed on nodejitsu and it just sends the app folder and uses package.json to configure the app. But there are a bunch of code that is not need (tests) for example and some code is external. And what If I want to obstruct server code too? How this issues are supposed to be soleved?
For front-end applications has a tons of methods to be build for production. I understand that the requirements are different, but didn't find any infromation on best practices fo how correctly to prepare node.js back end application for deploy.
Read section "Keeping files out of your package" in the NPM Developer page. It states following
Use a .npmignorefile to keep stuff out of your package. If there's no .npmignore file, but there is a .gitignore file, then npm will ignore the stuff matched by the .gitignore file. If you want to include something that is excluded by your .gitignore file, you can create an empty .npmignore file to override it.
Add those test files in .gitignore
or make another branch for production in git and push the production branch.
I have a Node.js Express app that I'm hosting on Nodejitsu. I'm already using env switches in Express for dev and prod, but obviously I'm going to need to push to different dev and prod servers.
For Nodejitsu, pushing to these servers requires a simple jitsu deploy, which looks to my package.json for app and domain/subdomain information.
I'm trying to think of the best way to handle the various pushes to dev and prod (and/r perhaps testing, staging, etc. in the future) given the package.json restriction. Clearly I would like to avoid maintaining several git repos, each with its own slightly different package.json.
What kind of workflow would be ideal for handling this?
We are't using Jitsu, but what we do is keep a couple of different version of the confs around in a confs folder. When we go to deploy our scripts copy the appropriate conf/package.json file in to the root dir.
You may be interested in this: https://github.com/nodejitsu/jitsu/issues/134
As Małecki points out in that issue, this can be done with npm scripts. You can have a few script setup in the package.json file(s) that do the appropriate pre-deploy work.