The documentation for Network.WebSockets.runServer says:
Note that this is merely provided for quick-and-dirty standalone applications, for real applications, you should use a real server.
Is this "real server" a reference to something that I'm supposed to know about (if I were more familiar with the Haskell ecosystem), or something that doesn't exist yet?
The actual server can be any TCP application. All you need is support of Berkeley socket from your programming language. This is a nice tutorial from Mozilla on how to write a websocket server.
The real production quality server in Haskell ecosystem is warp. You can use wai-websockets to target it to Warp. In fact wai-websockets uses the package websockets internally.
Related
I have a very basic question. When I write REST services, there is a server on which your service runs. When I write my service in Java using dropwizard framework, it uses Jetty server to expose endpoints. But what is actually this server? Because server is just a machine on which we host. For example, in node js application, when we just write a createServer(), it creates the server locally on the machine. Does it also have some fancy names like Jetty or Tomcat that it uses internally? I am little confused, what exactly is meant by Jetty, Tomcat, etc? Are these some library which makes it easy to connect to the machine OS and all or its something else.
My question looks very dumb but I wanted to understand the concept of servers.
This is a little bit confusing, you're right, as server can mean the machine itself, or the software that actually creates the web server.
But software needs some hardware to run, isn't it ?
Server usually means the combination of both.
Node.js servers have also some fancy names like Express, or Sails, and many others that make setting up your app easier.
This is more about the context of the discussion than frameworks and languages.
After a couple hours of searching top lists of free "web servers" and "web frameworks" on google, I realized I'm not sure what I'm looking at.
Let's take a couple of example softwares I have come across :
IIS
Apache HTTP server
Apache Tomcat
Socket.io
Node.js
Django
Questions :
Do all these work on the same scope/do the same thing?
If not, what is absolutely necessary to have my "helloworld.html" acessible from anywhere with internet? Let's consider I already have a dedicated server and a domain
Also if not, how do these work together/compliment eachother?
Each of this software has a different description on their website for what it does, what it is, who should use it, it really gets confusing when you're trying to find what is "fresh", what the cool kids are using
IIS and Apache are web servers that support a variety of different technologies for plugging code into the web servers. So, if you were using one of these web servers, you would also use some other framework and language runtime to plug into them.
Apache Tomcat is a Java-based server framework for web applications. From the wikipedia page: "Apache Tomcat, often referred to as Tomcat, is an open-source Java Servlet Container developed by the Apache Software Foundation (ASF). Tomcat implements several Java EE specifications including Java Servlet, JavaServer Pages (JSP), Java EL, and WebSocket, and provides a "pure Java" HTTP web server environment in which Java code can run." It may be used independently of the Apache Web Server. The "Apache" in the name has to do with it being part of the Apache open-source organization. So, if you want to program your server in Java, this is one of your options.
node.js is a Javascript-based framework that is both a framework and it's own web server. So, if you want to program your web server in Javascript, this is your main option. There are additional frameworks you might use with node.js such as Express to make programming your web server simpler.
Django is a python-based framework. If you want to program your web server in Python, this is one of your choices.
socket.io is really not like any of the others. socket.io is a layer on top of webSockets that gives you a whole bunch of additional features over webSockets. This would run in whatever server-side language and framework you were already using and you would have to select a socket.io library that was compatible with your server technology. You can see a list of features that socket.io adds on top of a webSocket here: Moving from socket.io to raw websockets?. webSockets themselves are used for continuous communication between server and client (more efficient than repeated Ajax calls) and for push notification from server to client.
So, if you were looking to select a technology from scratch, there are a number of different ways you could start your selection process.
If you have a preferred language (Java, Python, Javascript, Ruby, C#, etc...) you either know already or want to learn, then you can look at the frameworks that support your language and start there. The framework will indicate whether you need a companion web server or whether than is already part of the framework.
If you have an existing hosting company that you want to use, you may need to understand which technologies they support so you don't select something that would require you to change hosting companies. Not all hosting companies support all technologies and some are better specialists in some technologies.
If you have specific 3rd party code or libraries you want to use, you may want to investigate which languages/frameworks it can more easily be used with.
What is fresh and what the cool kids are using changes pretty regularly. I would suggest that's a crummy criteria. What makes more sense is to understand which technologies and frameworks are doing well with accelerating growth and a rich development community behind them vs. which ones may be falling out of favor. I haven't myself done any sort of overall survey to offer any sort of list of what's on the upswing and doing well vs. what is more stagnant.
I'm personally partial to node.js and the huge NPM library of open-source and compatible code you can draw from and the ability to use one language for both front-end and back-end. It is certainly one of the choices that is growing rapidly and has a vibrant development community behind it. But, it is not the only choice that would meet those qualifications.
I want major difference between ZeroMQ and socket.io
Performance. ( Is it faster? Scalable? )
Applications. ( Is it used for real time services? )
Browsers Support. ( Which browsers are supported? )
Although there are some situations where the two might be used interchangeably, you're comparing apples and oranges.
Socket.io
is a javascript library, composed of two parts- a client-side part meant to run in any browser that supports Web sockets, and a server-side part which runs on NodeJS. It's used to build real-time web applications, meaning you're expecting a lot of back and fourth communication between the client and server (and possibly multiple clients- eg. chat).
ZeroMQ
is a networking library, used to build distributed applications. It's meant to run on the backend. The idea is to enable communication between any combination of different threads or processes, be it on a single machine or a distributed network (which means it uses different transport means for different purposes- and it does so seamlessly). There are usage examples plenty of popular programming languages (PHP, Python, C++, C#, CL, Delphi, Erlang, F#, Felix, Haskell, Java, Objective-C, Ruby, Ada, Basic, Clojure, Go, Haxe, Node.js, ooc, Perl, and Scala), so it is not tied to NodeJS, or any server framework for that matter.
You should read the first couple of pages of the respective docs:
socket.io
ZeroMQ guide
In short:
ZeroMQ doesn't run inside a browser, and isn't necessarily tied to NodeJS or JavaScript- it facilitates communication between different "programs". Socket.io is written in JS, is a browser script and an npm package used when you want real time communication between NodeJS server and the client.
What is difference between rpc frameworks like thrift or gSoap and build-in MS RPC if we talk about security configurations. MSDN describes on http://msdn.microsoft.com/en-us/library/windows/desktop/aa379441(v=vs.85).aspx some aspects, so I can presume that there is support from Microsoft in rpc. Does this mean that if i would like to use different frameworks than MS, I need to take care of security by myself?
This is a very broad question. I'm not quite sure what you really expect, but I'll try to do my best to answer your question.
First, of course you have to take care of the security of whatever you are writing, be it server or client code. Security with regard to RPC services is a wide field, and any sophisticated security feature made available to you by a framework is still just a tool, and still only one part of the overall security concept of your service. To put it in another way: Using SSL will not protect your server from SQL-Injection.
Next, Thift , SOAP and MS-RPC each have different design goals. Thrift is designed with performance and portability in mind. Thrift is more focused on the basic RPC to provide efficiency and portability to any application, for any purpose, in the simplest possible way that works. Of course this approach implies, that there are not much higher-level features, because this is considered being out of the scope of Thrift and left to the user. However, for some of the languages TLS (SSL) transports are available.
In contrast, SOAP is a much richer protocol, based on XML as an machine-readable, standardized and extendable format which can be extended to support higher level features like WS-Security, WS-ReliableMessaging and so on. The downside is, that I have seen many frameworks and development tools which - despite the fact that SOAP has been standardized years ago - are still not able to deal with SOAP in the simpest fashion correctly, let alone supporting WS-Security. Yet, even in spite of this and even in spite of the fact, that SOAP messages tend to produce a lot of traffic and give bad performance, SOAP is still widely used in the industry.
MS-RPC as one of the foundations of DCOM is bound very much to the Windows environment and to Windows development tools. If you can live with that limitation and want to use DCOM, then DCOM offers a very high-level abstraction with good and proven support in today's IDEs.
In every blog, on every site, on every forum, all you hear about Node is how people use it for web development, similar to Ruby on Rails. And at the same time you always hear the slogan "for easily building fast, scalable network applications". My simple question is, can it be used for other server applications as well? Or rather, should it? There is the TCP server example of course, but is Node good/fast enough for other things than a web server? Like... a server for an online game? This is just a question out of curiosity, since it looks like it shouldn't be too much of a problem.
Node.JS at it's core is a high-performance i/o library/framework. So you can basically build ANY application that relies on fast i/o operations (which of course includes a web-server).
Since it's not a scripting language like PHP, you do not rely on a seperate server application to host your code; it's self-hosted.
So to answer your question: yes, you can build ANY server application using node.js (be it a server for an online game, an e-mail server or even a high-speed feed parser for machine-generated data).