Web socket connections are perfect for keeping your user interface synchronized with the reality of the backend. There are certainly novel solutions to long-polling to simulate this effect, but it's neither elegant, nor efficient. The trouble with web socket development is that unless you've got the backend chops necessary to keep a mock web socked environment maintained, it's often easier to go the polling route. It's just a matter of the UI developer being able to independently write code. However, there's a way to do web socket development independent of a backend connection, allowing the UI developer to implement real-time updates.
Showing posts with label websocket. Show all posts
Showing posts with label websocket. Show all posts
Wednesday, January 29, 2014
Wednesday, August 29, 2012
Delivery and Display
I sometimes find myself wondering about how web application data is delivered, and how it is displayed. Well, I actually have a good understanding of the mechanics behind it all — HTTP and HTML are the prominent technologies. What I don't understand is how the thinking behind these two technologies is changing. There was a time when HTML and HTTP were all that were needed to get the job done. And by job I of course mean a functional interface to the application. The client-server architecture that occupies the vast majority of what we interact with on the web works really well. The command response style of working with resources is simple, obvious, and well tested.
Tuesday, May 22, 2012
The Live Web
Ars has an interesting perspective on the future possibilities of web sockets and the real-time applications made possible by this technology. MMO is a good example domain. Lots of concurrent users need simultaneous updates with as little latency possible. I'm trying to be careful with my words here - real-time isn't exactly attainable to the same degree as Skype or WoW. At least not with the currently-available combinations of server and client technologies for the web. The potential is most certainly there, but is it real-time MMO style domains we should chasing after with web sockets?
I would argue that it might be a little premature to dive-into such problems with web sockets as your weapon. Especially since these large scale problems already have solutions implemented that work quite well. Another hurdle facing web developers and their ambition to solve big programming challenges with web sockets is lack of browser support.
Factors that work against web socket technology are also it's strength. Why not use web sockets to make the current web a little more responsive? Why not give your users a sense of liveliness when they visit your web pages? Before web sockets came along — they're only now beginning to gain populatrity in the web development community — it was painful to make even the most basic information current. We're getting closer to doing this seamlessly now. The question is, where do we start?
The Static Web
Looking in the opposite direction from that of the MMO domain, let's think about static web pages. By static web pages, I don't necessarily mean flat HTML files sitting on a server somewhere, waiting for a user agent to request a copy. The static web can just as well be dynamically-generated web pages, assembled during request time from numerous sources. The static web is only static from the user's perspective. That is, they request a page, and once it arrives, it's dead. Nothing more than a copy of the real data with no potential to evolve and keep in tune with it's origin. You could keep your browser window open for a decade and watch the DOM elements collect dust.
Thinking about web pages this way really digs at the core problem that web socket technology addresses. We want our users to receive live data. When the real data that's stored in the database changes state, we want those changes available instantaneously. That means that any active web socket connection will receive new data, instructing the DOM elements in the client's browser to rearrange themselves. Sounds great, doesn't it?
Let's imagine that we had a framework that enabled us to keep content live like this. Now, who would this web socket framework benefit? Like most content on the web, this blog for example, there isn't much to gain simply due to the nature of the data. It gets written, published, maybe updated once or twice. Other than that, my blog data becomes stale shortly after it's published. Let's not confuse staleness with usefulness. Staleness means that other components that rely on fresh, or near real-time data, can't rely on it.
So having said that, if the vast majority of static web content out there has nothing major to gain from web socket technology, what does? I'm talking, of course, outside of the MMO domain here — how do we think about data that goes on the web in terms of liveliness?
Reshaping Data
If we're going to make good use of technology that allows us to publish changes to data as they happen, we should first look at the frequency of change. That is, how often would we be pushing out updates to the web browser? If the answer lies somewhere between once every couple minutes and once per second, your data is live and should be reflected in the user experience you provide. Another way to visualize how users deal with stale data is to picture them hitting the refresh button — their lifeline for new information.
The reality is, I think, that most information available in the static web universe follows a pattern shaped by the fact that users only have a one-time view of the data. We're not designing websites with the hope that users will simply hit refresh to synchronize with reality. Sure, we've got to accommodate this behaviour as it is the expectation — users want fresh data and there is a magic button built-in to every browser that will make that happen. But is that the best we can do for folks? Or can we raise the expectation that what they're looking at is reasonably accurate?
Doing so isn't trivial because we have to rethink what changes in state mean for the application. When data gets written to the database in your typical web application, that means nothing for most users. They might get a response, telling of the newly-created entity. But what does that mean for other views of the data model? Does it impact statistical views that someone in a cave might be staring at? Absolutely. Does it mean that the application should take notice of these changes in state and make relevant users sessions aware? You bet.
On top of all this talk about real-time MMO gaming, and events that should be pushed out to user sessions in an otherwise static web application, we're one step closer to making web applications the dominant platform. Developers target specific mobile and desktop platforms for a number of reasons, one of which, it's easier to get up-to-date data into the UI. I can see the gap between the two closing in — but before that happens, we need to somehow merge the static web and the live web. There is nothing wrong with the web the way it is today for displaying certain kinds of information. But we're now able to start taking seriously the notion of real-time data in domains where timeliness matters.
I would argue that it might be a little premature to dive-into such problems with web sockets as your weapon. Especially since these large scale problems already have solutions implemented that work quite well. Another hurdle facing web developers and their ambition to solve big programming challenges with web sockets is lack of browser support.
Factors that work against web socket technology are also it's strength. Why not use web sockets to make the current web a little more responsive? Why not give your users a sense of liveliness when they visit your web pages? Before web sockets came along — they're only now beginning to gain populatrity in the web development community — it was painful to make even the most basic information current. We're getting closer to doing this seamlessly now. The question is, where do we start?
The Static Web
Looking in the opposite direction from that of the MMO domain, let's think about static web pages. By static web pages, I don't necessarily mean flat HTML files sitting on a server somewhere, waiting for a user agent to request a copy. The static web can just as well be dynamically-generated web pages, assembled during request time from numerous sources. The static web is only static from the user's perspective. That is, they request a page, and once it arrives, it's dead. Nothing more than a copy of the real data with no potential to evolve and keep in tune with it's origin. You could keep your browser window open for a decade and watch the DOM elements collect dust.
Thinking about web pages this way really digs at the core problem that web socket technology addresses. We want our users to receive live data. When the real data that's stored in the database changes state, we want those changes available instantaneously. That means that any active web socket connection will receive new data, instructing the DOM elements in the client's browser to rearrange themselves. Sounds great, doesn't it?
Let's imagine that we had a framework that enabled us to keep content live like this. Now, who would this web socket framework benefit? Like most content on the web, this blog for example, there isn't much to gain simply due to the nature of the data. It gets written, published, maybe updated once or twice. Other than that, my blog data becomes stale shortly after it's published. Let's not confuse staleness with usefulness. Staleness means that other components that rely on fresh, or near real-time data, can't rely on it.
So having said that, if the vast majority of static web content out there has nothing major to gain from web socket technology, what does? I'm talking, of course, outside of the MMO domain here — how do we think about data that goes on the web in terms of liveliness?
Reshaping Data
If we're going to make good use of technology that allows us to publish changes to data as they happen, we should first look at the frequency of change. That is, how often would we be pushing out updates to the web browser? If the answer lies somewhere between once every couple minutes and once per second, your data is live and should be reflected in the user experience you provide. Another way to visualize how users deal with stale data is to picture them hitting the refresh button — their lifeline for new information.
The reality is, I think, that most information available in the static web universe follows a pattern shaped by the fact that users only have a one-time view of the data. We're not designing websites with the hope that users will simply hit refresh to synchronize with reality. Sure, we've got to accommodate this behaviour as it is the expectation — users want fresh data and there is a magic button built-in to every browser that will make that happen. But is that the best we can do for folks? Or can we raise the expectation that what they're looking at is reasonably accurate?
Doing so isn't trivial because we have to rethink what changes in state mean for the application. When data gets written to the database in your typical web application, that means nothing for most users. They might get a response, telling of the newly-created entity. But what does that mean for other views of the data model? Does it impact statistical views that someone in a cave might be staring at? Absolutely. Does it mean that the application should take notice of these changes in state and make relevant users sessions aware? You bet.
On top of all this talk about real-time MMO gaming, and events that should be pushed out to user sessions in an otherwise static web application, we're one step closer to making web applications the dominant platform. Developers target specific mobile and desktop platforms for a number of reasons, one of which, it's easier to get up-to-date data into the UI. I can see the gap between the two closing in — but before that happens, we need to somehow merge the static web and the live web. There is nothing wrong with the web the way it is today for displaying certain kinds of information. But we're now able to start taking seriously the notion of real-time data in domains where timeliness matters.
Thursday, March 15, 2012
Web Sockets and Statelessness
The web works better when it's stateless, so the theory goes. Stateless meaning that the client and server are largely decoupled from one another. When applications are stateless, I can start a session on one computer, do something, and start another session elsewhere without worry. Put another way, in the context of web applications, we're talking about stateless clients — all the application data resides on the server.
Statelessness matters because it's how we're able to scale to many concurrent users. This would be a daunting task if every action the user performed was managed by the server. And so the web scales through simplicity — transferring the state of applications over HTTP.
Now we're seeing new protocols for how web application clients communicate with the server. You want to use web sockets when interactivity is important — when updates in application state are unpredictable and thus difficult to publish over HTTP. Intuitively, we'd like to use an abstraction that keeps the communication channel with the server open and listens for incoming data. What, if anything does that mean for statelessness and how well will it scale, if at all?
When I first started experimenting with web socket technology, I was balked at the prospect of passing state back and forth rather than in a single direction. But once you start using web sockets, it's really not that far a stretch from the tradition of HTTP. It's just a communication protocol, and we can still apply RESTful principles to it.
Ask Now, Answer Later
A key advantage of web socket abstractions is the ability to ask a question, and not have to wait around for the answer. If you need to get a list of objects, you issue a the command to fetch those objects over a web socket. The web socket connection, at an indeterminate point in time after the command was issued, will receive the list of objects. The client's web socket connection passes this data into the Javascript code that can handle it however it wants.
What does this mean for the application running on the server that has to eventually respond to these socket requests? Is this new technology somehow fixing a bottleneck in how requests block others from being fulfilled. Not exactly. Traditional HTTP requests only appear as though the server is actually spending significant effort in satisfying your request when in fact it's probably handling many requests simultaneously. Well, I'm sure there are plenty of cases where there are longer-running requests that may actually affect the duration of others in the system. However, these HTTP requests need a response in order to complete the workflow. HTTP requests expect to be acknowledged somehow. Sockets, on the other hand, we can fire and forget.
Once a web socket requests lands on it's target server infrastructure, it goes about it's chores like any other client-server request. It even responds to the client. How this is actually accomplished largely depends on the web application framework you're using. For example, maybe the incoming web socket request spawns a new handler thread, within, the connection is available for writing back to the client. Or, maybe you're not given any sort of client connection you can update as simply as a file object. Maybe you have to go find it based on the request's session. The end result, of course, means that you're no longer dealing with the traditional request handler abstraction where you can forget about the client once you've honoured your duties. And this can cause a challenge in complexity.
With the flexibility that web sockets afford an application come new obstacles that we're not overly-concerned with, if at all, in our more traditional HTTP applications. Once you've managed to wrap your head around the never-ending-connection philosophy, you'll start to realize that these sockets really do solve some ugly work-arounds that would otherwise need band-aids in HTTP land. For instance, a command issued by the client might want to send sparse feedback — with a second or two in between. This type of thing one can do blindfolded with web sockets. It's the other little hindrances that'll make for an interesting experience — like softening of the command-response architecture rules. Correspondingly, the stateless style of application we're used to building suddenly becomes foreign to us.
State Delivery
RESTful architectures push for statelessness by transferring the current state of data over the wire and to the client. There is no such thing as state that remains in the web browser, aside from what the user is currently viewing or interacting with. So my nagging concern about web sockets has always been along the lines of, how can we achieve something similar to stateless user interfaces? I'm guessing I'm not alone when I don't want to throw out my learned experience with designing resilient systems that scale based on the principle of statelessness.
I've now come to understand that this is in fact not the case — web sockets aren't out to destroy our grounded beliefs in the command-response architecture. No, web sockets are simply a delivery mechanism whereby state is transferred to some agent listening for it. Not that different from HTTP, only improved for certain situations. Like when state changes rapidly — more than once during a single command. We need an intuitive method of transferring these changes in state back to the client without shooting ourselves in the foot with traditional HTTP modes.
I would say the frequency of state changes in your application domain will serve nicely as an indicator of how necessary web sockets are. If it is frequent enough, perhaps web sockets are the answer. Perhaps it'll make developing the using interface code that much easier by not having to result to polling techniques. Because when you start implementing polling yourself, you're emulating the user hitting the refresh button. If it seems silly to you that the user sit in her chair and click refresh constantly, it may be time to consider building with an abstraction better aligned with the model your data is asking for.
Statelessness matters because it's how we're able to scale to many concurrent users. This would be a daunting task if every action the user performed was managed by the server. And so the web scales through simplicity — transferring the state of applications over HTTP.
Now we're seeing new protocols for how web application clients communicate with the server. You want to use web sockets when interactivity is important — when updates in application state are unpredictable and thus difficult to publish over HTTP. Intuitively, we'd like to use an abstraction that keeps the communication channel with the server open and listens for incoming data. What, if anything does that mean for statelessness and how well will it scale, if at all?
When I first started experimenting with web socket technology, I was balked at the prospect of passing state back and forth rather than in a single direction. But once you start using web sockets, it's really not that far a stretch from the tradition of HTTP. It's just a communication protocol, and we can still apply RESTful principles to it.
Ask Now, Answer Later
A key advantage of web socket abstractions is the ability to ask a question, and not have to wait around for the answer. If you need to get a list of objects, you issue a the command to fetch those objects over a web socket. The web socket connection, at an indeterminate point in time after the command was issued, will receive the list of objects. The client's web socket connection passes this data into the Javascript code that can handle it however it wants.
What does this mean for the application running on the server that has to eventually respond to these socket requests? Is this new technology somehow fixing a bottleneck in how requests block others from being fulfilled. Not exactly. Traditional HTTP requests only appear as though the server is actually spending significant effort in satisfying your request when in fact it's probably handling many requests simultaneously. Well, I'm sure there are plenty of cases where there are longer-running requests that may actually affect the duration of others in the system. However, these HTTP requests need a response in order to complete the workflow. HTTP requests expect to be acknowledged somehow. Sockets, on the other hand, we can fire and forget.
Once a web socket requests lands on it's target server infrastructure, it goes about it's chores like any other client-server request. It even responds to the client. How this is actually accomplished largely depends on the web application framework you're using. For example, maybe the incoming web socket request spawns a new handler thread, within, the connection is available for writing back to the client. Or, maybe you're not given any sort of client connection you can update as simply as a file object. Maybe you have to go find it based on the request's session. The end result, of course, means that you're no longer dealing with the traditional request handler abstraction where you can forget about the client once you've honoured your duties. And this can cause a challenge in complexity.
With the flexibility that web sockets afford an application come new obstacles that we're not overly-concerned with, if at all, in our more traditional HTTP applications. Once you've managed to wrap your head around the never-ending-connection philosophy, you'll start to realize that these sockets really do solve some ugly work-arounds that would otherwise need band-aids in HTTP land. For instance, a command issued by the client might want to send sparse feedback — with a second or two in between. This type of thing one can do blindfolded with web sockets. It's the other little hindrances that'll make for an interesting experience — like softening of the command-response architecture rules. Correspondingly, the stateless style of application we're used to building suddenly becomes foreign to us.
State Delivery
RESTful architectures push for statelessness by transferring the current state of data over the wire and to the client. There is no such thing as state that remains in the web browser, aside from what the user is currently viewing or interacting with. So my nagging concern about web sockets has always been along the lines of, how can we achieve something similar to stateless user interfaces? I'm guessing I'm not alone when I don't want to throw out my learned experience with designing resilient systems that scale based on the principle of statelessness.
I've now come to understand that this is in fact not the case — web sockets aren't out to destroy our grounded beliefs in the command-response architecture. No, web sockets are simply a delivery mechanism whereby state is transferred to some agent listening for it. Not that different from HTTP, only improved for certain situations. Like when state changes rapidly — more than once during a single command. We need an intuitive method of transferring these changes in state back to the client without shooting ourselves in the foot with traditional HTTP modes.
I would say the frequency of state changes in your application domain will serve nicely as an indicator of how necessary web sockets are. If it is frequent enough, perhaps web sockets are the answer. Perhaps it'll make developing the using interface code that much easier by not having to result to polling techniques. Because when you start implementing polling yourself, you're emulating the user hitting the refresh button. If it seems silly to you that the user sit in her chair and click refresh constantly, it may be time to consider building with an abstraction better aligned with the model your data is asking for.
Subscribe to:
Posts
(
Atom
)