Alright, so I had my socket.io server listening on a different port, but in order to get it to work with https, I needed to have it listen without passing in a port (default). (It works fine on a different port loaded with http, but I need it to work on https)
My project was working fine, client could connect and send data fine. However, I moved the site over to my main domain, which has an SSL certificate. The site loads everything via https, so it couldn't load the http version of socket.io.js
However, now that I switched it to just var client = require("socket.io").listen().sockets; instead of listening on a different/specific port , it's still not working. Instead of giving me a connection error, it's not including the file at all.
My fear is that I'd end up needing to remake my whole site to host my files via node.js and I'd rather not have to do that.
I'm not using any other module than mysql-node and socket.io, and I'd prefer to keep it that way if possible. I am new to node.js, so I'm sorry if there's an obvious answer that I'm unaware of.
I looked around, however, and can't seem to find the answer anywhere. Or, at least a clear answer.
Would I be better off using websockets instead of socket.io?
If so, how would I go about doing this? I'd be more willing to remake my node application instead of remaking my site, honestly.
I am including the socket.io.js file in the client-side like so:
<script src="https://mysite/socket-io/socket.io.js"></script>
but of course, 404 since it's not an actual file that's on my apache server. There's no folder/directory named socket-io in my public_html directory, so that makes sense to me.
But, how can I get this to work? Would I need to host my files via node.js or would I be better off using HTML5 websockets? A fairly large demographic of my site's users use mobile devices, so I'd have to be sure it works on mobile as well.
If you're going to use apache to host the socket.io.js file, then you need to put that file on your Apache server at a path that it can be served from by Apache, just like any other web file that you want the Apache server to serve. Or, you can just serve socket.io.js from a public CDN also and use the public CDN URL. It's just a JS file. You can put it anywhere or use any URL that reaches a place where the file will be served from. There are some advantages to letting node.js and socket.io serve it for you because it guarantees that client and server socket.io versions are always in sync, but you don't have to do it that way.
If you are using node.js (which it sounds like you are at least in some capacity), then the socket.io built into node.js will serve the file automatically if you are using node.js to serve your web page too and you've configured socket.io to listen on the same port as your node.js web server. In that case, your webpage and socket.io will use the same port and both will run through the node.js server.
You haven't really explained why you're using both node.js and Apache, how that architecture works and why you're serving some of your site with Apache rather than just using node.js for the whole site as that is certainly the cleaner option with socket.io.
You can use plain webSockets if you want instead of socket.io, but then you will likely have to build some of the socket.io functionality on top of the webSockets (auto-reconnect, message passing, etc...) and using plain webSockets won't really simplify any of the Apache/node.js questions you have. It's trivial to serve up the socket.io.js file to the client using either Apache or node.js and once the client has the file, it is actually more work to use plain webSockets than to use socket.io because of the extra features that socket.io has already built.
Related
I'm making a new website with HTML, CSS, js for frontend and Java for backend (I don't know Java, my friend will do the java part) and I need to use frontend technologies (languages/frameworks) to use localhost
I am unable to find frontend technologies for this purpose. I have already tried python -m SimpleHTTPServer and node.js but as these are backend I can't use them. Also, I can't change my backend language
The important thing here is that you need to understand the terms backend and frontend.
A website is by definition something that can be loaded from a server with HTTP and it made of HTML and maybe CSS and/or Javscript.
Now by definition every code that runs on that server is the backend. All code that runs in the Browser of the user is considered the frontend. If the website only contains HTML and CSS that is generated by the server it does not make much sense to do this seperation. This means we only talk about frontend and backend if we have both.
This also means that the frontend code, that runs in the browser, must be delivered by the backend. A frontend without a backend can not exist.
Lets look on a little example. If a user enters example.com in the browser the browser will make a HTTP GET request to example.com. The server (and so the backend) will respond with a HTML file. This file now could embed a javascript file with <script src="/code.js">. Now the browser does another HTTP GET to example.com/code.js and the server (and so the backend) returns that file. In that file may be some frontend code that is executed in the browser.
Now maybe this file wants to load some data from the backend. So it does a fetch('/api/data). The browser does anotherHTTP GETtoexample.com/api/data` and the backend has to respond. Now while the backend was relativly dumb up to this point and only delivered files it now could actually execute some logic. Maybe load the data from a database or such. It then sends the data to the frontend which then can use that data to do something.
This means in production your backend has to deliver the frontend code. In this example the initial HTML file and the code.js file.
So what you want is by definition impossible. A frontend runs in the browser and so can not deliver code on localhost. If it could it would become a backend.
Now while its common that the real backend delivers the frontend code on production its not common for development. Its very common to have a seperate minimalistic server that is only used for development. python -m SimpleHTTPServer is such a tool and so would do the job.
Sometimes this is also done in production. Then your backend is for example on example2.com and your frontend is delivered by example.com. But this essential means that there runs a second backend just to deliver the frontend. Usually for production this is a full fledged web server like nginx, apache or IIS (you'll need CORS, see below). In contrast to them tools like python -m SimpleHTTPServer should not be used for production.
Now this means basically you can just use any kind of backend to deliver your frontend for development. Later you will give your code to your backend developer and he will then deploy it with his backend. However there is one open question:
How will your frontend and backend communicate?
In production your frontend can just fetch something and it will work if your backend delivers your frontend. But for development (and so testing) you probably already want to use the backend without actually starting it on your computer. For this basically there are two ways.
First your development backend could proxy unknown requests to the backend. This means if your real backend runs on example.com and you start a development server on localhost that server will proxy all requests that are not an existing file to example.com. So if you request localhost/code.js and the file code.js does exist your server will respond with that file. If you request localhost/data and you have no file named data your server should do a request to example.com/data and return that response. This is very common. Depending on the tools, libraries and framework you use for frontend development they have a integrated development server with that capability. For example if you develop with ember.js you can do ember server --proxy=http://example.com. And it will run a server on localhost:4200 with exactly that behavior. Other tools like create-react-app allow the same.
Second you can use CORS. This must be implemented by the backend and allows a frontend from another server to access the backend. This is also needed if you run your frontend and your backend from two different servers as I described before.
If the backend implemented CORS correctly you can just do fetch('example.com/data) to get your data, and this Javascript must not be delivered by example.com and it will just work. However CORS complicates security.
I have configured my Vert.x server built in Java to already handle HTTP connections properly, but I would like to add an additional layer of security through HTTPS. I use the standard fetch call to make POST requests to the server. I have searched through the Vert.x documentation already, but the only information I can find is if I use Vert.x as client code as well, but I would like to avoid that if possible. Is there a way to configure my client and server to work together to form a secure connection without having to build an encryption schema from scratch?
If I understood you correctly, you have but one VertX instance, without load balancer, and you would like to access it using HTTPS protocol.
It doesn't actually matter whether you access it through
When starting your VertX server, make sure you specify setSSL(true) and all the other arguments:
https://github.com/vert-x/vertx-examples/blob/master/src/raw/java/https/ServerExample.java#L39
we built a node.js application for desktop and tablet. It's completely web based application. Now I am planning to implement same application as native app in android using Apache cordova.
Under project directory, we have node_modules,public,.... all client side files are in public folder. When I invoke URL in browser, from client side I am making API call to check whether user already logged or not. like this we are making API calls to my server.
As per my understanding,native app is nothing but we are storing all the client side files into device. whenever user open app will load client side files and as per work flow it will make API calls.
Theoretically I understand that much.
where I stuck :
In desktop app , I used to make API calls with URL like /api/web/shared/reject/, here we don't need to mention server address like localhost:8080/api/web/shared/reject/ that everything browser will take care. This same thing how can I make it work in cordova applications.
How cordova will know whether it is localhost or something else...
Regarding this, I Goggled but I didn't find any tutorials.
can anyone suggest me the way.
Basically, is a concept problem.
Node.js is a technology specialised in backend and some of usages like extend some services/functions, etc.
When you talk of a localhost:8080 you are talking that your node.js implementation should be in a server (Amazon, Azure, your own server, nodejitsu, etc), and the public pages or the pages that the client should consume will be added into phonegap, specifically in your www directory and the references for localhost:8080 should be changed for your server (Amazon, your own server, nodejitsu, etc), and the files on your www directory could have references (via GET or POST to retrieve the data from the server. Remember, the Crossdomain problem doesn't happens on phonegap (maybe in a local enviroment should occur).
And Phonegap is a framework to develop front-end with HTML5, jquery, CSS3 and other releated technologies.
For your specific case the node_modules should be installed in the server too, not on the phonegap project.
I'm running a game which contains a server.js backend (which is hosted and run on my localhost), and the frontend is on a github website. The github page connects to the server on my localhost through the config which points to 127.0.0.1. I realize that I will be able to play this from my localhost this way, but will other people be able to?
Basically the index.html connects to the visitor's localhost to look for the running server.
A visual representation (sort of):
[nullwalker.github.io/index.html] ----> [localhost(127.0.0.1)/server.js]
What should I do to allow myself to play from the computer that's hosting the server backend as well as others being able to play?
You would need to host it in a live environment. There are ways via port forwarding to use your computers ip (gateway) to allow others to connect, however typically ISP's will try to stop you from using your dynamic IP statically. Safest bet is to launch a cheap VPS and host it there.
http://www.howtogeek.com/66214/how-to-forward-ports-on-your-router/
This article seems to explain port forwarding well enough.
As for the VPS, you can find extremely cheap ones really easily, if you do not expect a lot of players it should be fine, if you expect more then using your own connection is dangerous.
unless they have the same server running on their localhost, no. And they almost surely don't. You should get a host (digitalocean.com is very popular and good, but there are many others), and then run it there and connect to that instead of localhost
I was thinking of building a web app which would be single page, using only javascript to update the page (no reloads). So I'm confused about what kind of setup to use.
I'm kinda new to both technologies, so I was wondering if you can set up nginx to serve html (+ js, css and other static resources) like a normal web server and then from those pages connect to a node.js websocket server (same host/ip) using something like socket.io?
Is this setup good or bad? What would be a better approach? What advantage would I get if I serve html pages in node.js and get static resources (css, js, images, ...) from nginx?
I dont think serving few images and static htmls from nodejs itself will ever be a bottleneck , ideally a front end proxy like nginx is required if you need to load balance between multiple servers and also for exposing you internal http services as https traffic. If you dont have that requirement it would be a overkill imho.
From various comments in the currently accepted answer, I wanted to note the following.
NodeJS itself does a pretty decent job of delivering static content, as good as nginx in many cases.
Trying to proxy a WebSocket connection is problematic at best currently, as most proxy code simply doesn't support it. Currently, it is best to use Node directly.
If/When you have a need to deliver static content separately, best to use another domain and a CDN at that point.