[MUSIC]

[SOUND] Thank you.

Okay.

Cool.

Okay, yeah, so I've chose the catchy title

of Choosing Your Real Time Web App Tech Stack.

So what I want to do is convince you that Real Time's awesome.

And then go about talking about how you should

look at the technologies and the decisions you should make

in choosing which Real Time web technology that you

will definitely be using in your current or next project.

So, yeah, I'm Phil Leggetter.

I've got this silly title of Developer Evangelist.

I've worked for a couple of systems.

I've worked for about three times now,

about four times now, if you count contracting.

yeah, [INAUDIBLE] is a, a developer tool kit and light

rate JavaScript framework for building large complex front end JavaScript taps.

So [INAUDIBLE] builds web trading frameworks

for, that they license to banks.

So we're open sourcing some of the tool kit behind that.

And previously, I worked for Pusher.

Who areuh, a Real Time web hosted service.

So, again, I hope that, that and the ten year's

experience will, will mean that these talks of interesting and useful.

So this is obviously future of web apps by

Future Insights so the focus should be on the future.

But let's try and understand a little bit

about the history of the technology before that.

So web communication apparently the first documented version of http was in 1991.

makes me feel old cuz I was around then but probably not using the internet.

I don't think many of us were.

So that was basically in 83 as a request response protocol.

It let's us request data a connection's open,

we get the data back, the connection's closed.

It's delivered generally from a client, a request made from a client to a server.

But for Real Time web communication we want two

end points or two clients or two devices to be

connected so that soon um,as say one of them has

new information it can instantly be pushed to the other.

So with ACTP we don't get that out of the box initially.

So in 1996 we had Java applets which meant in Netscape we could embed a Java applet

and we can communicate with JavaScript from the

applet using life connect plug in to JavaScript communication.

But, I mean so that was great and we can make

a persistent connection from the client, the web browser to the server.

When the server had new information it could push it to the client.

But there were loads of problems with Java applets.

We had legal battles between [INAUDIBLE] and Microsoft for the JBM.

We had really flaky Sun JVM problems.

And also, none of us liked plugins.

So we obviously went to move away from that.

So people who wanted this functionality ultimately hacked around it.

So around 2000 we had something called HTTP

Server Push, which meant that we used http, we

could create a connection from the client to

the server, and hold that open in some way.

So when the server had new information It could be pushed to the client.

So back as early as 2000, we had Real Time web technology.

We had the ability to do this sort of stuff.

But the only people using it were generally financial

companies.

So it wasn't until 2009 that it's really gone

mainstream, and I think that's for a few reasons.

Firstly, we're seeing that technology used within platforms that

we use all the time and the benefits from it.

But also marketing has got hold of it.

I think they think its all bad.

So, Robert Scoble back in 2009 wrote a blog post

saying is the Real Time web a threat to Google?

And what he meant by that was that.

He was using something called Friend Feed at the time.

Which is a social network aggregatEable also a social network in itself.

And he really liked the way that you can

publish information and as soon as the information was published

other people could search for you know matching terms and

find that data and have it returned to them instantaneously.

Now if you think about 2009, we would

publish a blog article or um,you know a new

website and wait for days for Google to

spider our site and make it accessible through search.

So this Friend Feed and, and then Twitter search were the first kind

of instances where at scale, we could

see content that was published instantly discoverable.

so, we've got instant discoverability of data.

Now back in 2009 if you went to Wikipedia

and searched for Real Time web there wasn't a definition.

I'm not boring that I wrote a book post on the

fact that there wasn't a definition of, of it in the Wikipedia.

I don't know why I didn't just write a definition.

So it says the Real Time web is a set of technologies and practices that enable

users to receive information as soon as it is published by it's authors in this case.

It could be systems, it could be users.

So that's a change just from the

instant discoverability of data is the instant delivery

of data to a, you know, to the

people that are interested in receiving that information.

So we've got instant delivery of data, and the one of the, one of the reasons why

it was then possible, and there was use

cases of this technology, is the thing that's offscreen.

Things like a Follow button.

So the applications we're now aware of the

pieces of information that you are really interested in.

You would follow people on Twitter.

So as soon as they tweeted that information could be delivered to you.

You would friend, friend people on Facebook.

So as soon as they post an update it can be delivered to you.

If you look at things like Google Plus, you have people to circle.

So you're interested in their information.

So, as soon as they publish something, it can be pushed to you.

So, a lot of people say this technology isn't Real Time.

Now you're not gonna use it to control a

nuclear power, power station safety system or control the brakes

on your car but you will get a delivery of,

of that message over the internet in around 300 milliseconds.

Probably less than a 100 milliseconds.

But it really depends on the network.

But in terms of usage, that's generally fine within applications.

Certainly in these cases, that we're seeing at the minute.

One thing I would say though, is that

the timely delivery of that data is really important.

So you need to think about data's generated.

Some event occurs and, and a payload of data is generated.

That needs to be delivered to the people of the

system that's interested in receiving that data within a timely fashion.

So, if I were to stand ten hours, slap myself in the face.

You guys would go, this guy is a loon.

And then if I just continued talking and five slides later,

I went ow, you'd go, it was weird when he slapped himself.

Now he's just shouting it out five slides, five slides later.

That doesn't mean anything.

There's no, there's no context.

You've lost, you've lost the context.

You've lost the relevancy, but if I slap myself and

say ow, it's still weird, but it's not quite as bad.

So it's really all about maintaining that context.

Maintaining that relevancy.

And obviously with Real Time technology the fast,

the fact that you can instantly deliver information.

To use it in systems within a

timely manner, it means you maintain that context.

So that's the opportunity with this technology.

So let's look at the benefits and use cases of Real Time.

The fact that we are pushing information

as soon as it becomes available is convenient.

We've probably all seen that in, in the apps that we

use but [LAUGH] a really silly and simple example is phone calls.

Because you people are, are, are a phone number

and it would be a nightmare if we had to

open our phone, open up the phone application and press

a button to see if we had an incoming calls.

The fact that, that the network maintains a connection to your phone And

when people phone your number it rings your phone is a form of Push.

And we've seen that in all sorts of different

other ways in terms of SMS and push notifications.

So this obviously isn't.

These aren't Real Time web applications, this is just

proving that Push is a convenience and there's a benefit.

So if you take that to the web ITV News had A

site update around a year ago by a company called Made By

Minnie and all they did really simply was change the site to

look more like an activity stream say it's a live news stream.

And from that CMS when they publish new content they

deliver that content to the web browser to the thousands of

people that are on that site ,and say there's three

new updates available you click that and the content slides in.

Now that doesn't seem particularly interesting, But within

six months of doing that they've ten fold

increase of traffic on their site because it

became known as a source for Real Time use.

This was developed for Manchester City by [UNKNOWN] a digital agency in London.

I think its championship manager or football

manager so I love it straight away.

But it's basically, it feels to me like a second screen

experience that you get lots of Real Time information related on the

game you're watching maybe on the TV or maybe you're not even

on, it's just useful TV information as soon as it is available.

So I think examples like these where there's lots of

data available so obviously sports are really good one where

you can get Real Time content that either compliments the

thing that you're watching anyway, or or is just generally useful.

Thinking of things like in how many of us out there watch a

TV program or watch a movie and actually then jump onto IMDB and go

what was that guy, and what was she in, and wouldn't it be cool

if you could have a synchronized view of IMDB based on what you're watching.

So this sort of thing's, you know, possible.

So, this isn't probably the most exciting examples.

But I wanted to, to provide it.

Because I think it's quite interesting to

think through why Google offer Real Time analytics.

Is it just a marketing ploy?

I think that's part of it.

But I also thing there's actually a lot of value.

And when you publish some content online.

What reaction has it had?

You, it's nice to be able to see you know, the,

the reaction that's had, how people are arriving at your site.

What keywords have they arrived at your site from?

Where are the sources?

And the real value, I think, in this, is the ability to

look at that and make instant decisions and react to those changes.

So if you see a bunch of people coming in from a destination you hadn't thought of.

You go and investigate that destination and go, oh they're interested in X.

Then you can actually update your site, and update your

content to take advantage of the fact that people come from

that destination, or they're coming from those different they're interested in

specific topics you hadn't thought about when you wrote that content.

You could also think about it.

I push a new side of production.

And all of a sudden I see my traffic massively drop.

You know, what's caused that.

That might be the trigger point for me to go and look at my production systems.

What's the CPU usage, what's the memory usage, what's

the disk space on all my, all my application servers?

Why has that happened?

And you can do that because Real Time information

has provided you with that opportunity along with [INAUDIBLE].

So the speed of delivery of this data is giving you an opportunity.

So another really simple example is something like foursquare.

So I go to Starbucks, I check in.

One of my friends is nearby.

They see the check in, they get a notification, we catch up for coffee.

It's not particularly Groundbreaking.

But it's nice to meet with a friend, and have a coffee.

It could be that it's just someone I happen to be friends with.

But I've never actually met.

I meet someone I haven't met before, have a coffee.

Business opportunity comes out of it.

So simple use cases like that.

And this is a relatively old screen shot of Kathleen Trader.

One of the Examples we build on top of the framework that we've got.

So something like this has been around with Caplin for around when did I

start, in 2001 we had something called Web Sheet and it's turned into Caplin trader.

But it was always a focus on life content in terms of news.

Or activity streams you can count it as.

Data but not prices.

And it was just this display of data.

And obviously in finance having the information first means a lot.

It means you can, you know, get rid of your stocks and shares.

It means you can buy stocks and shares.

So in finance Real Time really matters.

So obviously it's not a surprise that the technology was used there first.

But what's quite interesting about this is the evolution of the product.

And the evolution of the use of the technology.

Because it's moved from just being, I mean

it's still just off of the Real Time content.

But now you click on these things, click

on these tiles and you start executing trades.

You start interacting with real trading systems.

You start interacting with traders and saying hey

can I get this price for this product.

So the value was moved from just being able to

see data in real to to be able to interact.

And I think this is the main thing with this technology I

think it's the ability to interact with systems or with other users.

And I think generally it's useful functionality, but also from

an application point of view it means that someone's engaged.

And using that application.

We use products like Twitter and Facebook, and some of us use Google plus.

But fundamentally, they're communication platforms.

Then, you don't post a tweet and hope that

nobody favorites it or retweets it or replies to you.

You post this.

Generally hoping that there's some reaction form that.

There some for some, some sort of interaction and engagement.

[NOISE] to [NOISE] whats wrong [NOISE].

Okay, right, and that's all thanks to Real Time web

technologies that enable that and enable that Real Time communication.

So what are example of use of that technology.

chat.

[LAUGH]

It's not very interesting but I think if you're ever gonna use this technology,

the first thing you're gonna do is you're gonna try and build a chat application.

Because it is an interactive, Real Time experience.

And with this technology, you can easily add that functionality to any application.

You embed it as just part, part of your app now.

[SOUND] So collaboration.

I think this is the area that really needs a

lot of I think there's some good examples out there.

But I think there's more we can do.

So Google Docs is a really simple example that most of us have used.

If you think about editing a document in the past, you probably, if

you're unfortunate enough like me, you

maybe check out a document from SharePoint.

You set Track Changes.

You edit it.

You then save it.

You then check it back into SharePoint and that cycle will go on.

And if there where multiple people that needed

to access that document, it would be a nightmare.

So, the fact that we can get a document to a certain state and then and then

get everybody in to collaborate in Real Time instantly

saves a lot of time and effort and frustration.

Now taking that to a different use case Cloud 9 and there's

a bunch of different applications that offer the same sort of functionality.

Cloud 9 is an in-browser ID.

It lets you edit in Real Time with it used to be up to seven.

Maybe they've increased that now.

Of the developers that are writing code.

But not only just writing code.

They're then running the application, [INAUDIBLE] it together, chatting about

you know, what's going on in the application, and working together.

It's really really useful for, for remote teams.

But also actually useful for teams in the same office,

where you can only fit so many people around the monitor.

And then taking experiences that are collaborative but generally

require space and moving that into an online world.

So things like Mural.ly, which is you're building a mural,

your creating maybe a whiteboard, a great big wall of whiteboard.

But taking that online and letting people drop in notes and annotations and videos.

And building these rich interactive collaborative experiences.

So, so then the use cases.

Life content notifications, activity streams, chat collaboration and games.

I haven't gone into games, sorry.

So again I think it's about these.

So there's lots of value in live content still but I think, I

think you should be trying to

build interactive engaging experiences of this technology.

So what's the fundamentals in using it.

You obviously need to connect.

So you.

To, to get information from a source you need

to have established a connection to that source of data.

so.

I'm just gonna leave this here.

[LAUGH] I bet within loads of applications there's still a

set interval somewhere that's looping and making an [UNKNOWN] request

from the client to the server every ten seconds, every

five seconds, heaven forbid every two seconds, every one second.

Now that might be fine but the Real Time technology that's available

now is stable, it's easy to use, and it will definitely be

more efficient in terms of both resource usage, but also the amount

of code that's required in order to have that functionality within your app.

So I'd seriously consider moving that out and

looking at using a proper Real Time technology.

So another thing that I want to go away is something called comet.

Now comet is an umbrella term for all the hacks we had to go

through to get Real Time communication to

happen over, over http over older style http.

And you might of heard of http

long polling which is different from just polling.

And http streaming.

And all these things were implemented in different ways

in different browsers, and ultimately because of that, the hacks.

And a bit like the superstore we obviously want that to go away.

It went bust for those of you that don't know about comet.

So, the way it's gonna go away is because we have standards now.

We've got a couple of standards That are really useful.

They're not hacks because they're standardized.

Browsers implement them the same way.

and.

And also, because they're standards, it means it's not just tied to, to browsers.

It means we can have clients that aren't just browsers.

We can have server to server communication.

We can have an internet of things connected using these standards.

You've probably seen loads about doing, calling.

I'll be doing examples in a minute.

Loads of them use web sockets.

So, the two standards that we got are server-sent events and eventsource api.

That's just a push, it's a server to push solution over http.

But the solution I'm really excited about is web sockets, because

it's a single connection, it's bi-directional,

it's full duplex communication both ways.

Is a protocol and it's an API.

And I've got a really small [UNKNOWN] here to pick communication with Web RTC I

can't fit that into this talk, but that's obviously gonna be part of this as well.

So, but unfortunately, we still do need the hacks.

We ideally want to use web sockets, where possible.

But we might need to fall back to events source.

HTTP streaming, long polling, even polling heaven forbid.

So we still [UNKNOWN] and that stuff needs to be managed

within our application but it's managed within the solutions that we used.

So we talked about connectivity, what about the data.

And the client server interaction, ultimately the functionality

that you want to build into your application.

So I've broken this down into four things that I think kind of fit.

There's really simple functionality.

There just onMessage.

The server has new information, a blob of small, small piece of information.

It wants to send it to the client.

It's just an onMessage.

So I've taken this from, actually the web [UNKNOWN] has an onMessage.

But I can't point at this now and still speak in the mic.

So this is a suggest library.

We can create a connection.

We define an onMessage on our object connection, and then

we handle the, the callback, the, when we get data.

On the server, we do a bunch of stuff.

But ultimately, we've got the connection as being established.

We've got access to this connection that's been made.

We can just do connection.right.

So it's a really simple, single piece of data payload back and forward.

So that's fine, but as the complexity of your app increases,

and the complexity of the data, you need a better solution.

Now the, the number one solution at the

moment for Real Time web technology is Pubsub.

So we've talked about following people on Twitter.

We talked about being friends with them on Facebook Their subscriptions.

If we take another really silly but obvious example if we look at Google.

So if I go to Google right now and did a search

for aliens I would get a bunch of historical information about aliens.

And they would be relatively fresh cuz Google spies is really quickly now.

But if, there aren't many windows I'm stuck.

If I could hear a humming of spacecraft over the planet.

I could hear little green men running around maybe sticking to

the floor slightly then this information would be out of date.

And the most relevant information would be to me

now,who is interested in aliens, is that we're being invaded.

So Google really should be sending me new

updates saying that we've been invaded, there's aliens.

As soon as people stop and start taking

pictures of these aliens as they're attacking them, rather

than running away and posting them to social

networks, we should be getting that delivered to us.

Soon as the aliens invade digital space, I

want to see those aliens in my search results.

so, the point in this, although it's very silly, is to kind of go, this is

an obvious example where I've actually made a

subscription, I've not, I've not just done historical search.

It is a subscription, and I bet there are

example, examples within your applications, if you think about it,

if, if a user is on a certain URL,

they are potentially subscribing to content based on that page.

So, when new information is available, why not push it to them.

[BLANK_AUDIO]

Okay.

So here's an example, this uses the this, I use

to work for Pusher, so this uses the Pusher Client.

Here we create a new pusher object which is the connection to pusher in this case.

They use channels so channel identifies your subscription.

You might hear it called subjects or topics.

Here I am doing alien search which is just in my application I've decided that

I have prefix of search and whatever they are searching for is maybe a good start.

And Pusher is to have an abstraction above

just that subscription where you combine to specific events.

And that's really handy so here I've got.

I'm binding to new search results.

Oh, there I am.

Or when, when an update changes of when an update's deleted.

So you could think of that as COOD.

So crood without the R.

And you can see how you can expose those events happening within your application.

So as soon as new information becomes available to your

app, you can publish that to anybody that's interested, create my

data payload, and just do trigger, any in search, it's, in

this case, there's a real, it's updated, and here's the data.

And I get that update up here and update my UI accordingly.

And it should be as simple as that.

And these technologies do really make it simple as that.

So the next type of functionality is data synchronization.

I've got operational transforms in there because

you need to think about collisions of changes.

So what we normally mean with

data synchronization is there's a data structure.

I mean, say if we look at Google

Docs there's a data structure which represents that document.

How is that structure change reflected in anyone else who's viewing it.

So operational transforms are detecting those collisions

and making sure that synchronization works out.

So this one uses Firebase API.

And here we create new Firebase objects, so

that's a, that's a reference to our structure.

then.

In this case, I'm treating it as a collection.

So I'm gonna push on just some arbitrary data.

So I'm adding a new child in this case.

And I can also bind to certain events on that data switcher,

and say, so, when a new child's added, I wannna be informed.

When a child changes, so, some data changes

on a child, give, tell me about that.

And also when a child's removed.

So you can see how that kind of works.

You can also see how you might implement that in Pubsub, but this is a

very specific use case about data structures, and

it's probably an abstraction above the PubSub stuff.

Okay.

And the final one is um,remote method invocation.

Now some call it the cousin of remote procedure

call, the object torrented cousin of remote procedure call.

Ultimately your accessing an object and calling a function on it.

A function on it or a method on it over

the wire and that, that's kinda hidden away from you.

You can be making a call on a server you

happen to be interacting with a client object and vice versa.

Two solutions that I know so far that use this, and I

think, I'm sure there will be others A Signalr and d note.

So here's the Signalr example.

Here I can create a so obviously

the framework provides all this sort of functionality.

Here I extend something called hub.

I've got a chat hub

on the server.

Now on the client I can then access the chat hub by this call, connection.chathub.

On the server I'm exposing a send function.

Now on the client I can access that by chathub, down here.

So chat.server.send, and I'm executing this method.

And then the framework exposes functionality and let's me go to

clients to all so all clients are connected call their broadcast method.

And down here I got broadcast method and I'm getting the.

The name and message, so and this is all,

so basically the JavaScript object is created via the framework.

So you define yourself on the server.

Proxy objects create on the client and

you can just interact with us, really powerful.

Well I would say that it's hiding away the interactions

over the wire and potentially the data payloads you're sending.

So if you're using something like that be aware of, of that sort of stuff that

you might be making calls you don't realize,

end up in a network where it requests [INAUDIBLE].

So finally, choosing your Real Time web stack.

Hopefully I've convinced you about Real Time web's awesome.

But you just use socket.io, right?

That's me, done.

So the reason I put that there is because

socket.io is an awesome framework, and it's, it's some

really, it's done wonders for people using Real Time

work technology and, and understanding the benefits of it.

But it isn't the only solution available.

And that's the key thing here, really.

And there's loads of different solutions available.

Don't make it the default.

Try and think about what you want your application to do

before you just dive into it and say I'm gonna use socket.io.

So use an existing solution.

There are loads of solutions available, and I'll show you some of them.

So you should use an existing solution.

Firstly because the connectivity stuff is still a pain.

Proxies get in the way of connections some browsers don't support

web socket so you need to fall back to different solutions.

Then there's the support that an existing solution will have.

If you license it, then you've got that support level.

If you, if it's a community based solution.

If it's an open source solution.

Then you can access that, and get

value from interacting with a community and contributing.

Maintenance is an interesting one.

It's not such a big deal now, I don't feel.

But obviously book fixes will be great, but things like when,

when the web socket protocol was in, in its infancy, and it

changed quite frequently, push a, were the fir, one of the

first companies to jump on that and offer that as a solution.

And they managed the fact that that spec was changing all the time and that

different browsers, different solutions implement different versions of

the spec, and they just dealt with that.

And that's one of the benefits of using, you know, an existing solution.

Features as well so web circuit protocol defines sub proto, let's

define some protocols that haven't been exposed yet it might be.

Things like web rtc handshaking the ability to, to

act as the proxy to say to put two

peers in touch with each other, that sort of

stuff might be baked into these frameworks, and scaling.

So some of these solutions have got

they've thought about scaling from the off.

So they've thought about how you do scale.

Fay, by a guy called James Coglin is a good example of

that where he's thought straight away about how you scale across multiple nodes.

And the guys at Signal are.

Microsoft solution are doing a really good job there as well.

So unfortunately, that doesn't make it that much

easier still because there are loads of solutions available.

So what else can you do to fill it back down.

First thing.

Really, really simple.

A bit like the sockeye node thing everyone wants to use nodes.

It's awesome but it might not be your technology of choice.

It might not suit the thing that you've got.

So there are other solutions available.

So choose a solution that potentially is written in a language that you're.

You know, you and your team are comfortable with.

And there are loads of solutions out there.

I'm going to share these slides afterwards so you

know it's quite useful as a reference hopefully as well

but one thing to point out is something like PHP

where there isn't a great solution available at the moment.

Especially if they built on Apache which

just wasn't built to maintain persistent connections.

A connection is created, a bunch of resources allocated.

And you start to need to scale horizontally quite quickly.

But Ratchet PHP was created.

A more evented framework.

And on top of that, people are building solutions.

Something called Ratchet, [INAUDIBLE] which is a

a web socket solution.

But I don't believe it offers HTTP 4 [INAUDIBLE].

There's something called Water Spout Server that

seems to offer HTTP 4 [INAUDIBLE] PHP.

But it doesn't seem to have been updated for a while.

And then this [UNKNOWN].

There's a bunch of solutions that kinda cross the divide there.

If you want something at your message level, [UNKNOWN] is pretty good.

The next simple thing to think about is, do you want native mobile support?

So, the technology's been very browser focused.

But it might be that you want a native client that connects.

And has a Real Time connection, persistent connection to the server.

So.

Do these solutions offer native clients?

Now only a few of them do.

You also need to think about the type

of communication that's going on between server and client.

It's a mobile client, it might on a flaky network.

It might be that you don't want a lot of processing to go on.

You just want to send small pieces of data.

So that might affect the solution that you choose in terms

of a [UNKNOWN] synchronization solution that just sends the changes in data.

RMI might hide that away, as I said, the remote method of invocation.

Also, for Native, you, you'll need SSL support because

web sockets can be blocked by mobile network proxies.

Even SSL connections and also corporate networks.

So, think about that, and you might need [UNKNOWN] fall back.

There are quite,there are some solutions out there that

support web sockets in mobile natively, but don't offer HTTP.

There are a bunch of solutions that do have mobile clients.

As I said, I can provide that afterwards for reference.

So the fourth thing is understanding.

Your applications' functionality.

Is, again, it's pretty obvious but hopefully

the stuff that's common sense means it's right.

so, think about the information architecture,

the data you've got within your app.

Think about the complexity of interactions between the client

and server and how this technology fits into that.

How users will interact with that, how systems will interact with that.

So understand which type of functionality suits your solution.

So is it the simpler message.

Is it PubSub, is it synchronization, data

synchronization or is it remote method implication.

So I've tried to break that down and tried to apply an axis to that to help.

So across the Y axis we've got, along the Y axis we got data complexity.

And across the X axis we've got application complexity.

So if we look at onMessage we're talking about low data complexities,

simple data, and we're talking about the application isn't doing very much.

It's just getting simple pieces of information.

As the data starts to get complex you might wanna partition that data into like

just certain pieces of it, and only get

updates from those little bits of data chains.

So PubSub fits in really well with that.

You select, you have a name that just

identifies the piece of data that you want.

And then as the application becomes more abstract the

functionality that you want maybe becomes a bit more complex.

You can look at simple data through a simple

object turrented API because you're doing object turrented programming properly.

It's simple interactions, simple messages.

Over the wire.

Or it might be that you are, you really

are talking about complex data structures that you are manipulating.

In that case we're talking complex data

and complex functionality in the top right.

So I've tried to take the examples that I

had previously and put them into the right quadrant.

So the four square notification might just be a simpler message.

ITV, I happen to know that some of these solutions use Pubknobs,

oh sorry, PubSub, so ITV actually use Pusher and they have, they

use PubSub, and you can see the way you know, that different

use different types of categories so the channels are different categories of news.

It might be sport or it might be even down to the

club level football team or the different types of news that they've got.

Mann City actually used PubSub solution as well.

Let me find an interesting one.

Mural.ly.

Now Mural.ly for me is a synchronization platform it's

about synchronizing the state of that view between multiple devices.

But they actually use pusher as well, although it

feels like they should be using date synchronization solution.

Google Docs, obviously date synchronization

and Google have actually opened

up their Real Time API which provides you with access to

that sort of functionality so you can build your own

apps on that and cloud nine obviously you're synchronizing document state.

Interestingly enough, JabbR, built by David

Fowl from Microsoft on top of SignalR.

Dave actually used SignalR and RMI to build JabbR

which is, well JabbR which is a chat app.

So it's interesting that they've gone.

I guess your chats messages are relatively small, but for me

it feels like it PubSub solution so hopefully that helps you.

If you've got applications you're thinking which

one suits me, hopefully that kind of works.

And just to apply that to the solutions that were available at the minute.

There's a lot of data to take in, I don't expect people

to, you know, look at that now and, and just understand it.

But I'll share these and, you know, it just

might help, kinda go which solution might fit my needs.

An interesting one that people generally aren't aware of is that Dropbox have got

an API now that isn't just a

synchronizing files, but also synchronizing simple data structures.

I think it's probably named value pairs actually.

Okay.

So finally, where are you in development, in terms of your development life cycle?

And how does that affect the solution you choose?

So if you already have an application, you can either go self-hosted,

go for an existing solution and sell it and maintain it yourself.

Or you go host it.

Now I don't want to go into the details of the

diagrams, but the points here are that you can take the

Real Time solution and add it to your existing application code

so the same web server is,is fundamentally dealing with the ATTP.

Request response functionality is what the application

standardly deals with but also persistent connections.

Now that might be quite handy, there's things like

a lot of, a lot of [UNKNOWN] and node solutions

let you hook onto the same http server and let

you handle connections singly through that single existent http server.

And signalR is part of asp.net now, so it will offer that, as well.

But I think, as your application becomes more complex.

And you've got existing logic all in the same application, in the same component.

That it can become quite complex to manage.

So I think as you, as your application grows,

you want to be thinking about loosely coupled components.

And dealing with [INAUDIBLE] responsibility principle.

So, this example is just saying, all right, let's split it out.

Let's use a message queue to communicate between

the Real Time solution and the web application solution.

It's really simple.

It might be that your database is

actually something like Redis anyway which accesses a

system store but also a message queue.So you can quite easily hook that in anyway.

Or you might go for a hosted solution.

A proper hosted solution will obviously offer you a really simple API to integrate

with, and you should be adding Real

Time functionality to your app within, within minutes.

That used to be my whole sales pitch.

But that really is the case.

You know, these solutions are out there.

They've got developer tools.

Their functionality is relatively strong, so it should really help.

But I think it ultimately comes down, I'll move on.

It ultimately comes down, when you wanna use a hosted

service, your value is in features, adding features and functionality to

your applications, or if your infrastructure, your code, everything

about your application is really important to your, you know, what you offer.

Then you wanna probably self host.

Okay, so.

Say, you don't have an existing application, and you're

really lucky, you're green, in a green film position.

You can kind of do what you want.

You obviously want to think about these considerations.

You want to think about loosely coupling components, whether you go hosted,

or if you want to try out a new breed of framework.

So.

The number one exciting [UNKNOWN] is so good that

even [UNKNOWN] using it and I'm useless at coding

so it basically offers Real Time synchronization of data

structures plus templating functionality plus the ability to instantly interact.

Between client and server offers RMI functionality, I offer synchronization.

And it's all baked in to this one framework.

And you can even, you can have the, it's open source.

You can develop with it locally, and then you can

actually push to meteor.com, and have your own app running hosted.

Or if you want, to not be quite as tied to that, you

know, all-in solution, you can go with the backend as a service solution.

Things like Firebase are really good.

They offer a bunch of libraries.

So they offer the synchronization solution, but they also

offer on top of that a bunch of libraries.

Things like ember fire for binding with ember collections

and angular fire for obviously working with angular JS.

And you might've heard of no back end.

So there's no back end to org.

Not all of those solutions will have Real Time, you know,

as part of that solution, but a lot of them do.

So, kind of in summary, or definitely in summary

hopefully I've convinced you all that Real Time does rock.

And just the five points to emphasize ya know,

think about when you're choosing this Real Time solution.

There are lots of solutions out there please, please do use one

the languages are a consideration don't default to sucker IO ya know

if that suits your team then go for it cuz it is good

Think about native mobile support.

Think about the type of functionality you've got within your application.

Is it simple, simple messaging.

Is it something you can fit into thinking about the

messages your sending over the wire and partitioning your data.

Is it data synchronization or is RMI just does

that just fit nicely does it just make the code

you write look cleaner and can you somehow monitor the,

the network traffic and make that part your stack anyway.

And then also, depending on the point in the

development process that you're in, that can have a factor.

Because you can think about going with one of these,

you know, one of the more Real Time focused frameworks.

And ultimately, it might be that Real Time becomes

baked into a lot of frameworks that we use.

Hopefully the, the functionality is of that benefit that people will start

to, the developers will just go okay everything is gonna support web sockets.

Everything is gonna support on abstraction of that, at

least pops up, maybe synchronization will be an offering.

I don't know of any synchronization [COUGH] self host

its solutions so maybe that's something that might, might appear.

So that's it.

Thank you for listening.

I guess I got three minutes for questions.

The slides are available now.

I think you can push them at j.mp/Real Time-tech-stock.

>> Okay, Phil thank you very much.

Does anyone have any questions for Phil about [SOUND] Real Time?

[SOUND]