You've just finished a node.js site. It's a folder with some files and a my_main_file.js which handles the requests. The thing works on your machine by running node my_main_file.js. How do you deliver this solution to a client, though? Are you supposed to say 'take this folder, install node.js, run that command line and your site will be online'?
The answer is yes. This is quite a bit less complicated than delivering a servable site on other platforms. There are nodejs installation binaries for just about every platform and then it's as simple as:
$ node site/my_main_file
Or maybe there's one more step to install dependencies. Either way, it's about as simple as it gets.
Related
For my understanding, node.js is a javascript-engine which is running javascript-code without using a browser(window-global). You can use javascript on a server. But I saw now a lot of tutorials(react, angular, vue etc.). In every tutorial, I have to install something with npm. I can follow there are several dev-tools which I can use on my local machine to minimize my javscript-files or compile sass to css. But in the end, when I put my files on a webserver, I just have normal javascript-files, css-files etc. No node.js code in it, right?
My question is: React, angular, vue.js etc. are written in just normal javascript without node.js right? The reason why I use npm ist just to install every dependencies with one command, right?
A question more: Is there an any recommended order to learn all these frontend-development stuff? There are so much words I have to google it: angular.js, react, vue.js, vanilla.js, typescript, backbone.js, bower, grunt, webpack, yarn etc... I dont know where I start, so I look into few tutorials, but everytime I go through these tutorials, there is a new word(technology) I have to research.
I think you're getting your terminology a little muddled.
Node.js is a JavaScript runtime, built on Google Chrome’s V8 JavaScript engine. However, that is not to say that Node programs are executed in a browser. They aren’t. Rather, the creator of Node (Ryan Dahl) took the V8 engine and enhanced it with various features (such as a file system API and an HTTP library) to create a program we can use to execute JavaScript on our computers.
Node comes bundled with a package manager called npm which you can use to install packages (such as React and Angular) from the npm registry. These packages are indeed written in normal JavaScript (or a language that compiles to JavaScript, such as TypeScript).
The reason why I use npm is just to install every dependencies with one command, right?
Kinda. You can certainly use npm to install dependencies. However, it does a lot more that that. For example you can use npm scripts to carry out various build tasks, or you can create a package yourself and use npm to publish it to the registry.
A question more: Is there an any recommended order to learn all these frontend-development stuff?
As with everything, it depends. What are you trying to build? It's relatively pointless to learn about Node, npm, React and Angular if you are attempting to build a simple static website. If I were you, I'd define a clear goal and set about learning the technologies you'll need to reach that goal. Saying that, if you are doing anything with front-end development, learning about npm will be a good use of your time.
Here's an article by way of further reading that explains things a little more: https://www.sitepoint.com/an-introduction-to-node-js/
I'm looking for the proper way to distribute/deploy a node.js app that would run as a small webserver on the user's machine.
Is there a stub method or install script or a "install wizard" that would download all node_modules dependencies, download the latest nodejs binary, set up the environment, etc... or I have to distribute it bulk with everything packed? Is there any guide for that purpose?
Edited :
You could install node and npm, download your dependencies by running npm install in the command line (first declare them within your package.json) only then users can run your script. This is how you do development in Node.js, or deploy to a development server. See using npm. You could automate that with a shell script if that is what you are after.
However, when distributing programs to end-users that might not be the best approach. Linux users are used to a package (.deb for instance) and Windows users are used to an .exe or a setup wizard.
That is why I recommended the tools below. I also assumed you were targeting Windows as this is less of a problem is unix-like environments.
If you want a single file (.exe), pkg and nexe are made for that purpose. These Node.js tools are used by the developer to compile JavaScript code into a single executable binary that is convenient for end-users and Windows deployment. The resulting .exe file is very light and does not require node to be installed on the end-user’s computers.
Electron along with electron-packager can produce setup wizards, but it installs a lot of files even for the smallest program. Your program will include all of node and webkit, that is why it produces heavy installs.
NSIS can also create a setup wizard, it is simple and does common stuff well (copying files, running shell scripts).
Original answer:
Short answer is: not really.
You have to keep in mind that Javascript is and has always been interpreted, so until recently never compiled to binary as you might do with other languages. Some exploration has been going on, but essentially you won’t get a "good practice" answer.
The long answer is, maybe, for some limited use cases:
There is the fresh new pkg that does exactly this, and it looks promising.
There has been nexe for a while, it works great for some use cases (maybe yours). Native/compiled modules are still an issue however.
Electron might work for a full blown app with a significant user interface, but it is not light or compact.
You could always use browserify to concatenate and uglify all your code with the modules you use and then make an installer with something like NSIS to setup node and your script. Native modules would still be a problem however.
I'm currently moving on with reading about node. I'm getting through the tutorials well using the command line. However I am thinking ahead and I want to create a simple register, log in and log out website.
Where would I place the node files on a server (all examples I see run from local host:3000)?
What is the best tutorial for creating this type of website from scratch with node?
Thanks in advance!
It doesn't really matter where you put the files on the server. The localhost:3000 bit comes from the fact that your core server file tells the server to listen on that port.
I would recommend using the express-generator from npm. It's pretty versatile and does a lot of the leg work.
Just run the following:
npm install express-generator
After installing, you'll need to just run the following to create a new web app:
express
The details are here: http://expressjs.com/starter/generator.html.
Also, try to read through and understand all of the pre-provided code.
I'm working on including Ember into an already deployed Node/Express/EJS application. I don't want to disrupt any of the existing application behavior, but instead, want build out any additional feature to the app using Ember. The server side code for these new features has already been built, and each endpoint returns the JSON format that Ember Data expects. I've been looking into Ember App Kit and Ember-cli, but I'm not sure how to include these tools into my existing directory structure, and I'm not certain if these are in face the right tools for my use case. Does anyone have any experience with this particular use case?
For example, navigating to /foo returns the existing express route that renders an ejs template, but /bar would be an Ember route that hits the api endpoint of the same name.
Use ember-cli (ember-cli.org). It's perfect for this situation as it allows you to rapidly prototype out your ember app. It even comes with an expressJS based testing suite and mocks server.
Once you are ready to incorporate it to your NodeJS, Flask, or whatever other application all static files should be available in the ember-cli dist directory.
Just don't forget to build the ember-cli project before porting via the means of ember build. After that it's just a simple matter of moving the files in the ember projects dist folder into wherever you need in your environment.
Just to embellish a bit: Ember-cli has a great work-flow for use while building your ember app. Try ember serve for a quick example. I mention this because it speaks to your question of how to incorporate this into your existing project (by project, I assume you may mean workflow). I typically will build ember projects purely using ember-cli and consider the back-end (usually a REST-API exposed via either Flask or NodeJS) a separate concern. When importing the app all I have to concern myself with is making sure my server serves the correct static dist files.
I would not recommend using the Ember App Kit (EAK) as it has been deprecated in favor of ember-cli. It really is.. much, much better.
Ok so I'm going to try to be more complete in this answer. Let's start with the isolated question - ember-cli or eak? Definitely Ember-Cli, but why?
EAK is officially heading for deprecation in favor of ember-cli.
Ember-cli produces more structured, cleaner, maintainable ember code.
Ember-cli integrates your entire ember-app workflow.
Managing all types of dependencies and assets is made simple via bower install --save and Brocfile.js edits. (See the ember-cli docus for explanation)
Now the more complicated part of the question. How do I integrate this with an existing workflow? I recently ran into this when building a webrtc-included ember app. It just so happened that this was my first real use of ember as well. So, not yet realizing the full potential of my new hammer I wrote the REST API, Backend ORM layer, the signalling service, the session cache, and built a complete CI workflow first. Then I was ready to build my ember app and ended up in your exact position.
To short circuit a long story - the lesson I learned was that I should treat my ember-cli app like a completely separate concern. What I mean here is - there's my backend (NodeJS, Apache, Nginx... whatever) and what I code here is built, tested and integrated separately. It normally even lives in its own git repository. It's a separate concern to my front end equation which typically would consist of several components itself. My I-Phone Native app would have its own workflow from build-to-test and integrate to my backend via a REST API. My Android native app another. My web app another. For all intents and purposes, in my workflow these are entirely separate workflows that only tie together when we start talking Continuous Integration.
There's a lot of arguments for why you'd want to do this. Most importantly - it scales.
The beauty of ember-cli is that it makes it fairly trivial to get a workflow for your ember app going and trivial to redeploy your app + workflow on a new box/instance. I would certainly recommend referring to the official ember-cli setup instructions but I'm going to include them here in case the URL goes bad one day:
No really, refer to the link my instructions will suck in comparison...
Deploying a new Ember App
Install NodeJS, NPM and Git (ember-cli will as a default load git going for you on new apps) on your system via sudo apt-get install nodejs and sudo apt-get install npm, sudo apt-get install git.
Note: On Ubuntu 14.04 and some other Debian systems use sudo apt-get install nodejs-legacy instead. If in doubt, use legacy. If you experience problems using the node command after install, it's definitely that you need to use nodejs-legacy. Don't bother trying to do the linking manually.
Install required node modules globally: sudo npm install -g ember-cli, sudo npm install -g bower, sudo npm install -g phantomjs
Create new ember-cli app: cd <Desired Directory>, ember new my-app-name
Now you can look at ember help to begin learning how to use ember-cli. Hint: The --dry-run flag is your friend. You'll notice that when you installed ember-cli all the scaffolding was taken care of for you. You'll see that you can add things with simple ember generate commands and they will not only create the required objects, but the test files as well. Best of all, using ember serve you can start scaffolding your app and via simple flags you can configure the test server to actually proxy and use your already-existing REST API (if you have one) or the expressJS mocks server to build a psuedo-API.
Integrating it with your larger workflow from here is a simple matter of configuring whatever tools you use (I use Jenkins and Ansible for this kind of stuff) to distribute the dist folder of ember-cli to where it should go to be served as static content (it is just a single page webapp in the end).
If you want to instead play with an existing ember-cli app that operates in an isolated workflow and already makes use of most of the goodies in order to get some familiarity - as I suspect you'll quickly realize how to fit this into whatever your current structure is - feel free to clone and play with this one here.
And so finally - to answer the more specific question of how this might fit into an existing directory structure, I would break this down into two categories. When we're talking src - I would have it in it's own "structure", separated at least by being in a separate sub-directory of its own. When we're talking built and deliverable I would include the contents of the /dist folder in whatever static web server directory you want to serve your ember app from.
EDIT: I Added some more detail - hopefully useful details below the line break. Let me know if you have more questions or if I can explain anything better.
I am facing a similar situation. I am planning to use EAK as a "prototyping tool" in a separate project folder. Then build the distribution directory from EAK using grunt dist and insert that into the assets folder of my main Node.js project.
this might be a bit of a silly question but it's something that i've been struggling to find the answer to and for some reason it doesn't seem to be evident from the tutorials and websites i have been reading, so maybe it's something that is assumed that i'm really missing.
So anyway, i installed node.js and then used the command npm install socket.io. it them proceeds to download and install a bunch of files, i don't see any error with this process in the command line.
So now i've tried to access socket.io like this:
<script src="/socket.io/socket.io.js"></script>
Like it shows on the socket.io website, however i get an error saying the file isn't found..... my first guess is that the installation of node.js and stocket.io are both on the local machine (program files) and not in the htdocs.
I have tested this one two platforms, first was my localhost which is Windows 7 running XAMPP on it, and i installed node.js and stocket.io globally (Program files). Second was my Windows server that uses IIS still get the error.
So my question is, how do i reference the stocket.io API and start using it based on the installations i have?
Thanks for your time.
npm isntall socket.io installs Socket.IO in a local node_modules folder so that the library is accessible to you in your own Node.js applications. You still need to create (and run) a Node.js application that loads up the module and sets up an HTTP server that uses the module; the examples under How to use in the project readme is a good starting point, although preexisting knowledge of Node.js will be helpful. You might check out Node.js Tutorial with Socket.IO if you're looking for additional information.