I am trying to deploy a react based app in jetty. As part of that, I thought of trying to do the same in jetty server.
I followed a link:
https://www.megadix.it/blog/create-react-app-servlet/
The above link explains details about it and at the end there is a github project for making a war. the link to that is below:
https://github.com/megadix/create-react-app-servlet
Now, I am able to deploy the war created using the above github project in tomcat 9. I am unable to understand how the dependency resolution of node_modules is happening. Also I am unable to deploy the same war in jetty(putting the war in webapps folder and starting jetty)
Thanks
Single page applications needs to be compiled into one (in same cases more) .js file. In your case, create-react-app or similar tools are responsible for fulfilling this requirement.
In the pom.xml execution list, you can see npm install, npm build commands. They are pretty much similar as mvn clean install and mvn buuild.
Dependencies are resolved from package.json dependencies field and installed under node_modules. Once dependencies are there, npm build (or create-react-app-servlet build), compiles all the source code + dependencies into a js file. This probably has a name like main.XXXXXX.js.
In the end, you have a dist folder consisting of .html, .js and other resources.
It'd be better if you share more details of what's happening with jetty deployment
I am a beginner to mean.
I have followed the following steps to create meanjs app :
installed node v0.12.7
npm install -g bower
npm install -g grunt-cli
npm install -g yo
npm install -g generator-meanjs
cd C:\Users\SHIVAM\Desktop\MyApp
yo meanjs
MyApp folder containing mean directory created
Error occured on yo meanjs 1
Please provide a solution . I am struck at the first phase. I need to get started as sson as possible .
Version 0.4.* has different folder structure. The tutorial you are following is probably using earlier version of meanjs. You can find the new structure here-http://www.bossable.com/954/version-0-4-0/ She has compared the structure with the older one. I was going through the same problem. Follow these tutorials, it will be of great help.
The following directories have been changed in the 0.4.* versions of Meanjs; 0.4.2 is still unstable. 0.4.0 and 0.4.1 is recommended for beginners to get on MEAN.
-New files have been added
1) gulpfile.js-Gulp is relatively faster than grunt because gulp focuses on code rather than cofiguration. It uses node.js’ streams, and executes faster, since it does not open/close files, or create intermediary copies all the time. The lack of any up-front configuration, especially, specifying a source and destination is noticed immediately in this file.
2) protractor.conf.js-Support file for end-to-end testing in angularjs applications. (Pretty Neat.)
The app folder is removed, which is the major concern for the noobs trying their hands on MEANjs following the older tutorials. Controllers,views, models are now moved into a separate folder called modules which was previously in the public folder.
You can explore modules/core/server and modules/user/server of your project
Addition of client, server and test in modules/core and modules/user folder. All the client side angular will now be in the modules/core/client making it easier to access all services and directives of different modules of the application at one place. And all the backend or server-side files goes to modules/core/server.
public/application.js and public/config.js are now config.js and init.js in modules/core/client/app folder.
config folder is split and new folders assets and lib are added.
The previous env folder have been split into env and assets. All the references, mongodb port, session keys goes to the environment(env) whereas new libraries we are defining into our project goes to assets. For instance new css, sass or less reference will be defined into asset/default.js. config.js and init.js are merged into one file config/config.js.
lib contains express.js, mongoose.js and socket.io.js.
node_modules is pretty much exactly the same as the previous versions of meanjs.
These are the major changes in the folder structure. New models and controllers are added into the modules/users/server according to your application, just so you don't get lost while developing your project.
I have the Meteor app setup with such folder structure. I am not able to get the sass or scss file to create the appropriate css on its own and serve it to the client.
What should I do to make sass work as I prefer sass over scss.
Meteor supports less and stylus out of box my issuing meteor add less or meteor add stylus in your project root directory.
there is also a third party package repository (to be rolled into meteor core in the near future) on which you can find alternatives to many requirements.
For example, there is a third party scss package you can add to your project with meteorite add scss.
Now, the meteorite command here belongs to an npm package that interfaces your app to the atmosphere package repository as well as provide some deeper packaging structure to your app.
When you add the scss package, like in a typical meteor application your coffeescript, handlebars,jade,less,scss,javascript etc files will be compiled/bundled at deploy time and at each save afterwards and be placed in a hidden directory. So you will not be seeing your compiled css alongside your scss files, but the css will have been sent to the browser.
I am new to Node.js programming and I have recently created a sample working web application using (express, backbone & other complimentary view technologies, with mongoDB). Now i am at a point where I want to deploy the same on a staging environment and I am not sure how to package this application and distribute the same. [I can take care of mongoDb and setting it up seperately]
I am from Java world and in there we create jars for reusable libs and war/ear packages for web applications which is deployed in a servlet container. Now in this case since node.js itself acts as a web container as well, how do i package my webapp?
Is there any standard format/guidelines of packaging node webapps built using express? (Is there a similar jar/war packaging systems for node apps?)
How do I deploy it once packaged? Would it become an exe, since it is also its own container?
PS: As of now I am thinking of just manually copying all the required source files into the staging environment and run npm commands to download all dependencies on that machine and then use 'forever' or some other mechanism to run my server.js. (Also, add some sort of monitoring, just in case app crashes and forever fails) I am not sure if that is the right way? I am sure there must be some standardized way of addressing this problem.
Deploying Node.js applications is very easy stuff. In maven, there is pom.xml. Related concept in Node.js is package.json. You can state your dependencies on package.json. You can also do environmental setup on package.json. For example, in dev environment you can say that
I want to run unit tests.
but in production;
I want to skip unit tests.
You have local repositories for maven under .m2 folder. In Node.js, there is node_modules folder under your Node.js project. You can see module folders with its name.
Let's come to the grunt part of this answer. Grunt is a task manager for your frontend assets, html, javascript, css. For example, before deployment you can minify html, css, javascript even images. You can also put grunt task run functions in package.json.
If you want to look at a sample application, you can find an example blog application here. Check folder structure and package.json for reference.
For deployment, I suggest you heroku deployment for startup applciations. You can find howto here. This is simple git based deployment.
On project running part, simply set your environment NODE_ENV=development and node app.js. Here app.js is in your project.
Here is relative concept for java and nodejs;
maven clean install => npm install
.m2 folder => node_modules(Under project folder)
mvn test => npm test(test section on package.json)
junit, powermock, ... => mocha, node-unit, ...
Spring MVC => Express.JS
pom.xml => package.json
import package => require('module_name')
There is no standardized way, but you're on the right track. If your package.json is up to date and well kept, you can just copy/zip/clone your app directory to the production system, excluding the node_modules.
On your production system, run
npm install to install your dependencies, npm test if you have tests and finally NODE_ENV=production node server.js
Some recent slides I considered to be quite helpful that also include the topic of wrappers like forever, can be found here.
Hope this might be helpful for somebody looking for the solution,Packaging of Node js apps can be done using "npm pack" command.It creates a zip file of your application which can be run in production/staging environment.
Is there any standard format/guidelines of packaging node webapps
built using express? (Is there a similar jar/war packaging systems for
node apps?)
Yes, the CommonJS Packages specification:
This specification describes the CommonJS package format for
distributing CommonJS programs and libraries. A CommonJS package is a
cohesive wrapping of a collection of modules, code and other assets
into a single form. It provides the basis for convenient delivery,
installation and management of CommonJS components.
For your next question:
2. How do I deploy it once packaged? Would it become an exe, since it is also its own container?
I second Hüseyin's suggestion to deploy on Heroku for production. For development and staging I use Node-Appliance with VirtualBox and Amazon EC2, respectively:
This program takes a Debian machine built by build-debian-cloud or
Debian-VirtualBox-Appliance and turns it into a Node.js "appliance",
capable of running a Node application deployed via git.
Your webapp will not become an exe.
few ways to approach this:
Push your code into Git repository, excluding everything that isn't your code (node_modules/**), then pull it in your staging environment, run npm install to restore all dependencies
create an NPM package out of it , install it via npm in your staging environment (this should also take care of all of the dependencies)
manual copy/ssh files to your staging environment (this can be automated with Grunt), than restore your dependencies via npm
I used zeit's pkg module. It can create cross platform deliverables for linux/win/macos. Actually used it in production and works fine without any issues.
It takes in all the js scripts and packages it into a single file.
The reason I used it is because it helps in securing your source code. That way in production at customers environment they will have access to application but not the source code.
Also one of the advantages is that at production environment, you do not actually need to have the customer install node.js as the node binaries also get packaged inside the build.
https://www.npmjs.com/package/pkg
I'm working on my node.js demo.location.io web app at the same time as my location.io library. I'd like to be able to make changes to the location.io library and push them up to github from inside the node_modules folder. Is there any support for this in npm?
(If I understand your question) You can use
npm link
to link your location.io to your local demo.location.io repo. More info here