[MUSIC] 0:00 [SOUND] Thank you. 0:10 Okay. 0:10 Cool. 0:11 Okay, yeah, so I've chose the catchy title 0:13 of Choosing Your Real Time Web App Tech Stack. 0:17 So what I want to do is convince you that Real Time's awesome. 0:23 And then go about talking about how you should 0:26 look at the technologies and the decisions you should make 0:30 in choosing which Real Time web technology that you 0:32 will definitely be using in your current or next project. 0:34 So, yeah, I'm Phil Leggetter. 0:38 I've got this silly title of Developer Evangelist. 0:40 I've worked for a couple of systems. 0:43 I've worked for about three times now, 0:45 about four times now, if you count contracting. 0:47 yeah, [INAUDIBLE] is a, a developer tool kit and light 0:49 rate JavaScript framework for building large complex front end JavaScript taps. 0:53 So [INAUDIBLE] builds web trading frameworks 0:58 for, that they license to banks. 1:01 So we're open sourcing some of the tool kit behind that. 1:03 And previously, I worked for Pusher. 1:06 Who areuh, a Real Time web hosted service. 1:07 So, again, I hope that, that and the ten year's 1:11 experience will, will mean that these talks of interesting and useful. 1:13 So this is obviously future of web apps by 1:16 Future Insights so the focus should be on the future. 1:18 But let's try and understand a little bit 1:22 about the history of the technology before that. 1:23 So web communication apparently the first documented version of http was in 1991. 1:26 makes me feel old cuz I was around then but probably not using the internet. 1:34 I don't think many of us were. 1:39 So that was basically in 83 as a request response protocol. 1:41 It let's us request data a connection's open, 1:44 we get the data back, the connection's closed. 1:47 It's delivered generally from a client, a request made from a client to a server. 1:49 But for Real Time web communication we want two 1:54 end points or two clients or two devices to be 1:57 connected so that soon um,as say one of them has 2:01 new information it can instantly be pushed to the other. 2:05 So with ACTP we don't get that out of the box initially. 2:07 So in 1996 we had Java applets which meant in Netscape we could embed a Java applet 2:12 and we can communicate with JavaScript from the 2:16 applet using life connect plug in to JavaScript communication. 2:19 But, I mean so that was great and we can make 2:23 a persistent connection from the client, the web browser to the server. 2:26 When the server had new information it could push it to the client. 2:29 But there were loads of problems with Java applets. 2:31 We had legal battles between [INAUDIBLE] and Microsoft for the JBM. 2:34 We had really flaky Sun JVM problems. 2:39 And also, none of us liked plugins. 2:44 So we obviously went to move away from that. 2:46 So people who wanted this functionality ultimately hacked around it. 2:48 So around 2000 we had something called HTTP 2:51 Server Push, which meant that we used http, we 2:53 could create a connection from the client to 2:56 the server, and hold that open in some way. 2:58 So when the server had new information It could be pushed to the client. 3:00 So back as early as 2000, we had Real Time web technology. 3:04 We had the ability to do this sort of stuff. 3:07 But the only people using it were generally financial 3:09 companies. 3:13 So it wasn't until 2009 that it's really gone 3:14 mainstream, and I think that's for a few reasons. 3:16 Firstly, we're seeing that technology used within platforms that 3:18 we use all the time and the benefits from it. 3:21 But also marketing has got hold of it. 3:23 I think they think its all bad. 3:25 So, Robert Scoble back in 2009 wrote a blog post 3:28 saying is the Real Time web a threat to Google? 3:31 And what he meant by that was that. 3:34 He was using something called Friend Feed at the time. 3:36 Which is a social network aggregatEable also a social network in itself. 3:39 And he really liked the way that you can 3:42 publish information and as soon as the information was published 3:44 other people could search for you know matching terms and 3:47 find that data and have it returned to them instantaneously. 3:50 Now if you think about 2009, we would 3:53 publish a blog article or um,you know a new 3:55 website and wait for days for Google to 3:58 spider our site and make it accessible through search. 4:00 So this Friend Feed and, and then Twitter search were the first kind 4:03 of instances where at scale, we could 4:07 see content that was published instantly discoverable. 4:09 so, we've got instant discoverability of data. 4:15 Now back in 2009 if you went to Wikipedia 4:19 and searched for Real Time web there wasn't a definition. 4:22 I'm not boring that I wrote a book post on the 4:24 fact that there wasn't a definition of, of it in the Wikipedia. 4:26 I don't know why I didn't just write a definition. 4:29 So it says the Real Time web is a set of technologies and practices that enable 4:32 users to receive information as soon as it is published by it's authors in this case. 4:36 It could be systems, it could be users. 4:41 So that's a change just from the 4:43 instant discoverability of data is the instant delivery 4:45 of data to a, you know, to the 4:47 people that are interested in receiving that information. 4:49 So we've got instant delivery of data, and the one of the, one of the reasons why 4:54 it was then possible, and there was use 4:57 cases of this technology, is the thing that's offscreen. 4:58 Things like a Follow button. 5:02 So the applications we're now aware of the 5:03 pieces of information that you are really interested in. 5:05 You would follow people on Twitter. 5:07 So as soon as they tweeted that information could be delivered to you. 5:10 You would friend, friend people on Facebook. 5:12 So as soon as they post an update it can be delivered to you. 5:15 If you look at things like Google Plus, you have people to circle. 5:18 So you're interested in their information. 5:20 So, as soon as they publish something, it can be pushed to you. 5:22 So, a lot of people say this technology isn't Real Time. 5:28 Now you're not gonna use it to control a 5:32 nuclear power, power station safety system or control the brakes 5:34 on your car but you will get a delivery of, 5:38 of that message over the internet in around 300 milliseconds. 5:41 Probably less than a 100 milliseconds. 5:44 But it really depends on the network. 5:47 But in terms of usage, that's generally fine within applications. 5:48 Certainly in these cases, that we're seeing at the minute. 5:53 One thing I would say though, is that 5:57 the timely delivery of that data is really important. 5:58 So you need to think about data's generated. 6:01 Some event occurs and, and a payload of data is generated. 6:04 That needs to be delivered to the people of the 6:07 system that's interested in receiving that data within a timely fashion. 6:08 So, if I were to stand ten hours, slap myself in the face. 6:12 You guys would go, this guy is a loon. 6:16 And then if I just continued talking and five slides later, 6:17 I went ow, you'd go, it was weird when he slapped himself. 6:20 Now he's just shouting it out five slides, five slides later. 6:24 That doesn't mean anything. 6:27 There's no, there's no context. 6:28 You've lost, you've lost the context. 6:29 You've lost the relevancy, but if I slap myself and 6:30 say ow, it's still weird, but it's not quite as bad. 6:33 So it's really all about maintaining that context. 6:37 Maintaining that relevancy. 6:39 And obviously with Real Time technology the fast, 6:40 the fact that you can instantly deliver information. 6:43 To use it in systems within a 6:45 timely manner, it means you maintain that context. 6:47 So that's the opportunity with this technology. 6:50 So let's look at the benefits and use cases of Real Time. 6:53 The fact that we are pushing information 6:58 as soon as it becomes available is convenient. 6:59 We've probably all seen that in, in the apps that we 7:03 use but [LAUGH] a really silly and simple example is phone calls. 7:05 Because you people are, are, are a phone number 7:08 and it would be a nightmare if we had to 7:11 open our phone, open up the phone application and press 7:13 a button to see if we had an incoming calls. 7:15 The fact that, that the network maintains a connection to your phone And 7:18 when people phone your number it rings your phone is a form of Push. 7:22 And we've seen that in all sorts of different 7:25 other ways in terms of SMS and push notifications. 7:27 So this obviously isn't. 7:29 These aren't Real Time web applications, this is just 7:30 proving that Push is a convenience and there's a benefit. 7:33 So if you take that to the web ITV News had A 7:36 site update around a year ago by a company called Made By 7:41 Minnie and all they did really simply was change the site to 7:44 look more like an activity stream say it's a live news stream. 7:48 And from that CMS when they publish new content they 7:52 deliver that content to the web browser to the thousands of 7:55 people that are on that site ,and say there's three 7:58 new updates available you click that and the content slides in. 8:00 Now that doesn't seem particularly interesting, But within 8:03 six months of doing that they've ten fold 8:06 increase of traffic on their site because it 8:08 became known as a source for Real Time use. 8:10 This was developed for Manchester City by [UNKNOWN] a digital agency in London. 8:15 I think its championship manager or football 8:22 manager so I love it straight away. 8:24 But it's basically, it feels to me like a second screen 8:27 experience that you get lots of Real Time information related on the 8:29 game you're watching maybe on the TV or maybe you're not even 8:32 on, it's just useful TV information as soon as it is available. 8:35 So I think examples like these where there's lots of 8:39 data available so obviously sports are really good one where 8:41 you can get Real Time content that either compliments the 8:44 thing that you're watching anyway, or or is just generally useful. 8:47 Thinking of things like in how many of us out there watch a 8:51 TV program or watch a movie and actually then jump onto IMDB and go 8:54 what was that guy, and what was she in, and wouldn't it be cool 8:57 if you could have a synchronized view of IMDB based on what you're watching. 9:01 So this sort of thing's, you know, possible. 9:05 So, this isn't probably the most exciting examples. 9:08 But I wanted to, to provide it. 9:11 Because I think it's quite interesting to 9:12 think through why Google offer Real Time analytics. 9:13 Is it just a marketing ploy? 9:18 I think that's part of it. 9:20 But I also thing there's actually a lot of value. 9:22 And when you publish some content online. 9:23 What reaction has it had? 9:26 You, it's nice to be able to see you know, the, 9:27 the reaction that's had, how people are arriving at your site. 9:29 What keywords have they arrived at your site from? 9:31 Where are the sources? 9:33 And the real value, I think, in this, is the ability to 9:35 look at that and make instant decisions and react to those changes. 9:38 So if you see a bunch of people coming in from a destination you hadn't thought of. 9:41 You go and investigate that destination and go, oh they're interested in X. 9:45 Then you can actually update your site, and update your 9:48 content to take advantage of the fact that people come from 9:50 that destination, or they're coming from those different they're interested in 9:53 specific topics you hadn't thought about when you wrote that content. 9:56 You could also think about it. 10:00 I push a new side of production. 10:02 And all of a sudden I see my traffic massively drop. 10:04 You know, what's caused that. 10:07 That might be the trigger point for me to go and look at my production systems. 10:08 What's the CPU usage, what's the memory usage, what's 10:11 the disk space on all my, all my application servers? 10:14 Why has that happened? 10:16 And you can do that because Real Time information 10:18 has provided you with that opportunity along with [INAUDIBLE]. 10:20 So the speed of delivery of this data is giving you an opportunity. 10:25 So another really simple example is something like foursquare. 10:29 So I go to Starbucks, I check in. 10:32 One of my friends is nearby. 10:34 They see the check in, they get a notification, we catch up for coffee. 10:36 It's not particularly Groundbreaking. 10:39 But it's nice to meet with a friend, and have a coffee. 10:42 It could be that it's just someone I happen to be friends with. 10:44 But I've never actually met. 10:48 I meet someone I haven't met before, have a coffee. 10:49 Business opportunity comes out of it. 10:51 So simple use cases like that. 10:53 And this is a relatively old screen shot of Kathleen Trader. 10:56 One of the Examples we build on top of the framework that we've got. 10:59 So something like this has been around with Caplin for around when did I 11:05 start, in 2001 we had something called Web Sheet and it's turned into Caplin trader. 11:11 But it was always a focus on life content in terms of news. 11:15 Or activity streams you can count it as. 11:19 Data but not prices. 11:21 And it was just this display of data. 11:23 And obviously in finance having the information first means a lot. 11:26 It means you can, you know, get rid of your stocks and shares. 11:29 It means you can buy stocks and shares. 11:31 So in finance Real Time really matters. 11:34 So obviously it's not a surprise that the technology was used there first. 11:35 But what's quite interesting about this is the evolution of the product. 11:39 And the evolution of the use of the technology. 11:42 Because it's moved from just being, I mean 11:44 it's still just off of the Real Time content. 11:46 But now you click on these things, click 11:49 on these tiles and you start executing trades. 11:51 You start interacting with real trading systems. 11:54 You start interacting with traders and saying hey 11:56 can I get this price for this product. 11:59 So the value was moved from just being able to 12:01 see data in real to to be able to interact. 12:03 And I think this is the main thing with this technology I 12:07 think it's the ability to interact with systems or with other users. 12:09 And I think generally it's useful functionality, but also from 12:14 an application point of view it means that someone's engaged. 12:18 And using that application. 12:20 We use products like Twitter and Facebook, and some of us use Google plus. 12:22 But fundamentally, they're communication platforms. 12:27 Then, you don't post a tweet and hope that 12:30 nobody favorites it or retweets it or replies to you. 12:31 You post this. 12:34 Generally hoping that there's some reaction form that. 12:36 There some for some, some sort of interaction and engagement. 12:37 [NOISE] to [NOISE] whats wrong [NOISE]. 12:40 Okay, right, and that's all thanks to Real Time web 12:46 technologies that enable that and enable that Real Time communication. 12:50 So what are example of use of that technology. 12:55 chat. 12:58 [LAUGH] 12:59 It's not very interesting but I think if you're ever gonna use this technology, 13:01 the first thing you're gonna do is you're gonna try and build a chat application. 13:03 Because it is an interactive, Real Time experience. 13:06 And with this technology, you can easily add that functionality to any application. 13:10 You embed it as just part, part of your app now. 13:14 [SOUND] So collaboration. 13:16 I think this is the area that really needs a 13:20 lot of I think there's some good examples out there. 13:22 But I think there's more we can do. 13:24 So Google Docs is a really simple example that most of us have used. 13:26 If you think about editing a document in the past, you probably, if 13:30 you're unfortunate enough like me, you 13:34 maybe check out a document from SharePoint. 13:35 You set Track Changes. 13:38 You edit it. 13:39 You then save it. 13:40 You then check it back into SharePoint and that cycle will go on. 13:41 And if there where multiple people that needed 13:44 to access that document, it would be a nightmare. 13:46 So, the fact that we can get a document to a certain state and then and then 13:47 get everybody in to collaborate in Real Time instantly 13:53 saves a lot of time and effort and frustration. 13:55 Now taking that to a different use case Cloud 9 and there's 13:59 a bunch of different applications that offer the same sort of functionality. 14:02 Cloud 9 is an in-browser ID. 14:05 It lets you edit in Real Time with it used to be up to seven. 14:07 Maybe they've increased that now. 14:10 Of the developers that are writing code. 14:11 But not only just writing code. 14:13 They're then running the application, [INAUDIBLE] it together, chatting about 14:15 you know, what's going on in the application, and working together. 14:19 It's really really useful for, for remote teams. 14:22 But also actually useful for teams in the same office, 14:25 where you can only fit so many people around the monitor. 14:28 And then taking experiences that are collaborative but generally 14:32 require space and moving that into an online world. 14:35 So things like Mural.ly, which is you're building a mural, 14:37 your creating maybe a whiteboard, a great big wall of whiteboard. 14:40 But taking that online and letting people drop in notes and annotations and videos. 14:43 And building these rich interactive collaborative experiences. 14:49 So, so then the use cases. 14:52 Life content notifications, activity streams, chat collaboration and games. 14:55 I haven't gone into games, sorry. 14:59 So again I think it's about these. 15:03 So there's lots of value in live content still but I think, I 15:04 think you should be trying to 15:07 build interactive engaging experiences of this technology. 15:08 So what's the fundamentals in using it. 15:12 You obviously need to connect. 15:15 So you. 15:17 To, to get information from a source you need 15:17 to have established a connection to that source of data. 15:19 so. 15:23 I'm just gonna leave this here. 15:23 [LAUGH] I bet within loads of applications there's still a 15:26 set interval somewhere that's looping and making an [UNKNOWN] request 15:29 from the client to the server every ten seconds, every 15:33 five seconds, heaven forbid every two seconds, every one second. 15:34 Now that might be fine but the Real Time technology that's available 15:38 now is stable, it's easy to use, and it will definitely be 15:42 more efficient in terms of both resource usage, but also the amount 15:45 of code that's required in order to have that functionality within your app. 15:49 So I'd seriously consider moving that out and 15:53 looking at using a proper Real Time technology. 15:55 So another thing that I want to go away is something called comet. 15:59 Now comet is an umbrella term for all the hacks we had to go 16:04 through to get Real Time communication to 16:07 happen over, over http over older style http. 16:09 And you might of heard of http 16:14 long polling which is different from just polling. 16:16 And http streaming. 16:18 And all these things were implemented in different ways 16:19 in different browsers, and ultimately because of that, the hacks. 16:21 And a bit like the superstore we obviously want that to go away. 16:24 It went bust for those of you that don't know about comet. 16:28 So, the way it's gonna go away is because we have standards now. 16:32 We've got a couple of standards That are really useful. 16:35 They're not hacks because they're standardized. 16:37 Browsers implement them the same way. 16:39 and. 16:42 And also, because they're standards, it means it's not just tied to, to browsers. 16:42 It means we can have clients that aren't just browsers. 16:47 We can have server to server communication. 16:50 We can have an internet of things connected using these standards. 16:51 You've probably seen loads about doing, calling. 16:54 I'll be doing examples in a minute. 16:56 Loads of them use web sockets. 16:58 So, the two standards that we got are server-sent events and eventsource api. 17:01 That's just a push, it's a server to push solution over http. 17:05 But the solution I'm really excited about is web sockets, because 17:09 it's a single connection, it's bi-directional, 17:12 it's full duplex communication both ways. 17:14 Is a protocol and it's an API. 17:17 And I've got a really small [UNKNOWN] here to pick communication with Web RTC I 17:21 can't fit that into this talk, but that's obviously gonna be part of this as well. 17:25 So, but unfortunately, we still do need the hacks. 17:31 We ideally want to use web sockets, where possible. 17:33 But we might need to fall back to events source. 17:36 HTTP streaming, long polling, even polling heaven forbid. 17:39 So we still [UNKNOWN] and that stuff needs to be managed 17:41 within our application but it's managed within the solutions that we used. 17:45 So we talked about connectivity, what about the data. 17:50 And the client server interaction, ultimately the functionality 17:53 that you want to build into your application. 17:55 So I've broken this down into four things that I think kind of fit. 17:57 There's really simple functionality. 18:01 There just onMessage. 18:03 The server has new information, a blob of small, small piece of information. 18:03 It wants to send it to the client. 18:08 It's just an onMessage. 18:10 So I've taken this from, actually the web [UNKNOWN] has an onMessage. 18:11 But I can't point at this now and still speak in the mic. 18:15 So this is a suggest library. 18:18 We can create a connection. 18:21 We define an onMessage on our object connection, and then 18:23 we handle the, the callback, the, when we get data. 18:26 On the server, we do a bunch of stuff. 18:30 But ultimately, we've got the connection as being established. 18:32 We've got access to this connection that's been made. 18:35 We can just do connection.right. 18:37 So it's a really simple, single piece of data payload back and forward. 18:39 So that's fine, but as the complexity of your app increases, 18:43 and the complexity of the data, you need a better solution. 18:46 Now the, the number one solution at the 18:48 moment for Real Time web technology is Pubsub. 18:51 So we've talked about following people on Twitter. 18:53 We talked about being friends with them on Facebook Their subscriptions. 18:55 If we take another really silly but obvious example if we look at Google. 18:58 So if I go to Google right now and did a search 19:05 for aliens I would get a bunch of historical information about aliens. 19:07 And they would be relatively fresh cuz Google spies is really quickly now. 19:11 But if, there aren't many windows I'm stuck. 19:15 If I could hear a humming of spacecraft over the planet. 19:18 I could hear little green men running around maybe sticking to 19:21 the floor slightly then this information would be out of date. 19:24 And the most relevant information would be to me 19:28 now,who is interested in aliens, is that we're being invaded. 19:30 So Google really should be sending me new 19:33 updates saying that we've been invaded, there's aliens. 19:35 As soon as people stop and start taking 19:38 pictures of these aliens as they're attacking them, rather 19:40 than running away and posting them to social 19:42 networks, we should be getting that delivered to us. 19:45 Soon as the aliens invade digital space, I 19:49 want to see those aliens in my search results. 19:51 so, the point in this, although it's very silly, is to kind of go, this is 19:54 an obvious example where I've actually made a 19:57 subscription, I've not, I've not just done historical search. 19:59 It is a subscription, and I bet there are 20:03 example, examples within your applications, if you think about it, 20:04 if, if a user is on a certain URL, 20:07 they are potentially subscribing to content based on that page. 20:08 So, when new information is available, why not push it to them. 20:11 [BLANK_AUDIO] 20:13 Okay. 20:16 So here's an example, this uses the this, I use 20:18 to work for Pusher, so this uses the Pusher Client. 20:21 Here we create a new pusher object which is the connection to pusher in this case. 20:24 They use channels so channel identifies your subscription. 20:28 You might hear it called subjects or topics. 20:32 Here I am doing alien search which is just in my application I've decided that 20:34 I have prefix of search and whatever they are searching for is maybe a good start. 20:39 And Pusher is to have an abstraction above 20:43 just that subscription where you combine to specific events. 20:45 And that's really handy so here I've got. 20:48 I'm binding to new search results. 20:50 Oh, there I am. 20:52 Or when, when an update changes of when an update's deleted. 20:54 So you could think of that as COOD. 20:57 So crood without the R. 20:59 And you can see how you can expose those events happening within your application. 21:01 So as soon as new information becomes available to your 21:05 app, you can publish that to anybody that's interested, create my 21:07 data payload, and just do trigger, any in search, it's, in 21:09 this case, there's a real, it's updated, and here's the data. 21:13 And I get that update up here and update my UI accordingly. 21:16 And it should be as simple as that. 21:21 And these technologies do really make it simple as that. 21:22 So the next type of functionality is data synchronization. 21:25 I've got operational transforms in there because 21:29 you need to think about collisions of changes. 21:31 So what we normally mean with 21:33 data synchronization is there's a data structure. 21:34 I mean, say if we look at Google 21:37 Docs there's a data structure which represents that document. 21:39 How is that structure change reflected in anyone else who's viewing it. 21:42 So operational transforms are detecting those collisions 21:47 and making sure that synchronization works out. 21:49 So this one uses Firebase API. 21:52 And here we create new Firebase objects, so 21:54 that's a, that's a reference to our structure. 21:56 then. 22:00 In this case, I'm treating it as a collection. 22:01 So I'm gonna push on just some arbitrary data. 22:03 So I'm adding a new child in this case. 22:07 And I can also bind to certain events on that data switcher, 22:09 and say, so, when a new child's added, I wannna be informed. 22:12 When a child changes, so, some data changes 22:14 on a child, give, tell me about that. 22:17 And also when a child's removed. 22:19 So you can see how that kind of works. 22:20 You can also see how you might implement that in Pubsub, but this is a 22:21 very specific use case about data structures, and 22:24 it's probably an abstraction above the PubSub stuff. 22:26 Okay. 22:31 And the final one is um,remote method invocation. 22:31 Now some call it the cousin of remote procedure 22:36 call, the object torrented cousin of remote procedure call. 22:39 Ultimately your accessing an object and calling a function on it. 22:42 A function on it or a method on it over 22:44 the wire and that, that's kinda hidden away from you. 22:46 You can be making a call on a server you 22:48 happen to be interacting with a client object and vice versa. 22:50 Two solutions that I know so far that use this, and I 22:53 think, I'm sure there will be others A Signalr and d note. 22:56 So here's the Signalr example. 22:58 Here I can create a so obviously 23:01 the framework provides all this sort of functionality. 23:03 Here I extend something called hub. 23:06 I've got a chat hub 23:08 on the server. 23:11 Now on the client I can then access the chat hub by this call, connection.chathub. 23:11 On the server I'm exposing a send function. 23:18 Now on the client I can access that by chathub, down here. 23:22 So chat.server.send, and I'm executing this method. 23:24 And then the framework exposes functionality and let's me go to 23:28 clients to all so all clients are connected call their broadcast method. 23:31 And down here I got broadcast method and I'm getting the. 23:36 The name and message, so and this is all, 23:39 so basically the JavaScript object is created via the framework. 23:42 So you define yourself on the server. 23:46 Proxy objects create on the client and 23:48 you can just interact with us, really powerful. 23:50 Well I would say that it's hiding away the interactions 23:52 over the wire and potentially the data payloads you're sending. 23:55 So if you're using something like that be aware of, of that sort of stuff that 23:57 you might be making calls you don't realize, 24:01 end up in a network where it requests [INAUDIBLE]. 24:02 So finally, choosing your Real Time web stack. 24:05 Hopefully I've convinced you about Real Time web's awesome. 24:11 But you just use socket.io, right? 24:14 That's me, done. 24:16 So the reason I put that there is because 24:18 socket.io is an awesome framework, and it's, it's some 24:20 really, it's done wonders for people using Real Time 24:22 work technology and, and understanding the benefits of it. 24:24 But it isn't the only solution available. 24:27 And that's the key thing here, really. 24:28 And there's loads of different solutions available. 24:30 Don't make it the default. 24:32 Try and think about what you want your application to do 24:33 before you just dive into it and say I'm gonna use socket.io. 24:35 So use an existing solution. 24:37 There are loads of solutions available, and I'll show you some of them. 24:39 So you should use an existing solution. 24:43 Firstly because the connectivity stuff is still a pain. 24:46 Proxies get in the way of connections some browsers don't support 24:48 web socket so you need to fall back to different solutions. 24:52 Then there's the support that an existing solution will have. 24:56 If you license it, then you've got that support level. 24:58 If you, if it's a community based solution. 25:00 If it's an open source solution. 25:03 Then you can access that, and get 25:04 value from interacting with a community and contributing. 25:06 Maintenance is an interesting one. 25:09 It's not such a big deal now, I don't feel. 25:10 But obviously book fixes will be great, but things like when, 25:13 when the web socket protocol was in, in its infancy, and it 25:15 changed quite frequently, push a, were the fir, one of the 25:18 first companies to jump on that and offer that as a solution. 25:21 And they managed the fact that that spec was changing all the time and that 25:24 different browsers, different solutions implement different versions of 25:27 the spec, and they just dealt with that. 25:30 And that's one of the benefits of using, you know, an existing solution. 25:31 Features as well so web circuit protocol defines sub proto, let's 25:35 define some protocols that haven't been exposed yet it might be. 25:39 Things like web rtc handshaking the ability to, to 25:42 act as the proxy to say to put two 25:46 peers in touch with each other, that sort of 25:49 stuff might be baked into these frameworks, and scaling. 25:51 So some of these solutions have got 25:53 they've thought about scaling from the off. 25:57 So they've thought about how you do scale. 25:58 Fay, by a guy called James Coglin is a good example of 26:01 that where he's thought straight away about how you scale across multiple nodes. 26:03 And the guys at Signal are. 26:07 Microsoft solution are doing a really good job there as well. 26:08 So unfortunately, that doesn't make it that much 26:11 easier still because there are loads of solutions available. 26:13 So what else can you do to fill it back down. 26:16 First thing. 26:20 Really, really simple. 26:21 A bit like the sockeye node thing everyone wants to use nodes. 26:23 It's awesome but it might not be your technology of choice. 26:27 It might not suit the thing that you've got. 26:29 So there are other solutions available. 26:31 So choose a solution that potentially is written in a language that you're. 26:33 You know, you and your team are comfortable with. 26:37 And there are loads of solutions out there. 26:38 I'm going to share these slides afterwards so you 26:41 know it's quite useful as a reference hopefully as well 26:44 but one thing to point out is something like PHP 26:46 where there isn't a great solution available at the moment. 26:49 Especially if they built on Apache which 26:52 just wasn't built to maintain persistent connections. 26:54 A connection is created, a bunch of resources allocated. 26:56 And you start to need to scale horizontally quite quickly. 26:59 But Ratchet PHP was created. 27:01 A more evented framework. 27:03 And on top of that, people are building solutions. 27:04 Something called Ratchet, [INAUDIBLE] which is a 27:07 a web socket solution. 27:11 But I don't believe it offers HTTP 4 [INAUDIBLE]. 27:11 There's something called Water Spout Server that 27:13 seems to offer HTTP 4 [INAUDIBLE] PHP. 27:16 But it doesn't seem to have been updated for a while. 27:19 And then this [UNKNOWN]. 27:21 There's a bunch of solutions that kinda cross the divide there. 27:22 If you want something at your message level, [UNKNOWN] is pretty good. 27:25 The next simple thing to think about is, do you want native mobile support? 27:29 So, the technology's been very browser focused. 27:32 But it might be that you want a native client that connects. 27:35 And has a Real Time connection, persistent connection to the server. 27:38 So. 27:41 Do these solutions offer native clients? 27:42 Now only a few of them do. 27:45 You also need to think about the type 27:46 of communication that's going on between server and client. 27:48 It's a mobile client, it might on a flaky network. 27:51 It might be that you don't want a lot of processing to go on. 27:54 You just want to send small pieces of data. 27:56 So that might affect the solution that you choose in terms 27:58 of a [UNKNOWN] synchronization solution that just sends the changes in data. 28:01 RMI might hide that away, as I said, the remote method of invocation. 28:06 Also, for Native, you, you'll need SSL support because 28:10 web sockets can be blocked by mobile network proxies. 28:13 Even SSL connections and also corporate networks. 28:17 So, think about that, and you might need [UNKNOWN] fall back. 28:22 There are quite,there are some solutions out there that 28:24 support web sockets in mobile natively, but don't offer HTTP. 28:26 There are a bunch of solutions that do have mobile clients. 28:31 As I said, I can provide that afterwards for reference. 28:35 So the fourth thing is understanding. 28:38 Your applications' functionality. 28:42 Is, again, it's pretty obvious but hopefully 28:43 the stuff that's common sense means it's right. 28:45 so, think about the information architecture, 28:49 the data you've got within your app. 28:51 Think about the complexity of interactions between the client 28:53 and server and how this technology fits into that. 28:56 How users will interact with that, how systems will interact with that. 28:59 So understand which type of functionality suits your solution. 29:02 So is it the simpler message. 29:07 Is it PubSub, is it synchronization, data 29:08 synchronization or is it remote method implication. 29:10 So I've tried to break that down and tried to apply an axis to that to help. 29:13 So across the Y axis we've got, along the Y axis we got data complexity. 29:19 And across the X axis we've got application complexity. 29:25 So if we look at onMessage we're talking about low data complexities, 29:29 simple data, and we're talking about the application isn't doing very much. 29:32 It's just getting simple pieces of information. 29:35 As the data starts to get complex you might wanna partition that data into like 29:38 just certain pieces of it, and only get 29:43 updates from those little bits of data chains. 29:44 So PubSub fits in really well with that. 29:47 You select, you have a name that just 29:48 identifies the piece of data that you want. 29:49 And then as the application becomes more abstract the 29:52 functionality that you want maybe becomes a bit more complex. 29:55 You can look at simple data through a simple 29:59 object turrented API because you're doing object turrented programming properly. 30:01 It's simple interactions, simple messages. 30:04 Over the wire. 30:08 Or it might be that you are, you really 30:09 are talking about complex data structures that you are manipulating. 30:10 In that case we're talking complex data 30:13 and complex functionality in the top right. 30:16 So I've tried to take the examples that I 30:18 had previously and put them into the right quadrant. 30:21 So the four square notification might just be a simpler message. 30:25 ITV, I happen to know that some of these solutions use Pubknobs, 30:30 oh sorry, PubSub, so ITV actually use Pusher and they have, they 30:34 use PubSub, and you can see the way you know, that different 30:38 use different types of categories so the channels are different categories of news. 30:41 It might be sport or it might be even down to the 30:47 club level football team or the different types of news that they've got. 30:50 Mann City actually used PubSub solution as well. 30:54 Let me find an interesting one. 30:58 Mural.ly. 31:01 Now Mural.ly for me is a synchronization platform it's 31:02 about synchronizing the state of that view between multiple devices. 31:04 But they actually use pusher as well, although it 31:08 feels like they should be using date synchronization solution. 31:10 Google Docs, obviously date synchronization 31:13 and Google have actually opened 31:15 up their Real Time API which provides you with access to 31:18 that sort of functionality so you can build your own 31:20 apps on that and cloud nine obviously you're synchronizing document state. 31:22 Interestingly enough, JabbR, built by David 31:26 Fowl from Microsoft on top of SignalR. 31:30 Dave actually used SignalR and RMI to build JabbR 31:33 which is, well JabbR which is a chat app. 31:38 So it's interesting that they've gone. 31:41 I guess your chats messages are relatively small, but for me 31:43 it feels like it PubSub solution so hopefully that helps you. 31:45 If you've got applications you're thinking which 31:48 one suits me, hopefully that kind of works. 31:49 And just to apply that to the solutions that were available at the minute. 31:52 There's a lot of data to take in, I don't expect people 31:55 to, you know, look at that now and, and just understand it. 31:57 But I'll share these and, you know, it just 32:00 might help, kinda go which solution might fit my needs. 32:02 An interesting one that people generally aren't aware of is that Dropbox have got 32:08 an API now that isn't just a 32:11 synchronizing files, but also synchronizing simple data structures. 32:13 I think it's probably named value pairs actually. 32:17 Okay. 32:20 So finally, where are you in development, in terms of your development life cycle? 32:22 And how does that affect the solution you choose? 32:26 So if you already have an application, you can either go self-hosted, 32:28 go for an existing solution and sell it and maintain it yourself. 32:32 Or you go host it. 32:36 Now I don't want to go into the details of the 32:37 diagrams, but the points here are that you can take the 32:39 Real Time solution and add it to your existing application code 32:42 so the same web server is,is fundamentally dealing with the ATTP. 32:46 Request response functionality is what the application 32:50 standardly deals with but also persistent connections. 32:53 Now that might be quite handy, there's things like 32:57 a lot of, a lot of [UNKNOWN] and node solutions 32:59 let you hook onto the same http server and let 33:04 you handle connections singly through that single existent http server. 33:06 And signalR is part of asp.net now, so it will offer that, as well. 33:10 But I think, as your application becomes more complex. 33:13 And you've got existing logic all in the same application, in the same component. 33:16 That it can become quite complex to manage. 33:20 So I think as you, as your application grows, 33:22 you want to be thinking about loosely coupled components. 33:24 And dealing with [INAUDIBLE] responsibility principle. 33:26 So, this example is just saying, all right, let's split it out. 33:30 Let's use a message queue to communicate between 33:34 the Real Time solution and the web application solution. 33:36 It's really simple. 33:39 It might be that your database is 33:40 actually something like Redis anyway which accesses a 33:41 system store but also a message queue.So you can quite easily hook that in anyway. 33:43 Or you might go for a hosted solution. 33:49 A proper hosted solution will obviously offer you a really simple API to integrate 33:52 with, and you should be adding Real 33:56 Time functionality to your app within, within minutes. 33:58 That used to be my whole sales pitch. 34:00 But that really is the case. 34:02 You know, these solutions are out there. 34:03 They've got developer tools. 34:04 Their functionality is relatively strong, so it should really help. 34:06 But I think it ultimately comes down, I'll move on. 34:10 It ultimately comes down, when you wanna use a hosted 34:13 service, your value is in features, adding features and functionality to 34:15 your applications, or if your infrastructure, your code, everything 34:18 about your application is really important to your, you know, what you offer. 34:23 Then you wanna probably self host. 34:29 Okay, so. 34:33 Say, you don't have an existing application, and you're 34:34 really lucky, you're green, in a green film position. 34:37 You can kind of do what you want. 34:39 You obviously want to think about these considerations. 34:41 You want to think about loosely coupling components, whether you go hosted, 34:44 or if you want to try out a new breed of framework. 34:49 So. 34:54 The number one exciting [UNKNOWN] is so good that 34:55 even [UNKNOWN] using it and I'm useless at coding 34:59 so it basically offers Real Time synchronization of data 35:03 structures plus templating functionality plus the ability to instantly interact. 35:08 Between client and server offers RMI functionality, I offer synchronization. 35:14 And it's all baked in to this one framework. 35:18 And you can even, you can have the, it's open source. 35:20 You can develop with it locally, and then you can 35:23 actually push to meteor.com, and have your own app running hosted. 35:24 Or if you want, to not be quite as tied to that, you 35:28 know, all-in solution, you can go with the backend as a service solution. 35:32 Things like Firebase are really good. 35:37 They offer a bunch of libraries. 35:38 So they offer the synchronization solution, but they also 35:40 offer on top of that a bunch of libraries. 35:42 Things like ember fire for binding with ember collections 35:44 and angular fire for obviously working with angular JS. 35:49 And you might've heard of no back end. 35:54 So there's no back end to org. 35:55 Not all of those solutions will have Real Time, you know, 35:57 as part of that solution, but a lot of them do. 35:59 So, kind of in summary, or definitely in summary 36:01 hopefully I've convinced you all that Real Time does rock. 36:07 And just the five points to emphasize ya know, 36:12 think about when you're choosing this Real Time solution. 36:14 There are lots of solutions out there please, please do use one 36:18 the languages are a consideration don't default to sucker IO ya know 36:22 if that suits your team then go for it cuz it is good 36:25 Think about native mobile support. 36:30 Think about the type of functionality you've got within your application. 36:32 Is it simple, simple messaging. 36:34 Is it something you can fit into thinking about the 36:36 messages your sending over the wire and partitioning your data. 36:38 Is it data synchronization or is RMI just does 36:42 that just fit nicely does it just make the code 36:44 you write look cleaner and can you somehow monitor the, 36:47 the network traffic and make that part your stack anyway. 36:50 And then also, depending on the point in the 36:53 development process that you're in, that can have a factor. 36:55 Because you can think about going with one of these, 36:58 you know, one of the more Real Time focused frameworks. 37:01 And ultimately, it might be that Real Time becomes 37:03 baked into a lot of frameworks that we use. 37:05 Hopefully the, the functionality is of that benefit that people will start 37:07 to, the developers will just go okay everything is gonna support web sockets. 37:11 Everything is gonna support on abstraction of that, at 37:15 least pops up, maybe synchronization will be an offering. 37:17 I don't know of any synchronization [COUGH] self host 37:20 its solutions so maybe that's something that might, might appear. 37:22 So that's it. 37:28 Thank you for listening. 37:29 I guess I got three minutes for questions. 37:30 The slides are available now. 37:32 I think you can push them at j.mp/Real Time-tech-stock. 37:33 >> Okay, Phil thank you very much. 37:42 Does anyone have any questions for Phil about [SOUND] Real Time? 37:43 [SOUND] 37:46