Web is the main medium to share information and access data on internet. It is usually tight to browser - proxies/routers - web server. The main protocol is HTTP and most of the internet services are HTTP oriented.
HTTP at the beginning was only about one site communication: client makes a request to server and server prepares response. Now web is more then simple request response. It’s a medium for application. And applications often require more then a single site communication.
push notifications - often denoted as a mechanism which allow server to sent requests / events to a client.
There are a lot of solution to integrate HTTP with bi-directional communication, to implement push notifications for a web server.
Instead of describing available solutions, I will point to some resources, which did it:
- Push technology - Wikipedia article, quiet technical.
- What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? - clean overview of push technologies, TLDR for those who don’t want read Wikipedia article.
- Stream Updates with Server-Sent Events - a great overview for Server-Sent Event Technology.
A lot of programmers make a question:
- Which realtime technology should I use for realtime communication?
- What to use for push notifications
- WebSockets vs Server-Sent Event vs Comet
- Socket.IO vs SockJS or pure WebSockets?
WebSockets is probably one of the best solution. It provides fast and secure bidirectional connection. All we need in terms of functionality. But it has some drawbacks:
- Hard to implement.
- Evolving standard. Not all client libraries are compatible with the newest one.
- It’s not HTTP. It resembles only at the beginning - on handshake. Then it updates to WebSockets protocol. This mean that it can make a problems on some HTTP based infrastructures (proxy servers, firewalls, ...).
- Lacks automatic reconnection.
You can also look at SockJS or Socket.IO, which abstracts from the underground transport layer and provide you good, WebSockets like API for your realtime communication. This is especially useful when you need to support different clients (mobiles, desktop browsers...).
The problem with Socket.IO is that it is equated to it’s Node.js implementation on a web server. Other implementations are quiet behind and has some potential problems with new library versions.
SockJS has better interoperability and parallel supports other implementations on web servers.
Finally if your client requirements are not so big (IE 8+, Firefox 6+, Chrome 6+, Safari 5+, Opera 11+ is enough) you should look at Server-Sent Events
SSE is a regular HTTP and uses single long streaming connection. It has lot of advantages:
- Transported over regular HTTP instead of a custom protocol (using HTTP streaming) - you don’t need special server implementation!
- It’s much simpler to implement and debug. Protocol is dead simple and it’s all text. You don’t need huge server-side library or 3rd party service, You can just print the lines yourself.
- Fast and secure. Even faster to initiate then WebSockets. Also the protocol has less overhead (messages are not divided into frames/packets).
- Doesn’t require any tricks or reconnects you can find in Comet implementations.
- Built in support for automatic re-connection and event-id.
- It can switch between permanent connection and polling at any time, so you can change strategy depending on your server load (e.g. if you run into connection limit, just drop some clients, they’ll reconnect in couple of seconds).
All you need is a client with a good HTTP support. If your browser doesn’t provide Server-Sent Events API (EventSource) you can easily polyfill it.
The only drawback is that SSE connections are simplex - only capable to send data (events) from Server. For most of the use cases it is not a problem. You can use HTTP XHR requests and stay with your HTTP web application server! It performs really good for most scenarios.
When SSE is not good enough?
Good answer for this question comes from HTML5Rocks article:
One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn’t need to be sent from the client. You simply need updates from some server action. A few examples would be friends’ status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store). If you’ll need to send data to a server, XMLHttpRequest is always a friend.
That means we can go rid of realtime framework and maintain additional services. Just use Server-Sent Events!
Want to read more? Take html5 Doctor article.
Probably a lot of business clients are worried about technology stack they want to use for their IT web services. Recently I was talking with some company about new project. They were concerned about technology they should use for their web startup.
It is a responsible decisions, and a lot of people have similar concerns. If you want to contract a serious project, you probably want to be aware about technology choice, you won’t end up in a dirty hole.
When choosing a programming language you should start with collecting requirements:
- How many users you want to handle (overall)?
- How many users you want to handle per second?
- Does your application needs to have real-time communication with a server?
- Do you have third party libraries you want to use?
More complicated jobs are done by separate workers.
Assuming you want to use stable environment, and don’t be limited by libraries support you will probably consider the most popular programming languages. I will quickly discuss some of them.
Chosen by big players. It doesn’t mean that Java is the best one. Java was built around Enterprise model. At the beginning they planed to make business around it (the same .NET). It means that Java is:
- expensive. The costs come with overcomplicated solutions.
But it also means that they are overestimated. Just check how popular web framework are going. Which startup is using Enteprise now? It’s complicated. Sprigs goes towards Rails model now (and still doesn’t have WebSockets support). Leading companies, which want to have Java stack, prefer new fresh solutions (Play, Scala etc...) - LinkedIn, Xerox. Google have their own solutions. Oracle? They took open MySQL and almost close it. Just look how they did with 5.6 release.
Python / Ruby
Very fast developing and prototyping. Enjoy when coding, easy to maintain and refactor. Most of the web is driven by Python / Ruby / PHP frameworks (I don’t want to talk about the last one). Those languages are built by professional geeks.
Disadvantage: not as fast as Java. But for serving web content it is fast enough. Because there are implementations with JIT (eg PyPy, Numba for Python), this disadvantage is going to be even weaker. JIT gives a huge boost.
Others also can argue that dynamic type languages (like Python, Ruby) are error prone. Static types allows you to find bugs earlier, but only some of them. If want to rely on static type checking, then I feel sorry for your applications and developers. All in all you need to have tests that cover all functions. Those tests, by the way, make validations about arguments (types) you pass to functions. On the other hand Java type hierarchy slows your development and makes refactoring hard.
Like the previous one. Brings performance rather then reliability.
The newcomer. Takes the best from Java (fast) and Python / Ruby (fun, productive). Have simple yet powerful type hierarchy. Disadvantages: although the project is stable, there are not a lot of tools around it. Some which exists are not as rich / mature as the ones we have in previous technologies.
Nonetheless Go is already used in production (Google, Heroku). It proves its usability and productivity as a general programming language: http://www.youtube.com/watch?v=kKQLhGZVN4A . The teams, which give Go a chance are happy for this decisions.
Which one to choose?
Long story short: choose the one for which you have proficient developers. Really!
Web backend doesn’t require so much complicated tools (those are done through separate workers, if not then it means your app is unsafe and aware of critical bugs, data crash etc...).
Which I’m choosing?
If I need to make a choice I will choose Go or Python. Go has a great network and concurrency support. Actually I’m developing surfer - new web framework in Go programming language. I just don’t like Java. Even Scala - it’s hard to find specialists and is over-complicated (thought once I was fascinated about it). Just compare the results:
- why I don’t like Java google query. The second position from Ask Hacker News is quiet interesting: http://news.ycombinator.com/item?id=4406224 . Please, read the first (most scored) response - by strlen
- why I don’t like Python google query. Surprisingly we have analogous Ask Hacker News: http://news.ycombinator.com/item?id=1463425 - again the first (most scored) response by gte910h makes my point.
Believe me I haven’t read those post before. I’ve just wanted to prove that other geeks share similar opinion. And I was positively surprised.