When I'm generating app from locally installed JHipster 4.7, I can start it on localhost:8080 by running ./mvnw with no problems.
But when I generate the project online at https://start.jhipster.tech, running ./mvnw shows the blank page on localhost:8080 (no errors on the browser's console). To see the page, I have to run yarn start and use localhost:9000 (this is optional if I generate the project locally).
Did anyone experience this?
Yes in dev mode the JHipster development documentation is still valid with JHipster Online, which might not be obvious. So indeed you'll need to run ./mvnw for the backend and yarn start for the front-end
In prod mode, running ./mvnw -Pprod will run automatically yarn so you might not see it (as it's automatic), but in the end it's basically the same thing.
In the future that might change, to make things easier: the build could be done in the cloud (or in a local Docker container), so you won't see those at all.
Related
I'm completely new to web programming and have a very basic Angular.js app in JetBrains Webstorm IDE.
In Webstorm I can right-click on index.html file and choose Run/Debug and it will launch the app in Chrome with the debugger attached (I have chrome LiveEdit Jetbrains extension). This created a generic JavaScript Debug configuration. This is nice because it launches a chrome browser running my app automatically.
However, I was also able to run the app using npm start via JetBrains npm template. while I haven't explored it further, can probably also run the app using a Node.js template.
My question is that what is the difference between these launch methods?
How would I choose one rather than the other?*
It's nice that, for example, running index.html directly opens a chrome tab automatically. But what is the difference in doing this way over another? For local development, which one is better?
The application development landscape has been changing continuously
over the past few years, both on the client side (frontend) as well as
on the server side (backend). On the client side, we have plenty of
awesome new and updated JavaScript [and other scripting] frameworks;
and on the server side, we have new architectural approaches such as
single page applications(SPA), microservices, and serverless architectures.
The index.html is the main root file in your front-end & index.js is the main starting point of your backend. When you install Node on machine there is an npm which is node package manager which can install the project libraries and packages using 'npm install' based on the information on the package.json file. If you look into this file there is script part such as this:
"scripts": {
"start": "node ./index.js",
},
The project command starting with npm such as npm run start or npm run build ... can be found and define here.
When you start with your backed it initiated your project and load required templates. When you using IDE such as Webstorm, Visual Studio, or ... they build and run your entire project. So, by initiating and serving the index.html just you can see a part of front-end application and this running that you can see is what 'IDE's provide for you. For better understanding this process you can open project in a simple text editor such as Sublime text editor to understand the differences. So there are actually no difference in your context.
This was an general explanation that I hope could help but there are many other rooms to discuss.
I'm trying to start a NextJS application on my Node server using Plesk but it is not working. I activated NodeJS for my Plesk environment, and I was able to run npm install and npm build, but now, when I try to start the application, Plesk only shows "Please wait" and stays like that with no change, I have been waiting for more than 2 hours now, but I don't get any results, no errors, nothing.
The only issue I can think of is that, according to what I could find, the Application startup file and the package.json file should be in the same directory, the root folder, but in my case this is not possible. I have my package.json in the root directory, but the startup file for NextJS, index.js, is inside the pages folder. I tested building and starting the app locally and everything works fine, I don't understand why it's not working with Plesk.
I was able to fix this after correcting the startup file, it should be "node_modules/.bin/next" and not "pages/index.js".
Also when you start your app, Plesk will tell you to wait. Just check the site and make sure it is running, if it is, you can close Plesk.
You might need to install Express in your Next.js
You may refer to this repo fmi # https://github.com/zeit/next.js/tree/canary/examples/custom-server-express
If you're referring to the package.json's command we'll have:
dev
build
start
In Plesk's Node Application extension.
Website & Domains > "Your Domain" > Enable Node.js
Simply set server.js as my Application Startup File.
Ensure that all dependencies is installed using "Npm Install" helper.
You must run build command before start command.
Screenshot:
Helpful NPM/Plesk reference:
Running scripts in Node.js Application
Adding .npmrc file in Node.js Application Root folder
Bit of a n00b question:
I created project with vue-cli using webpack.
On my windows machine I run "npm un dev" and I get a frontend server with HMR and so on.
Now I want to deploy my app to a production machine - ubuntu on DigitalOcean.
What are the steps I must take? I'm not very familiar with the logic of how it's supposed to work. If my ubuntu machine has NODE_ENV set to production, it won't install any of the devDependancies and i'm not able to build anything. So I guess I'll have to change that? If yes then it doesn't make any sense since it's a production machine.
And do I have to create another node/express server to serve index.html? Won't it supposed to work out-of-the-box somehow?
Thanks :)
TL;DR Build on your local machine and everything you need will be outputted in the ./dist/ directory, just copy the contents over to the webroot on your production server and you're good to go.
The webpack template handles most of the stuff for you.
Step you need to take to release:
Run npm run build on your local machine
Copy the contents of the generated ./dist/ directory to your server webroot
That's it!
When you run npm run build, the pre-configured build script sets the node environment to production, and builds with only the stuff that should be in production, it also optimizes the code and removes debug capabilities. When it comes to dependencies webpack takes care of that and includes them in the generated javascript files located in the ./dist/js/, so you need not concern yourself with copying over the node_modules/ directory either.
It also copies over everything in your static directory and src/assets directory to the ./dist/ directory to be prepare for a release. And resolves all the references to the new path generated by webpack.
The production server should not be concerned with building the vue app, run the build command on your local machine to keep dev dependencies away from your production server. I recommend against installing webpack and other dev tools on your production server. It just pollutes the server with things not needed there.
Some development tools could potentially produce alot of issues on production servers. So best practice is to never install them.
You could optionally create your own release script that uses ftp or rsync, whatver you prefer to copy everything in the ./dist/ directory to the production server webroot. This could be a script in bash, if on windows, run it in git bash or something similar for example.
Hope that cleared things up, congrats on your first vue release!
I'm trying to use cute-files on my openshift account
https://www.npmjs.com/package/cute-files
I know node.js works as I did in localhost:3000 but not as expert,
I'm ended up with http://cutefiles-powerupware.rhcloud.com/ that's not I'm looking it. It should be Cute-files app as start.
I did PuTTY to access terminal to do npm-install but no luck due to permission.
The problem is... I cannot understand how openshift works, I need to know how to access console to do npm-install then, execute "$ cute-files", alternativley I've used Git to commit and push, the files are updated...I got no results... I've spent like 6 or 7 hours, Openshift has been very complicated me to use, can anyone explain how to install and execute simple node.js app in openshift?
It's not like you can access Openshift and run any command. Openshift isn't a simple hosting or vps service, it's a PaaS. That means they offer you an environment to run certain services in particular as you demand.
When you create an app it's bound to a git repository which when pushed will be deployed to openshift.
About your application being deployed and runned, it's NOT about node.js running in port 3000. Openshift has some default application file names and port to expect.
So, working in a local clone of such repository you might perform the npm install command, that will download the node_modules folder to be there.
How to do all this?
First you should install rhc in your system.
Manage to clone any of you applications via rhc.
Make changes, and do git.
Those changes may include doing npm install getting your dependencies.
When doing git push, expect the changes to be deployed.
You really should read this guide.
Having gone through and used demeteorizer. I wonder what are the main differences between setting up meteor vs demeteorizer and running it via node; on own server?
meteor only
hot swappable code?
problem in maintaining packages similar from production and dev
same meteor versions running on prod and dev
hardcoded environment settings (i.e. mongo)
demeteorizer
platform independant as this auto bundles dependancies and uses pure nodejs
organise and maintain mongodb how you like (backup scripts etc)
I have been using demeteorizer (packaging->upload->running forever), but wonder if there are any performance or issues in the long run.
I have seen packages such as "authentication" running okay locally but very slow on the test server (hangs on submit, indicating sync problems?)
thanks in advance.
ref: https://twitter.com/SachaGreif/status/424908644590030848
Demeteorizer builds on top of meteor bundle with one small difference: Demeteorizer builds a package.json for you and deletes the node_modules directories.
Without demeteorizer you would have a bit of trouble deploying your app, particularly if it was on a different platform to the one you built your app on.
If you see meteor's own docs, you have to remove fibers and manage your npm modules yourself, manually. With a package.json you can run npm install and have them all installed for you, including ones from packages.
Why is this useful? For services like modulus it means you can upload an app and have it install all your dependencies for you without you having to think about it, as if it were an ordinary node-js app.
Everything that applies to meteor bundle will also apply to demeteorizer as it is still the same meteor bundled app, just with the package.json. So you can use forever, hard coded/environment based settings, etc the same way.