 Thank you very much for coming. It's a pleasure to see all those new and familiar faces here in this room Have you enjoyed the conference so far? Yeah, I did too. Good. All right I have a first question to you You've probably heard of a saying like if all you have is a hammer everything looks like a nail You certainly did. Well, it's not just a saying It's actually something formulated as the law of the instrument by the American philosopher Abraham Kaplan But not the Kaplan most the jungle author has nothing to do no different thing. Yeah Well, anyway, what does it have to do with today's talk thing is that I believe that this saying it perfectly illustrates the way We work with the web today and the way we are using HTTP We're a bit childish by using HTTP because it's our hammer whatever task we have HTTP do it do it Please but there is more than HTTP on the web So it should be was not designed to do the tasks that we often force it to do the protocols itself the HTTP It's just centered around the request and response. That's it. There is no progress reporting There is no multiple Requests or responses for requests anything like that if you need something you can build an abstraction of top of course But at the end even if you build like the pseudo acing communication with HTTP It still does not change the way the underlying HTTP protocol works It's still synchronous and it's still centered around the request and response cycle. So again, the idea is that simple in the good old Times there was just a request to the back end. We fetched the page. We displayed it. That's it easy Well, then the web evolved of course it became smarter so that we needed the application server It also became a beautiful. So we needed the CSS images fonts files And then it's the picture changed more or less like this So we still have our browser the client it makes requests to the web server to get stuff more stuff now and even more stuff But it still fits in the paradigm still fits into the way the HTTP is supposed to work just more requests But that's okay The first time I noticed I remember that something goes wrong here is when I had to deal with the icons Do you remember a good old times of the icon sprites? like this It was the obvious problem like hmm. We have too many icons that means too many requests HTTP is not handling that well What can we do? Oh, let's pack all of the icons into one image and just offset it To the left and to the right genius. Well, this is something that I mean by the web abuse and using the HTTP Not in the way it is designed to be used. It has nothing to do with web sockets, but the story is going Then async requests, so the problem was fixed by introducing Ajax when we thought like, okay We need some pre-autical updates of our content without reloading the whole page and then we got Ajax But at the end it's good However, Ajax does not change anything for the back end Ajax is a pure client-side technology for the back end It looks totally the same way and it's again the very same HTTP Moreover, if you take a look on how exactly the paradigm how exactly Ajax update works Like we wanted to get something like a dialogue between the client and the server. What's the dialogue? Well dialogue is like when two parties exchange their opinions. They're equally involved. They are respecting each other This is a dialogue, but how our dialogue between the browser and the back-end look it's more like this Because at the end we are dictators the client is a dictators the servers are not allowed to speak Only when we ask so it is kind of a funny way of doing dialogue in my opinion and So although Ajax solves this problem partially meaning that we can just periodically ask the back-end about the updates And it's a pseudo dialogue. It's still ugly so Yeah, as I already explained we have a couple of problems we have First problem is that the dialogue is not really a dialogue It's a pseudo dialogue and the second is that you still need a lot of requests and the more frequent updates You want the more requests you do and this obviously does not scale well Moreover, you are still using HTTP on the On the background HTTP has quite a high noise to the signal ratio Meaning that you send all of the headers all of the cookies everything just to get a response from the back-end Nothing you happened That's not cool. And then we come to the long polling. Well, this is already something. This is already some Progress, let's say we open the connection. We keep the connection alive Connection is just idling idling idling and whenever something new happens on the back-end we push it through Well, that's great. HTTP overhead is still in place, but at least it's not periodical as Ajax It's waiting for stuff idling and in my opinion. Well it's of course good because You get things asynchronously and it's even better because Long polling is kind of romantic because if you think of it It's like looking in someone's eyes when no words are needed. You just wait and wait and wait and Then and then he or she replies something to you The problem is I don't think that's my level of relationship is already there on the web I don't want it enough. Please Every time you use long polling a guy from Boston Dynamics kicks the robot Now finally enough of this nonsense There is just one way to do the real-time bidirectional communication between the client and the server and that is web sockets Nothing else forget socket IO forget this libraries that are built on top of usually long polling and in the worst case Ajax They are outdated. There is totally no reason not to use web sockets these days As the developers we can finally benefit from from web sockets because We have no longer a problem of the HTTP overhead We have no longer problem of the real full duplex connections Meaning both parties can start talking to each other as a normal dialogue and Finally the interface is really easy from the client as well as from the server I'll show you in a moment a couple of code Pieces and as well as a demo But first just web sockets in a glance so another cool advantage is that the web sockets they are not HTTP But they are compatible with HTTP meaning that they run on ports Used by HTTP 80 and 443 So all of the firewalls will work all of the proxies will probably just let it through So basically you do not need any new setup in your infrastructure. You can just use engine X or whatever reverse proxy you use It should just work then How exactly we we we jump from the HTTP to web sockets protocol We start normally as we always did with HTTP We do the the handshake we establish a connection and then our client Says to the server that hey I want to upgrade to the web sockets protocol And if the server supports it it says yeah do it then they establish this connection the full duplex TCP connection They do not communicate over that connection with HTTP now It's pure web socket connection meaning that HTTP headers do not go through it And this is cool because we're not sending HTTP overhead anymore to the client every time All right Let's go for the use cases so obviously It's stupid to say just use web sockets for everything because there are good sides and bad sides So the good cases for web sockets are any cases when you need to implement kind of a multiplayer behavior It's obviously games. It's also tracking system when you have multiple objects Let's say moving on the map and you need to update their locations in the real time This is like typical scenario for web sockets also the collaborative editing Google Docs when you have again multiple Cursors right in text at the same time. That's exactly the case. However As I said, they're also bad cases to implement web sockets first of all because you are with losing HG Losing the HTTP overhead. You're also losing the benefits of HTTP and that is caching that are the standard HTTP responses like 404 400 500 and so on most of our JavaScript Clients these days see automatically reacts to the problems to the error codes of HTTP Like if you return 500 so that your web framework will know that it's a server problem 400 It's a client problem. Well on web sockets We don't have an overhead meaning we don't have status codes Well, all that you get is just a message a pure message and then it's up to you to handle it So if you want to say there was an error You cannot send the status code because there are no status codes You have to somehow encode it yourself and then on the client parse it yourself and see. Oh, this was an error So remember this Then in HTTP, we know that get requests are idempotent meaning that you can repeat it as much as you want in web sockets You cannot say it again is just sending a message. There are no get and post in web sockets It's just sending a message So it's up to you to decide if you want to build it in idempotent fashion on the back end or not And the client also has nothing to do with it now Let's see a little example as I mentioned already web sockets are really really easy. So to prove it Here is the vanilla JS example of what do you need to do to establish the connection with the back end? Can you see it? You can oh, that's that's great. That's already something. I Don't have the mouse here, but all right. I'll just comment it like this So as you see we're just not using any sort of libraries It's a pure JavaScript. You open the debugger in Chrome and that's what you need to type So you are creating first the web socket connection to that host in this case local host and then you define three callbacks What to do on open when the connection is established what to do when you get the message in this case I'm just depending it to document body and what to do on error obviously nothing. I who cares of that? these are Ten lines that you need to write to use web sockets So it's really really easy now It would be of course boring if I wouldn't come up with a demo I thought like I want to get some feedback about this talk and the best feedback for a speaker is obviously throwing tomatoes on him so I Really like this shirt. So please don't do it right now, but you can do it on the web So if you just go to all this is the wrong URL You go to I'll just do it with you Go to demo dot casted as dot me Slash you're a python You don't have to do it. But if you have a laptop anyway, you can just do it then you learn how to How to use web sockets I here I have a little code snippet. I'll just zoom in for you Didn't make it much better. Anyway, you'll get the idea. So if you copy this Into the debugger Yeah, I saw that someone already did it. You are throwing tomatoes on the speaker Well, you might think that this guy is actually not so bad like I do not want to throw tomato on him I better throw a candy. You can do that too then instead of tomato over there You're right candy. Oh Somebody throw an egg on me. Oh, that's bad. All right. Well, anyway, have fun Have fun with it What is demo shows is that when all of you are throwing tomatoes on me? I like tomatoes. That's fine when when you're doing it One person throws it and everyone sees it everywhere because on the background what you do is you sent? Oh my god Could you please send some candies to or cats you can send cats by the way? My god. Yeah, so you see it's updated in the real time One person sends everyone receives it and if you like reload. Oh, this is sweet. If you reload the page Then you get it all at once It's just the web socket is pushing through everything that it received by now And this is just that three lines four lines over there and you can what you can see the source codes There are no libraries involved at all. It's just one HTML page with JavaScript inlined Super easy super cool. I want to say to you that there is no barrier in not using web socket these days Now back to the presentation and you can have fun meanwhile. Let's let's see at the end Let's let's see at the end. What's there? I'm really interested now. Okay Now we still have time to see how much time do we have 15 great. So now we obviously want to see it's a Python conference. How can you use it from the back-end side? So we have a several frameworks that can do it and the easiest one is tornado. Well, in my opinion tornado is kind of a flask, but the async way You all know that flask is super minimalistic, but tornado is also minimalistic You can have just one pie file and this is actually all that you need this 26 line 26 lines to run the web server with web sockets and you have here already the handler implemented This is literally all you need to do pip install tornado that you have it running now Let's just have a few if you comment on what exactly does it do It's very very much similar to what we do on the client side. We define three callbacks on open on message and on close What what should we do and when you receive a message? Obviously or the on message callback is triggered and in this example. I'm just sending it back I do sell dot write message. Hello, and this just sends back. Hello and whatever you received at the beginning That easy, of course, it's not so easy if we want to throw tomatoes on the speaker It's a bit more difficult because you want some place to store all of the thrown objects And then you want to send it not just to one client You want to send it to all clients meaning the broadcasting But for this you can just use plain Python tools just append everything to the list And then when the new client connect it right on that list and send it back. So There is no magic. It's just normal Python data structures in this case I implemented it super simple on purpose like you do not need any kind of read me file for this super easy But if you want more complex setup because it's still minimalistic now you can take a look on Django Django channels It's very different because Django in the first place is a synchronous web framework So you cannot run web sockets on Django out of the box because it just does not work by design What they did it was a good idea They created a synchronous server next to the synchronous server So actually when you send the web socket data in Django, you're not sending it through the main web server You're sending it on kind of a alternative one which is a synchronous which supports the thing and then they integrate So please understand that Django channels has little to do with Django They tried to write it in the similar way and they succeeded But it's still two different libraries working in totally different ways They are somehow integrated and the tool set is really cool and really huge It's nothing compared to tornado because it has all of the broadcasting features the sessions the users Tornado doesn't have it you have to implement it yourself. So like in Django channels It's relatively easy to say To map the user to the web socket connection if you want if you want to split your users by group Like only this group will receive this message and Django channels. It's easy in tornado You have to do it yourself even though it's also easy, but you have to do it Okay, now let's go to the next one the bonus one the web sockets package called web sockets This is how it looks. This is really the most minimalistic thing I have found so that you have just one function one handler that Is handling your web socket connections and here you can use the async a your library with async await syntax if you like So I think it's quite self-explanatory. I tried to build up this example very minimalistic again You do the await web socket receive meaning that you Idol in that moment until the data arrives when it arrives It's written to the name variable then you formulate the string that you want to send back And then you again do the await web socket dot send sending it Synchronously and that's it and that three lines on the bottom are just running the I think a your I'll loop quite standard stuff I would say and you can integrate those because tornado runs on I think not out of the box, but it supports the sink a your I'll loop so you can run both I don't know why would you need it? But people ask these questions if I can integrate this you can Alright, so this looks already like some dialogue to me if you use web sockets I Noticed your reaction to the guy kicking the robots from Boston Dynamics I see that you're also concerned about this topic. So I think at the end of the presentation It's important to show you that there is a petition Stop robot abuse and the best thing are the comments there So feel free to sign it. I think it's outdated, but it's hilarious. I had to add it there now the commercial time Sales time I run a python agency if you have projects or you're interested in doing a project with me, please contact me Let's see how many tomatoes are on me by now lots of cats. Well, this is nice. Let's like a paradise cat paradise The funny thing is that I was really in a rush for this demo. So I have no way to flush it now I need to redeploy the whole thing But I think I will not because it's really cute, isn't it? Okay Yeah, then last thing The credits there are really cool Articles online about web sockets and about using them with Python also the videos and that's it. Thank you very much Okay, and you want a question please stand up and come here you send that It's over the HTTP the web socket You start with it. Yes start with it. So can we have all the it's a get I think It's a get to request at first and can we have all the parameters there like a get a get parameter get parameters just to know what to send What to do with it with this web socket? Yeah, thanks for the question So, yes, you start with HTTP because you never know if the back end supports the web socket you start with You are connecting as if you are connecting HTTP But you only do it not to send the data You only do it to ask if we can upgrade to the web socket connection And if you can there are no get requests. There are no parameters Nothing So if if the server and the client both support web sockets protocol as soon as the connection will be established You totally forget about HTTP So no you cannot get parameters and you do not have statuses and you do not have Request types like get post boot that doesn't exist HTTP is really used just as a transport at the first phase to establish the connection and that's it and it is done that way in order to be Compatible with firewalls reverse proxies and so on. So the protocols are very different. They have Not so much similar because the web socket was developed in order to maximally decrease the overheads of Sending messages back and forth basically in web sockets everything you send almost everything is a message There are a few frames at the beginning of the data frame indicating the order so that the back ends can then Combine this web socket message pieces into one big message and that's it. That's all the metadata that is sent. So No parameters Thanks more questions How practical web sockets For Yeah, so how practical our web sockets in Python Of course Well, first of all most of the things that as I mentioned that in the use cases of Collaborative editing multiplayer games and tracking systems are already on web sockets like Google Docs So it's quite a big project I would say it's not in Python. Unfortunately, but It's basically the only way that you can do the reliable full duplex communication these days between the client and the server So it's not like you have much of a choice. You can use Ajax. Yes But if you have imagined like this room right now Sending these cats with Ajax. I mean my poor server would just die From that and since you use in context of Python I can mention again that it's a spatial while playing in Python because you have a sink await syntax So it's really cool. You don't have to do the callback spaghetti as you have in in JavaScript You can use a sink. I always a sink await syntax And it even looks nice and you do not see much of a difference with a normal Request handler like you have in flask or tornado or Django. You just put a wait. That's perfect. Any more questions? I am using web sockets for a trading application and it's the bandwidth is it's using is about maybe one or two megabits per second not megabytes and I find that the library I use is Consuming up to like 25% CPU just to pass messages. What library do you use? I think it's WebSocket dash clients and it's something built on top of it But do you find that is normal or is it way too much? I have to be honest I never used the WebSockets library because that's all you need to write the WebSockets connection This is ten lines or something. So I know that in the old days When WebSockets have been just introduced you had a lot of browser introduced an internet explorer that did not support it Then you had to use something like socket IO that would fall back to long polling and if that doesn't work it would fall back to Ajax requests. Yes, but these days are gone. That's it. All of the browsers including IE I think since Even I have to say it's a command line client in Britain in Python has got nothing to do with the JavaScript world Python clients Okay, which name again? It's WebSocket dash clients. I wonder if you could be able to advise, you know efficient CPUs WebSocket libraries. I Mean that you can just use the standard they sync IO with the WebSockets library That's what I was using when I was experimenting in production. I use tornado always for WebSockets because it has other things that the web browser that the web server needs like templates Sessions and so on but if you just need pure WebSockets, then the WebSockets library is okay I never seen any CPU or memory issues with it to be honest It is just a fluke with the library. Yeah, it could be that the libraries are outdated But at the end if you're using WebSockets with a sync IO Something that would cause you a lot and your resources would be a sync IO and it's optimized quite well now So I don't think that you will encounter any problem with that Yes, sure rest API's are using the The HTTP so with that you automatically when you're writing the rest client You can first of all rely on the status codes as I said that if you do any request and it returns you any now Any number in the status that begins with for you can understand that you are doing something wrong with your requests It would be probably parameters. You forgot something in your parameters. Oh, you didn't authenticate. That's another status code actually, but rest fully pi's are not always implementing it. So like Just having Default responses can already give you some hints on what you're doing wrong and what you're doing right Like if you get response to hundred status means everything is perfect on WebSockets. You don't have it So let's say you receive a WebSocket message. Okay That's probably good, but the fact is that you do not even Need to receive any message because when you send the WebSockets a message to the back end There is no response by default Only if the server wants to send you something back You will know if it even worked or not like here You just send cats to me and the only way you know that it's there is by seeing it on the page Meaning that the whole loop worked in the restful API's you would see in the shell over there on the right red Red signs like you know when when something on the HTTP goes wrong The debugger tells you automatically like on this line in this file or in this connection something is bad In WebSockets, you don't have it. You have to debug everything by yourself You have to understand everything by yourself the browser knows nothing about your communication And that's the first and I think the biggest difference and difficulties in building API's In using WebSockets and using restful approach and secondly It's just hard to compare it because that's to do total different partings I'm just compared now from the technical side like exactly the protocol and implementation But in general like you can also think On the WebSockets when you reconnected to this page like did the page reload What I have to do here is send one message for each object over there in The restful API you would usually send them all at once like one big thing And the big difference is that you could cash it with restful API's here You can't so it's kind of different approaches the WebSockets are really tailored to be one by one communication So I'm sending everything to everyone. I cannot cash it That's another thing. Yeah, I mean we can discuss it for a really long time because restful and WebSockets are two different sites At this point, but I think that these are two main differences as of a technical protocol perspective Welcome One more question Is it does WebSockets can be based on the path of the server? It is yes. So to connect to WebSockets. This is the path that I'm using right now WS is normal WebSockets WSS is the secure WebSockets kind of the HTTPS for WebSockets And yes, you can have different passes here And this would map in your application server to different handlers or endpoints that will be handling that What's the behavior of WebSockets when When the client is roaming In a mobile for example, I'm changing from one Losing the connection You don't have it So again in HTTPS requests if you didn't get requests and something is wrong with connection Since get is always adempotent the browser knows that it can just repeat it and do it again again until it gets something in WebSockets You don't and there is no success message or failure message. So you sent it network gun You don't know if it was delivered or not It's TCP so on the protocol level you do know but you do not know if it was complete if it was successful and so on So this is yeah, it's a big difference. You don't have this you have to take care of it by yourself Yes, yes, but you have to implement it you have to implement it yourself, okay one more So can you do query parameters No, you can't that's a quick one What's the point of using async if you don't get a response at all So where is the was the async actually mattering? Well, thank you, yeah Thanks. Yeah. Well, there are many cases of using WebSockets like first of all on the on the if we if you ask me about the async First of all think on the on the back end on the back end side. It's fully async You do not have an overhead of keeping the connection open as you have in WebSockets in sorry in long polling The protocol is tailored that way that you have minimal overhead of multiple connections So with just minimal AWS machine You can easily solve the 10k connection problem It costs back and nothing and you can use a single-threaded server like tornado or Node.js to handle them And you can use a fancy async await syntax on Python. So even if you are not using If you're not using it in a request response fashion, which you actually shouldn't do because it's totally up to you You can just receive messages. You do not have to send something back if it's let's say a tracking application You just want to get the positions of your items somewhere. You're just collecting them You're not sending anything back, but the way you're collecting them Are a synchronous in a sense that the connection is open You do not do anything with that connection the data comes through and only when it comes through your code is triggered Just as you have on the HTTP connections as well if using the async or your similar thing But without the HTTP overhead Okay, I think it's twice off now Okay, coffee break. Okay. You took it right. Yeah, ask me on the coffee break If you have more questions, thank you very much