I'm attempting to scale a Node.js application but am a little confused on one piece of it. I moved all my static files to the gateway server running NGINX, and it routes them accordingly. Now looking at the waterfall diagram in Chrome's dev tools, I notice a full second of wait time to access the socket.io javascript file. I'm assuming that is because this is still being accessed from the application server, not the web server. My question is, can I move this file to the web server to have it load faster? It's an npm module so it seems a little fishy to me, like it needs some sort of interaction with the application server to initialize the connection or something. Or am I thinking about this all wrong? Thanks!
Related
I've been developing a Next.js website locally and now want to set it up on my Apache server (with cPanel). However, I'm very new to Next.js and Node apps and not too sure how to go about it.
Has anyone done this successfully? Can you list the required steps and what files should be on the server?
Also, can this be done on a subdomain?
Thank you!
To start with some clear terms just so we're on the same page, there are two or three very different things people mean when they say "server":
A Server Machine is a computer that is connected to the internet that you intend to use to serve something to people on the internet.
A Server Program is some software you run on your Server Machine. The job of the Server Program is to actually calculate the responses to various requests.
A Server as a Service is a webapp provided by a company that stores your code and then puts it onto Server Machines with the right Server Program as needed.
While we're here, let's also define:
A Programming Language is the language your website is written in. Some sites have no language (and are just raw HTML/CSS files that are meant to be returned directly to the user). Many sites, though, have some code that should be run on the server and then the result of that code should be returned to the user.
In your case, you have a Machine whose condition we don't know other than that it is running the Program Apache (or probably "Apache HTTP Server"). Apache HTTP server is very old and proven and pretty good at serving raw files back to users. It can also run some Programming Languages like PHP and return the result.
However, Next.JS is built on top of the Programming Language Javascript, which Apache does not have the ability to run. Next.JS instead wants its Server Program to be Node.
So the problem here is basically that you have a hammer, but only screws. You can't use the tool you have, Apache, to solve the problem you need solved, running Node code and returning the result. To get around this you have two options:
First, you can find a way to access the Server Machine that is currently running Apache and tell it, instead, to run Node pointed at your Next.JS code whenever it starts up. This might not be possible, depending on who owns this machine and how they've set it up.
Second, and probably easier, is to abandon this Machine and instead use a Server as a Service. Heroku, AWS, and Netlify all support Next.JS and have a free tier. The easiest solution, though, is probably to just deploy it on Vercel, which is a Server as a Service run by the same team that makes Next.JS and which has a very generous free tier for you to get started with.
The good news, though, is that yes next.js does totally support being hosted from a subdomain.
Next.JS allows you to build fully functional Node Applications, as well as simple statically-generated sites like Jeckyl or Docpad. If your use case is a simple statically generated site look here: https://nextjs.org/docs/advanced-features/static-html-export
In particular the next build && next export command will create all the HTML and assets necessary to host a site directly via an HTTP server like Apache or Ngnix. Contents will be outputed to an out directory that could serve as the server root.
Pay very close attention to what features are not supported via this approach.
I'm working on a system where a remote machine (hooked up to a projector and some other hardware) is controlled via a Meteor application. Currently, we are using a home-grown DDP client written in C++ to accomplish this, but this approach is not as flexible as I would like:
There is duplication between C++ and JavaScript.
Upgrades are hard because we can't deploy both the server and the client at the same time, so we always have to think about backwards compatibility and ordering.
So I'm toying with the idea of rewriting the Meteor part of the C++ app in JavaScript. What I would like, ideally, is to have a special client of our app (call it headless, akin to to server and client) which:
is built from the same source as the rest of the Meteor app, so we can reuse the same business logic as on the server and web client,
runs in Node.js on the client machine so it can access the OS, and
doesn't contain any of the browser code, but adds some other code specific to controlling the machine and communicating with the C++ app.
Even better would be if this client would not contain any of the actual code, but just a piece of bootstrap code. The bootstrapper would download the actual application code from the server and re-download it when the server is updated, in the same way as happens for the HTML client. That would make updates much easier, because we can assume that server and client are always running the same version.
Does such a thing exist? If not, how close can I get without unreasonable effort? Searches for "meteor headless client" and "meteor node client" are not helping me, and the only somewhat related question I could find isn't well answered.
You should be able to get this to work by using the meteor-desktop package to build your remote headless client.
https://www.npmjs.com/package/meteor-desktop#architecture
In Electron app, there are two processes running along in your app.
The so-called main process and renderer process. Main process is just
a JS code executed in node, and the renderer is a Chromium process. In
this integration your Meteor app is being run in the renderer process
and your desktop specific code runs in the main process. They are
communicating through IPC events. Basically, the desktop side
publishes its API as an IPC event listeners. In your Meteor code,
calling it is as simple as Desktop.send('module', 'event');.
This will give you:
os access on this (desktop) client
hot code push (with caveats around the node modules)
provides Meteor.isDesktop to control which code runs on the browser vs the desktop client
If you wish to use the Meteor client as a headless client, and since client runs in the browser, I'd suggest your look at using a headless browser like PhantomJS, which can run your Meteor code without the UI, and has the ability to access the local file system.
Another option, which is not really what you describe but would make everything javascript, is to use the node ddp client, and write your code in modules you can easily import on the node side.
Is there a regular meteor client on the remote machine with custom hardware? Or is that the C++ program acting as a client? And then a server, in addition to your other client browser?
Sounds like you should actually do a few things differently:
Set up a dynamic DNS system with a custom domain and port forwarding so you can use the special hardware remote system as a server.
Run the Meteor server on that remote machine with hardware.
Instead of a full C++ app speaking DDP, just make a Node.js C++ addon that talks to the hardware and use that in the Meteor server code.
I use Nginx to serve my php applications for dev purposes.
On Ubuntu it works out of the box.
I want to do the same for Node.js apps.
Is this possible without doing nodejs app.js before?
How to achieve this in a single Nginx conf file?
PHP and node.js are oil and water. PHP requires a web server to run the .php files, however node.js typically creates its own web server. Since you are creating your own web server, in many cases you wouldn't find it necessary to serve your application from Nginx, however, if you truly insisted on "serving" it from Nginx, you would need to proxy it.
This is not possible without doing nodejs app.js before, due to the way node.js works.
This question best answers your question regarding proxy'ing via Nginx.
As a closing remark, its good to remember that node.js does in fact (in most cases) implement its own web server, and PHP does not.
So I thought about giving node.js a try seeing the possibilities it has for a little test chat project (with mysql) I'm doing.
But what I couldn't find out is where to run the file from and whats most common.
What I currently have:
A FreeBSD server with latest Node and PHP 5.3.x
A vhost
some tutorials on how to start with node (which I looked through and got exited about)
knowledge on how to run it from terminal without having to keep my terminal open (screen)
So far so good.
What I need:
Some basic information of where to put the (lets say:) chat.js file.
Most logical port to run it on
So the web root (www) runs on a user (not root obviously). And the webroot has an underlying folder where I could put the script (away from visitors grabby little hands). This seems to me to be the most safe place to put it seeing nobody can get to it, which is probably what I want seeing I'm going to connect to a db and don't want my DB login data out there (I don't know how this works yet but I'll figure out db connect with node later, no answer required).
But if a file is not in the webroot, it seems to me a connection cannot be made from outside. Cause my webroot is configured to only allow 80 (or ssl on 443) incomming traffic, which is logical. Outgoing obviously has no problems.
All the examples that I found don't really help me. They just do everything on a local machine, which sucks for me cause I don't want to do that.
So what I would like to is the best practice for:
Where to put the file
port to run it on.
What is Node.js?
A lot of the confusion for newcomers to Node is misunderstanding exactly what it is. The description on nodejs.org definitely doesn't help.
An important thing to realize is that Node is not a webserver. By itself it doesn't do anything. It doesn't work like Apache. There is no config file where you point it to you HTML files. If you want it to be a HTTP server, you have to write an HTTP server (with the help of its built-in libraries). Node.js is just another way to execute code on your computer. It is simply a JavaScript runtime.
A nice tutorial How to Deploy Node JS Applications, With Examples
You'll need to have your non-node application on port 9000 (for
Apache, this will be in /etc/apache2/ports.conf and in your
sites-available file for your site), and you'll need your node
application to listen on 8080. You'll also need to set up DNS 'A'
records for the different hostnames you'll be using for your servers.
Companies like Heroku allow for automated deployment of apps from the desktop to the cloud.
Nodejitsu provides a tool called jitsu that makes deploying an Node.js application super simple. You can install jitsu with npm.
npm install jitsu -g
Heroku How To
Getting started with jitsu
Use monit, forever, upstart or systemd to start your node server. Use Varnish or HAProxy or Nginx (Nginx not work with websockets).
Ultimately you can stick it anywhere you want. I recommend running your application using Forever or similar instead of directly with Node. I usually keep my apps in /var/ and let each one run under a unique user. I do not recommend keeping them in your http root, as your .js files are should NOT be interpreted by Apache, php, etc.
To be clear - you do NOT need a traditional webserver, nor do you need php,mySQL or anything else. Node is all you need. It'll serve content directly - it IS the webserver.
Often times you'll have each app use a high port number (3000+) and use NGINX to proxy them all to different hostnames off of port 80 (allowing you to easily have multiple apps on a single machine). If you aren't using some sort of proxy, then 3000 is very default, but there is no correct or incorrect port, so long as you don't use a reserved port.
We have a whiteboard application powered by NodeJS sitting on a 'cloud' server (rackspace cloud). I recently scaled our server up to accommodate for the anticipated traffic with our launch, and in the process it shut down NodeJS. We are launching our product in a few hours, and our NodeJS developer has gone for the day.
The whiteboard application is supposed to run at http://rayku.com:8001 (the port is opened). However, it's not working because the port isn't listening to anything with NodeJS shut down.
I honestly have no idea which js file to run in order to start NodeJS for the whiteboard. There are many js files in a 'whiteboard' folder. Do you know what type of code I should look for that might suggest it is the right one? Or, do you know what types of logs I can dig up that might point me in the right direction?
Much appreciated
Look for app.js, server.js or something similar. It isn't required but a lot of people use app.js from what I have seen.
node or nodejs is typically the command to start. You may need to set environmental variables or arguments depending on how the developer set things up.
Also make sure to run it with screen or forever so it doesn't quit when you log out.
For common code. createServer is probably what is used to open the server itself. That is consistent between the core libraries and a lot of the frameworks. There might be another file that loads the module prior to executing so running might not work.