I have discovered socket.io recently, and it seems to fit perfectly my needs for a multiplayer game. From what I understand, it serves the same role for communications between client and server that jQuery does for client-side querying and animations. Is that roughly correct?
The official website is kind of informative, and I've found a few blog posts, such as this one, boasting how awesome it is. However, I've found no Wikipedia article describing it, no news items, no scholarly research, etc. So, how popular is it?
Somewhat surprising, I have not been able to people complaining about its bad parts, apart from (understandable) bugs like this. For some reason I haven't found comments about how fast it is, how buggy it is, how complete it is, etc.
I would like to know what I'm getting into before diving in and learning the technology!
Note: My opinion is biased because I work on Socket.IO
We have the http://socket.io site and some wiki pages on github (https://github.com/learnboost/socket.io/wiki). It's not allot of information, but enough to get your started.
I think the main reason why there isn't that much information yet is because node and socket.io are relatively young. But it's really populair in the node.js community, when you want realtime communication socket.io is usually the first module that is suggest to you.
According to the stats of npm (node package manager) it's quite populair http://search.npmjs.org/ as it's in the list of most depended on modules. Also if you checkout the stats on the repositories on github you can see that it's quite active and loved. The server has more than 2000+ watchers and 220+ forks. And the client 1300+ watchers and 110+ forks. The google groups has 1350 members already. So that is not to bad for one single node.js module (if i may say so).
As for the bugs, we have launched a complete rewrite of the code a couple of months ago, incorporating the lessons and feedback we had on Socket.IO 0.6, so there a few leaks and bugs but we are working on hard on resolving those. I have already fixed most of the known memory leaks and they should hopefully land in socket.io 0.7.8 / 0.8.
Hopes this helps <3
Related
All:
When I try to build a Reactjs shopping app, I find many posts mentioned one server side tech called GraphQL, so I go to FB website to learn its intro. I am so confused by its definition work of TYPE SCHEMA QUERY etcs, and build a data server seems take a lot of work to redesign how the data been fetched.
So my question is how practical this tech get used in real project and is it worth investing time to learn for my simple project(the main data REST requests are mostly products, users etcs)?
Thanks
GraphQL is relatively new (released as "preview" only a year ago), but the trend towards widespread adoption is very clear. Among the early adopters are many startups, and Twitter among others. As I've written in a blog post, I think you'll be seeing much more of that.
If your project is relatively small and your REST API is simple, there many not be many benefits to using GraphQL, but if you're either building a larger app or working in a team, the benefits of GraphQL far outweigh the extra work you have to put in at the beginning.
I have been given the task to see if it's feasible to convert an Ajax-based application to Websockets. Fundamentally, I'm clear on how to go about doing this. My question, is regarding best practices regarding scaling the codebase.
The application in question has about 80 different Ajax requests. Some of these are clearly user account related, some are related to the operation of the actual application and yet others are of a global nature (statistics, etc) and finally we have a chat service.
I'm wondering if there are any best practices on how to implement something like this. It's entirely possible to do all of this through the same WS channel, but I'm considering an approach where each functional group connects to a different WS channel/topic. I think this might help keep the codebase clean and separate the different functional areas, but on the other hand I have no idea about the performance implications of this.
I've looked around for tutorials on this subject but it seems that all Websocket tutorials are of a rather basic nature and don't focus on the issues of large scale websocket development from a point of keeping the codebase clean vs performance issues.
Thanks for any insights.
I'm working on an Ajax-heavy web app, and we're getting complaints of flaky behavior in situations where the user has an iffy network connection. As a first step in dealing with the issue, we'd like to add a network status widget to the top right corner of the affected pages.
The simplest version would be to have a script ping the server via Ajax every n seconds and show a green light/red light depending on whether or not it succeeded; that should be pretty easy to implement. However, is there an available widget that does something like this, possibly with a more sophisticated or informative approach? My initial Google searches haven't turned up anything, so I'm checking in here to see if anybody knows of any good existing solutions to this problem.
Some links that might help.
Detect that the Internet connection is offline? This question might prove helpful if you decide on creating your own or it might have the answer outright. There are many helpful answers.
How to Detect if Your Server Is Down When Making jQuery Ajax Calls - Might also prove helpful for a homegrown solution.
Check if Internet Connection Exists with Javascript? - More good suggestions for a simple AJAX solution.
Detecting offline status in HTML 5 - might be helpful.
Based on my findings I think your simple AJAX solution described in the question would work best. I didn't see any established widgets out there. Nevertheless, I would still review some of the suggestions/answers in the links as there were many clever solutions for different situations.
I'm interested in:
Performance
Latency
Throughput
Resource usage (CPU, memory, ...)
High availability
No single point of failure
Features
Transport options
Routing options
Stability
Community
Active development
Widely used
Helpful mailing list, forum, IRC channel, ...
Ease of integration with my current codebase
Gotchas maybe
Any other thing you think I omitted
I've read about them, but I couldn't find a good comparison. Specially I'm interested in performance benchmarks comparing them. (Maybe I should do one on my own! I hope not.)
Well, I haven't used the other two, but can share my experiences with ZeroMQ. In my opinion, it excels at all of yours.
Speed and throughput
It's as fast as TCP, doesn't use CPU or a lot a memory. It can push A LOT of messages very quickly without a sweat. It will saturate your network channel way before you run out of memory (I doubt you'll ever be able to max-out the CPU). There was a comparison to RabbitMQ somewhere and ZMQ outperforms it by a factor of 2. From things I've read around the web it's in use in high speed trading.
RabbitMQ is also a very good tool. Have a look at it - it might be good fit for what you are looking
SPOF
If you design you application properly, then you can have no single point of failure. It's very easy to connect two sockets to another one. So if one of them fails - the other is there to handle the work. There are things like High water marks to help you along the way. Read the ZeroMQ Guide to learn how to design your app without a SPOF.
Transports and routing
Regarding transport options (if I'm understanding this correctly) - it's up to you to define your protocol. ZeroMQ basically promises you that it will deliver this blob of data to the other end. Use JSON, Protocol buffers, Morse code, whatever you like.
There is no built-in routing in like there is in AMQP. Again, it up to you to specify which ZeroMQ socket connects to which, but this is very easy.
Stability
I've been developing with it for a few months (using Python) and haven't found a single issue with its stability. Even when I try to use it the wrong way it just throws a nice error telling me not to do that. Even restarting/killing some of the services and bringing them back up doesn't cause any problems. I'd say it a very stable piece of software.
As a note: always use the latest version - the 2.1 version is very much stability oriented, so many stability issues are resolved in it.
Community
Bindings for more than 20 languages, active mailing list, very good documentation, frequent releases. Anything else?
Integration
Because it's designed as a library it's up to you to design you application (unlike the case with a framework) and it pretty much stands out of your way. It feels a bit like a normal TCP socket, much more powerful and easier to use (it guarantees you that a message will be delivered as a whole, not only the first 128 bytes and the rest later as it the case with regular sockets).
Gotchas
There are some, but they are all documented in the guide. (For example: you might miss the first few messages from a PUB socket when you connect (SUB) to it. There is an explanation to this in the guide and a recipe how to handle it).
Overall
I find this one of the best designed pieces of software - stable, well written, well documented and doesn't stand in my way.
I recommend you to read the guide end-to-end. It's well written, examples in a lot of languages (including C++) and it describes a lot of edge cases and pain points.
I have been doing some catching up lately by reading about cloud hosting.
For a client that has about the same characteristics as StackOverflow (Windows stack, same amount of visitors), I need to set up a hosting environment. Stackoverflow went from renting to buying.
The question is why didn't they choose cloud hosting?
Since Stackoverflow doesn't use any weird stuff that needs to run on a dedicated server and supposedly cloud hosting is 'the' solution, why not use it?
By getting answers to this question I hope to be able to make a weighted decision myself.
I honestly do not know why SO runs like it does, on privately owned servers.
However, I can assume why a website would prefer this:
Maintainability - when things DO go wrong, you want to be hands-on on the problem, and solve it as quickly as possible, without needing to count on some third-party. Of course the downside is that you need to be available 24/7 to handle these problems.
Scalability - Cloud hosting (or any external hosting, for that matter) is very convenient for a small to medium-sized site. And most of the hosting providers today do give you the option to start small (shared hosting for example) and grow to private servers/VPN/etc... But if you truly believe you will need that extra growth space, you might want to count only on your own infrastructure.
Full Control - with your own servers, you are never bound to any restrictions or limitations a hosting service might impose on you. Run whatever you want, hog your CPU or your RAM, whatever. It's your server. Many hosting providers do not give you this freedom (unless you pay up, of course :) )
Again, this is a cost-effectiveness issue, and each business will handle it differently.
I think this might be a big reason why:
Cloud databases are typically more
limited in functionality than their
local counterparts. App Engine returns
up to 1000 results. SimpleDB times out
within 5 seconds. Joining records from
two tables in a single query breaks
databases optimized for scale. App
Engine offers specialized storage and
query types such as geographical
coordinates.
The database layer of a cloud instance
can be abstracted as a separate
best-of-breed layer within a cloud
stack but developers are most likely
to use the local solution for both its
speed and simplicity.
From Niall Kennedy
Obviously I cannot say for StackOverflow, but I have a few clients that went the "cloud hosting" route. All of which are now frantically trying to get off of the cloud.
In a lot of cases, it just isn't 100% there yet. Limitations in user tracking (passing of requestor's IP address), fluctuating performance due to other load on the cloud, and unknown usage number are just a few of the issues that have came up.
From what I've seen (and this is just based on reading various blogged stories) most of the time the dollar-costs of cloud hosting just don't work out, especially given a little bit of planning or analysis. It's only really valuable for somebody who expects highly fluctuating traffic which defies prediction, or seasonal bursts. I guess in it's infancy it's just not quite competitive enough.
IIRC Jeff and Joel said (in one of the podcasts) that they did actually run the numbers and it didn't work out cloud-favouring.
I think Jeff said in one of the Podcasts that he wanted to learn a lot of things about hosting, and generally has fun doing it. Some headaches aside (see the SO blog), I think it's a great learning experience.
Cloud computing definitely has it's advantages as many of the other answers have noted, but sometimes you just want to be able to control every bit of your server.
I looked into it once for quite a small site. Running a small Amazon instance for a year would cost around £700 + bandwidth costs + S3 storage costs. VPS hosting with similar specs and a decent bandwidth allowance chucked in is around £500. So I think cost has a lot to do with it unless you are going to have fluctuating traffic and lots of it!
I'm sure someone from SO will answer it but "Isn't just more hassle"? Old school hosting is still cheap and unless you got big scalability problems why would you do cloud hosting?