 Good afternoon everybody My name is Kashi Kran Prishnassai. I work in a company called School of Shire Shopping. The brief introduction as well is that Shere Spool is concerned. Okay, this is good. The brief introduction as well Sorry, I've been having a terrible cold. The brief introduction as well is that Shere Spool has been concerned Has been that I've been writing JavaScript for the last two years My code initially used to be extremely sucky actually four years code used to be initially sucky now It's like much less Okay, so the talk today that I want to give is about The talk today. I'm gonna give is about a real-time web and How to actually go about implementing real-time strategies? I mean implementing real-time infrastructure in your existing web application So the history on how I actually ended up doing real-time web is we developed this product my project management software and We got a lot of requests from people saying that you know There are like lots of people logged in to the board at the same time And they want to see what each of them are like updating so if one is updating something on the board and The other person wants wants to see what actually is happening. So Because of this We're like thinking about like various ways of like implementing this probably like Reloading the page every couple of seconds and all of them seemed intrusive and we had to go We had to dive into technology and start doing the really cutting-edge cool stuff So that's how we started running our fingers with red time web and last time When by we kind of like managed to I think we can kind of manage David So what I'm gonna do today is I'm not gonna talk through all the options possible. I'm gonna do it another way We're gonna assume that We are having a web application. So I've just created a simple to-do list and a Simple static. I mean a simple to-do list and they're gonna see how we can actually implement real-time stretch I mean how we can implement real-time on that Web app. So these are the general steps that we would I would suggest anyone who they're considering real-time to First and foremost before you actually start doing real-time make sure your code is actually clean because lots of event when programming and if your code is already messy Then it's gonna be really hard to implement Then I like The first step would be to like start using new functionalities available in like modern browsers like web sockets like an awesome technology I'm pretty sure lots of people who have talked about it Through the course today. So we want to see how we use web socket start implementing that time at least for the new browsers Whereas for older browsers, you know, just don't do anything. Let's leave it and then We go to the next step where and we say, okay, okay new browsers own browsers Let's implement real time for all the browsers. So all the all the browsers that includes IE six, which is like After that, I mean you have real time you have a nice system working and then you start realizing that Maintaining that code is really complicated. So what are the strategies you do what's ideal? What are what are things that you can do with the technologies available to make? maintenance really simple and finally The usual deployment scalability and all those big words Let's give you a hand loss so Let me jump into the court. I think that makes a lot more sense Okay, so this Is the code for a very simple Web app So what does it do? It's it's basically a task Simple to do this, okay, you go click on something it turns green which means you complete it Take it again turns red, right? Very simple. And yeah, if you want to add a task you add something else Now So This is all fun, right? I tell you when it's not fun when I like two or three people working on this through this and You have one guy using firefox, there is another guy On Google Chrome doing the same thing. Well, he's like changed it to green is that doesn't get reflected here Right. So what this guy has to do is they constantly keep refreshing the page, which is a sad thing to do okay, so Let's look at the code. I mean this is probably how most of us write our code initially if you're at least loaded I think I started writing it like yesterday night and Initially, you know, it's it's like crazy. So you have like a render task the render task Okay, before that, okay, you get tasks from the back end and You allow tasks to be in them. So get us. That's a Jack's query. It's a list of tasks as Jason object I mean just the projects to Jason format And for every time that was a turn Render task so render task then does it and also like does the call back to make do an edit So it's it's a bit of a mess, right? So Yeah what's happening is code is like And that technically means the truck factor is one. How many of you know what a truck factor is? Any guesses it's like this Assume truck factors technically the number of people who are working on a project on whose absence the project will come to a standstill so Very crudely put the number of people from your team who have to get run over by a truck for the project to come to a complete Sansa so the truck factors one which technically means the guy who wrote that quote is the only one who actually understood it So that's gonna be like really complicated, right? So, yeah, why was the truck factor one because business logic data and rendering are all tied up There are like two functions which does the rendering which also does the data patch which handles the data and which also That's like the logic on the click, right? now Such codes are really really hard to test testing is extremely hard and Feature addition is even more harder because you're like you already have a really big Big messed up system and you're trying to squeeze in something else within the force and that's like adding complication chaos to the system, right? Which all boys down to the fact that they are going to be box. No excuses. They will definitely be box I'd be really surprised if a guy can like a code like that and come and say it's completely buck me Right, so what are we gonna do first step step zero is to clean our code be ready for real time Step zero is essentially decoupled logic data and rendering So let's look at the code again. So I am gonna show you a slightly different version of the code What I've done over here is I've used back home Which is like a nice JavaScript framework from writing like rapid web applications There was actually supposed to be a talk on that one's questions. He was not possible. So So back what it does it can influence the MVC strategy on the front end. So you have like models You have models and you have collections which are like a list of models So what about every every time you get Data you like get the data and like populate the collection create a model for each start and populate and You can also it also does signal handings or technically if it fires a signal Every time a new model is created every time a new model is edited or anything of that sort Signals created and you can listen to the signal and like do it So essentially what am I doing? I'm breaking down and like isolating my models Isolating the logic and how whether or there's a task change the So isolating rendering so whenever a task changes, I mean when you like change it to like done or not started how that gets rendered and you have your logic separately so the kick logic on the structure is separate so there's not technically completely Ordinary MVC for MVC example, but this is a way this is a place to get started So from that convoluted code you've come to a slightly more organized piece of code So yeah, yeah So what's happened? this Was much more cleaner Which technically means course also easily testable Changed in logic data schema and rendering is easy So if you're like changing away your task models like past or the way tasks are rendered on the page Or how you handle it so instead of that clicking if you want to put a checkbox So all those things have been like decoupled So you can you only have to have to change small bits of code instead of like all the code and yeah I technically avoid repetition on all the good traits of good programming Adding new functionality is easy. So this is where you have to be in order to even start doing start thinking about So step one, what are we gonna do web sockets? Brilliant real-time support for browsers which support the awesome HTML that fire web sockets pick Right to fail there for browsers written for a couple of others. I mean that's technically a great story So make sure that browsers which have web socket Will you use the web socket and for browsers which do not have or which do not have web socket implementations Don't do anything just leave it as such so you can actually tell your customers saying hey You know what we want additional functionalities start using it in Chrome or firebox. It's a bad thing to say But at least it's a start right so a Small bit of note on the technologies have used technologies. You can use and stuff like that I'm using to order, which is like a Python web server Running on a different port which basically handles web socket connections So web sockets are not handled the way HTTP is right So what happens? If you get any details, it's basically you start with a HTTP 1.1 call and then that gets upgraded into the web socket spec But as implementers we need not worry much about it because your framework your browser and your server will like take care of it What you need to know what you need to like do is get a server which had which does the web socket Spec properly the tornado does if it has a web socket handle So I'm using that and I'm running it in a separate port not only default port 18, but on a different port 88 I'm going to use the native web socket JS API Which comes with a browser to create a new connection with my web socket server and like pass data Do nothing when I impossible integrate the user. This is a nice way to do it This from a conference for which I was like So, yeah Let's look at the code again. So what's now happening This unit like I've written a method called a real time So I'll come to this check later on so essentially what it does is it creates a Web socket connection Connects it to port 80 ad and Whenever the connection the server sends a message this receives it and this functions the call back for the server's message So it basically picks a tough object and like updates its own collection So what am I doing in this step? I'm Whenever I do an edit and it goes to us it goes to the server To my actual app server after I get a success call back I I send a message to all the to the web socket server saying notify all of the friends that this Update has taken place so the technically So this is the ad task so I added task on the success of it I sent WS the web socket Variable in which we store the web socket and So I say WS dot send a j-signified Representation of the task so the task has a name an ID and a status right This T dot get okay, you don't get a party around that backbone model methods, which is like basically get the The property of the task So yeah, so what are we done? We send a message and other we send a message from one browser and other servers Sorry other servers receive it over here I mean other other client other browser clients a browser's will receive the same signal over here So that's like the second step So I'll actually show you how it runs You see both the browser's I'm gonna Make this so that gets changed on the other thing so what what's actually happening goes to the server So it is stores it in the back end Then comes back on the subsist on the subsist sends a message to a live server saying hey update on all the other clients But I open Internet Explorer nothing's gonna happen so The changes will happen in Chrome and in Firefox, but on Internet Explorer nothing is gonna happen because Internet Explorer The version at least the version I have does not support the web socket Right So we got Simple homogeneous So I'll actually come to that in the third step, so I just wanna like go on incrementally, right? So Your ad or it using web sockets is done So we have a real-time back-end server running on a different port a full real-time support for new browsers and No real-time support for old browsers. Okay a bit of a note here in the code. I was doing Something like this Now what what is I actually doing now the web socket? Spec has only been recently very recently finalized until then all the browsers love the spec and the spec was in progress as well So they used to implement various various versions of the spec So Firefox has this crazy idea of like adding a prefix to anything that has not been like standardized So fire in Firefox, you can't just do a new web socket. You have to do a new Mars website All right. I think the latest version of Firefox. It's kind of being it's it's become web socket again and In Chrome, well, it's web socket. So what am I doing? I'm actually doing I'm actually doing a feature snips I'm seeing if the web socket features available and if it's on the Mars web socket name Then I say that's the class I have to use if it's not there Then I say okay at least you get web socket. So so that I say hey, it's a webkit based browser If it's not there as well, then I say return don't do anything if it's there then create a web socket connection and do Right Yeah, so Full real-time support for new browsers no real-time support for old browsers If you if you hate Internet Explorer users, you can stop right here. You have a fully working system But as it turns out most of us, I think there was a graph which was shown the other room We are like some 26% of you internet users who still use IE sticks So for those blocks you I mean you really want to explain give real time to all your customers, right? You don't want like selectively, you know Give it off to people. So What are we what are we going to do in this step step to use a combination of comic? Web sockets flash and any other possible technology that is possible to create across browser functionality which is kind of uniform across all browsers so Comet what is Comet Doing non-http things through http ways It's a ugly hack, but it works and people have been using it much before the web socket spec even came So, yeah, the technology we're going to use is something like socket.io or js.io or something similar in the front end and Us a server which also understands the handshake. So let me explain this to you I Have a browser and I have a socket IO client. Okay, it's a piece of it's a piece of code What it's going to do is it's kind of like a snip. I'm saying how I got web socket. No Have I got flash support? No Then I should probably do http long polling so it falls back to the technology available right and In the back end and then once it falls back to the technology available It notifies its server saying I'm going to communicate with you for real-time communications using this So is that it using http long polling or using like http multi-part cards or using web sockets So what it does is yeah, yeah, you saw the previous code where I actually put that features in it for like much web socket or I Mean that was just for web socket like two browsers We are now talking about like lots of technologies and the big there's a huge logic involved on deciding which Which is the protocol that I have to use to communicate with my real-time server now Libraries like socket IO makes that easy point. So it takes care of doing the handshake. It decides on which on which Channel or on which transport the data can be communicated and finally Once all these things have been decided you can just create a class and they start sending data Which can be like transfer between the lights over and your client So let's go look at code again Now if you see I use the socket IO the JS client library Which gives me This IO dot connect object. I use that I You start to connect to my server my server is run my server is not a mere web socket server It's not a smart server. It can like decide on which connection it has to use So once I do the new IO to connect it's gonna like this. It's gonna communicate They're gonna be a handshake and the most ideal transport is going to be chosen You can you have options to like tell These are only transports. I want the socket IO to use and there are various configurable options, which you can But let's leave that for me This is like very similar to what we're doing whenever it gets a message Connection receives a message execute this callback and the callback is exactly similar to what we did on the previous What we saw in the web socket message code Yeah, so the first preferred transport Transport method using this. Yeah, this library will like do use web socket then falls back to Flash then falls back to HTTP long coding then falls back to like God knows a lot of things. I mean high frames Never loading high frames and form multi parts and every possible hack okay, so let's actually look at This code again Well kill the web sockets over Now comes the big guy. They said I'm not going to use you to my good friend local on Cool So I think you can actually all the tree right now. So the magic happens works on IE as well So cool. We now have all of Real-time. I mean we now have real-time System in place which supports every browser. I mean, you can write right on compatibility more So, you know the first like 99% of your Cool So are we? Yeah Okay, so what I used is I Which is basically socket Ios for a server-side port into Python So a quick note here you can use a lot of servers You've got event machine which can handle that socket and like this thing Turnado has turn audio which is like do that and I think almost every major language Implementation every major language has an implementation which kind of uses the socket. I was standard in the back end to run a server No, I purposely did not use socket Ios server But used a Python server just to say that you know the communication handshake has been kind of standardized Thanks to talk it I which is being the first one which actually incremented the thing I mean, there was yes, I know which also talk about the handshakes right now socket. I was kind of become the de facto and socket I on the client side using that code and Using a server which understands the socket I or handshake protocols So are you saying that my server side code which will respond back to the Jason will be saying You Yeah, yeah, yeah, that's right. I can actually show you the code but it's gonna be Python If you can understand it like just a second so I was this is like a socket IO connection, which which is like which is Channel connection is from what turn audio gives. Oh, sorry So you have this thing called channel connection, which has basically the on message on open So the handshake is a completely taken care of my turn audio at the back end and socket So you have to write your logic over here and that gets like decimated across So usually You know The server goes down What happens in a web socket which has some kind of connection Yeah, that's that's the tricky part and that's that's a part that everyone that has a big time right now So there are a lot of which I will be talking about right now. So What we had is yeah We in this that we bring support for real time real real time even on ice six Abstracted out API to perform real-time action. So socket IO gives you this nice API by which you say send message And like decide on the transport itself On its underlying layer sense receives on school Right now is when you actually start talking strategies on how to So these are questions that are like Pop-up, okay, but when you look at The examples given by all these time on your legs socket IO You have like simple chart applications or simple to do the two applications like work But in your real app, you're gonna have things like yeah I mean you're gonna have multiple users and you don't want to see one user's data to go across all the users, right? Oh How about if an action is performed on an API so you expose API is to your back end So I do a post on to the API and how is that going to be reflected across all the people locked into my client and How about we need authentication? I mean we just all we did was like you know what open connections and data authentication is another big problem so What we what the web is heading towards is Especially the real time one is a pop-up channel based system So what there are these systems available which will like it's like chat So whenever you open a new connection you say I want to subscribe to this channel. Give me data to this channel alone okay, and Your back end will like if you're subscribed to that channel though you can do a lot of the kids saying hey I'm this user Please check with my back end if I am this user then add me to this channel and once you add it It'll like send you data only pertaining to that channel So you don't get to see what someone else is start to do this this right step one Actions activities performed through the API Okay before that I was telling you all these systems There's something there was something called hookbox which was like return last year Which was amazing in the ability that because Hupbox was written on top of A socket IO kind of system So all you had to do is open a hookbox connection say subscribe to this channel This are my authentication details hookbox and then go check with the back end see if you are the user with the authenticated Details then subscribe to the channel Javan art is another rails implementation which has been Implemented on top of socket IO, which does the exact same thing Yeah, I wrote one myself which so that technically means that it's not like really hard to implement such a thing So I I took up tornado and like wrote something over the weekend Which is basically a simple pop-up channel system which Was the second thing what happens when you are doing API calls, right? So you have to like now decide on what your strategy has to be for it, right? So what was initially happening? So what was initially happening was? What was initially happening was? This is the client which made the action Then the retail to the server So it's a response. It sends a positive response This then sends data to the live server, which is like separate entity in itself Which then tells all the other clients subscribe to the lights up, right? Now what happens if an API call interaction happens over here, which means This action lot which means none of these clients will be updated so The next logical way of like doing it is something similar to this very Action is like one direction goes to serve now serve as the one which actually Sends the data to the live server The back end the back side of the life server, which then Decimates the data across all its clients So the advantage of this is whenever there's an API action happening this action like still continue Which means your clients would be afraid Now deciding on which architecture works best for you is one more Critical there's one more schematic that you can consider wherein All these are like bi-directional and the live server is the one which communicates the server so the live server acts like a kind of proxy which then channels on the day a transmission to The server especially if you're writing chat applications, right? That's like awesome because Data gets transferred and then it gets locked on your login Right so This is a second missing and what is the final thing? How about having to need to authenticate? Okay? I The stock was like meant to be a real-time talk So I've reduced amount of content I was flying through on like socket.io So socket.io has like this method by which you can like Send events which are like not which are specific messages pertaining to a particular topic So you can actually write an event which does authentication handling So as soon as I open a connection, I send an event saying authenticate me against my back-end server So when that is done then they carry me to the channel So Yeah So the first question is you're assuming that all of these things are user events. Yeah, so there is a system event Let's say a timer or let's say, you know, a com job. Yeah Your workflow So in that you would you would have a user even triggered directly from the server and yeah, so that schema will work Yeah All right Deploy scale and much much more Okay, these are the really really really big problems that you will be facing because until now everything will be like cakewalk You have a really nice working system on your sandbox. The second you're talking about deploys You have to think enterprise think what your customers will be facing Running the light running the lights are all on a different port is not a great idea at all Reason there are lots of companies out there which have blocked every other port but for port 80 and for what? So if I'm running a running it on 8080 running my lights over on 8080 My life so actions will not take place at all If you have an architecture which was like that the previous one then your entire system brings right? So you need to figure out if you are figure out a way to like write a feel safe So you say you shouldn't run it on the different port that means you'll need a web server that's web socket compatible Yeah, so I'm getting to it. So what has what has happened is? I mean I can run it on a different board if my customers do not feel the pinch But if my customers feel the pinch then I need to figure out a way to like put a proxy or use a user server Which can like understand it's rocket connections and think I got all the any web servers out there that can understand a web socket connection engine X has this has this engine X cannot Technically what happens is I'm going to use engine X as like a proxy server Which is everyone's I mean everyone who's using socket I have lost in there, but it also has the problem of How it connects it talks to its client side the client-facing side on HTTP 1.1 Whereas talks to its back end to the server that actually does the web socket or but that does real time on HTTP 1.0 Which technically means you can't? You can't use the HTTP The WebSocket protocol itself violates HTTP 1.1. It's not compatible with the 1.1 Yeah, no, it's so initially one of the engine X doesn't support WebSockets So yeah, so what are the options available? So anyone wants to build an application what web servers do? Okay What I do is okay scale So what I found as a big good strategy this is like personal and is what I have been doing I use half proxy and what I do is Before that if you're doing HTTPS connections as well, I have a HTTPS terminal point So like something extra start all What's that other thing called? Okay, yeah Yeah, so Basically have an endpoint for HTTPS connections, which is like the encrypted and put it to another port So what happens if I get a call on 443, which is like HTTPS. I forward it to 8443 Or if I get a call to 18 just transfer it how proxy is a proxy server a load balancer Which listens on 8443 and 8443 and 80 and I basically say if I can like do like you are in between saying if I'm getting a call on the socket IO socket IO URLs then pass it to the socket IO server or pass it to my main web app server So the half proxy is like basically a load balancer which will say hey, is this connection a WebSocket or is this connection a real-time server connection or is it like the same based on the URL So I have a unique URL for my WebSocket Calls, so I will call my real-time call So I'll say anything that goes to that when I go to go forward to the real-time server It's come over to my web app server and I think you know engine X. There is an official patch for you The the TCP Again, it violates H2 and when yeah, it's never get it's never gonna get accepted officially So the authentication will happen two different times if you don't use this cross So these are all in the back-end back-end There's a back-end server And then you have a live server So I will do the authentication first Back-end server So when I go to the live server Again, yeah, it's since it's the same port and you're using the same this thing, right? Using the same your domains. There's no cross-domain calls. Let's happen So if you're if you're talking about sessions, okay again sessions, right? It's a very tricky thing because some Some some of the transport connections have the habit of like sending your session cookies there some of them So Authentication it's actually subject to based on what you're actually doing Authentication I wrote Yeah Over there what I would ideally do is do a Put a channel based system over there and say Authenticate me against my back-end so the lights are all like authenticate me against the back-end and then let's say, okay I'm I accept it or not. So there's a call back happening over there Yeah, any other questions? Any other questions? 10 So Add on to that so the stock it's was a mature for a while and it finally got The spec got production ready only two months ago and there are multiple drafts of the proposal. Can you talk more about it? Yeah, so there have been like quite a bit of drafts and all having like weird games. But what happened was they want to finally an RFC which got accepted like two months ago. But until then every browser, the new browsers love the idea of WebSocket and jumped into it. So whichever spec seemed advanced enough at that point was implemented. So Chrome was on a different spec and these specs are basically not APIs but internally how the action happens, right? I mean how the TCP connection takes place or how the HTTP connection takes place. So a quick question to add on to that. Most of the specs are not intercompatible. So if you're writing an application that works on certain spec it doesn't work on the other one. So how do you ensure that your code continues to work everywhere? I mean this is a big deal and node knockout happened. Everybody was using Socket.io. Chrome released a new version with the newest draft and Socket.io broke. All the WebSocket applications broke. So how do you ensure that these things don't happen? So okay, you can't really ensure because you're in a very nascent stage and you don't know what new drafts are. My question is what can you do about it? Try to use the standard APIs provided exposed by your native client which will not change unless the draft changes. So the on message and on connect and things have not changed for WebSocket. Though internally how it works has changed. So if you're writing back in servers you need to be worried because that's where the connection handshakes and things have to be taken care of. Let's say when the draft updates the way the handshake happens changes. You're also writing code for the server side and your code is still not ready for that kind of handshake. So is there a way you can say this is not compatible and you can probably send the HTTP normal response saying please switch to a fallback. Yeah, there is probably, yeah, you could probably implement a fallback. I mean seeing if there's a connection problem. I'm pretty sure most of the browsers will also raise their defecation money. Chrome does for us. Any other questions? Yes. Thank you.