 So what I'm going to talk to you about today is a quick visit in the world of real-time and why I think it's important and how it can change the way you build your apps. So I'm glad to be here today. You don't hear me? So bad. To tell you more about real-time apps, I've been working on building real-time apps for the last few years, different startups. And I think today almost every app could benefit from real-time. It used to be complicated and hard, I think, hard to scale as well. But now with a few different ways to do it, it's become, I think, simple and scalable. So I'd like to start with why I think it's important and how it really benefits to the users. So the user world, you know, today it's changing quickly. You have a lot of information, data. You need to react quickly. It's not just for tech. And many people are working as teams and collaborating all the time. Also, we have mobile, which has changed a lot of things. And it has definitely changed the expectations of the users. You also have the Internet of Things, which is coming, which offers new opportunities and new ways to connect things together and to interact in real-time. And you have this kind of addiction. You know, people are, like, on Twitter scrolling down to get the latest updates. And you always want more and quicker. So it's about the daily struggle of the user, you know. The web has a lot evolved. First, we had static HTML pages. Then we got JavaScript. We got Ajax. Then we moved to single-page apps to make it quicker and better. And the way I feel it is the next evolution of this is really to making it real-time. Because you have the single-page app, which makes it instant to react to the user actions. But then you are waiting for the data, which is only updating when people ask for it. Or at least at some regular interval. So what I want to get rid of is really this, you know, as a pull to refresh. We wait for people triggers. And also we have refresh buttons, sign-up forms with different steps. And you wait until people click on some button to complete and move to the next one and so on. So I think we can do better. And so today for me is a time of fast and real-time. As I said, mobile apps have really raised expectations. And single-page apps are kind of as a website of this. And it helps provide a closer experience to mobile apps. And what people expect as well with mobile is push notifications. So they are no longer waiting for their email updating every five minutes or 10 minutes. They are waiting to get the updates just directly when it's available. So there's another side of this, which is cross-device syncing. And so multi-device, multi-platform sync. For instance, Apple brought it to the latest OS 10 with continuity to kind of help smooth when you go from one device to the other. But then again, it really asks you to be able to have the data shared in real-time between devices. And then you also have collaboration platforms like Google DAX, Slack, which really shows that people are collaborating together on this. So the big question is, when do you need real-time? Is it for everything? Is it just for specific things? To me, the benefits are really clear. You have an increased user engagement. I've seen that on many different sites. You also increase the user experience and the quality of the user flow. Some other benefits are maybe a bit different. It depends on the cases. But it can help decrease the server load as you keep connected. And there are many, many different use cases. The obvious one, I think, is instant messaging and group chat. You always have also collaboration and content. It's exactly the Google DAX things. But how can you bring that to your own applications? Like when people are working on some form and preparing to submit it, what happens if several people are doing it at the same time? With real-time, you could be, instead of using one text area, using some collaborative text area, several people can be, at this step, already collaborating together. But there are also different things like real-time monitoring services. For instance, recently I worked on creating a worker for some tasks. And I didn't want to have to wait for the end to be able to show some results to the user. And with basic real-time features, I was able to really quickly provide updates in real-time to the user about what's happening, what the current state, where is it headed, and so on. And then you have a lot of different things, like live-chatting and graphing, real-time web analytics, digital advertising, e-commerce, publishing. All this could benefit from real-time somewhere as the other. Now, it's a bit different because you already have features. So you're not going to change everything you already have. And that's not what I'm trying to say. For existing features, I think for some of these, you can make it real-time quite easily. You don't have to change the whole architecture of what you do. There are simple ways to move in that direction through a notifications layer with channels or streams. And you can just subscribe to know when some new data is available. And then you just call your existing refresh method. So it's just a way to be notified of the existing new data. So this is similar to push notifications. You just know there is new data. You don't get it. But you can react. I think it's super useful with third-party. Also, when you use some connect with something, like GitHub or Facebook, to automatically update the whole single-page application in real-time as soon as the user is connected. You open this pop-up. It starts the process and so on. And once it's done, as your app is listening for, for instance, the status of, is the user connected to this service? As soon as it's connected, you can update your whole UI without reloading the page or things like this. For new features, you can conceive it with real-time in mind, I think. And we'll get back to that later. So next time you'll be asked to develop things like chat, IM, notifications, status. I think think about it twice. Who has been already in the room asked to develop some real-time feature? Yeah, so quite many people, yeah. So the question is, for me, where would you like to go? It's clear for me. It's real-time first. And I think it echoes to a few things we've heard for the last couple of days about offline first, because I'll get back to that. But I think it's really the same direction. And if your architecture is real-time first, it's also offline first and vice versa. Also what we heard about streams, I think, makes a lot of sense. And it really matches this approach. Now the question is, how do you do it? And how to get it to scale? So you have two big ways, and you have a choice to make here, between self-hosted and hosted platforms. Definitely not the same. Self-hosted may be a requirement. Someone told it the other day, but I know in some countries or for some projects, it may be a requirement to have the thing working on a dedicated server and so on. So you may not have the choice. And also hosted as a price, but it also offers many trade-offs. So regarding self-hosted, I think on the plus side, you have direct access to the database. You can customize it, really make it fit your needs. Do you really want to maintain that? How do you get it to scale? Because it's not easy. I think if I ask you, how can you make a new real-time feature, you'd think about Node.js with Socket.io or something like that. But for people who've already tried, Socket.io is not super simple to get to large-scale applications. But that's still one way of doing it. And I don't know if you follow it, but Socket.io now automatically takes care of WebSocket and also long-pulling built-in. So it's quite convenient. And it really works with many browsers in many different situations. You also have some other approach, like Meteor.js, which can be both hosted or self-hosted. And you also can use Hoody. I know you know more about that. But what I'm going to focus, I think, more about is hosted. And I've been using it. And I think it can be very powerful. It scales. It's simple, usually. You have support. You also have a lot of features. And in addition, what is as complicated when you use some self-hosted system here? It's usually not multi-platform. You have one thing for the web, using Socket.io, for instance, or something similar. But then you don't get all the APIs and SDKs for iOS or Android, for instance. So you're not independent. In some cases, like I'm going to point later on, you don't have direct access to the raw database. And it also has a price. You have kind of three categories here. You have, as I said, general messaging, PubSub approach, which are mainly channels. It doesn't take care of the data, of persistence of the data. So it's maybe easier to integrate in existing projects, but it's limited. It's not going to completely change as a way that you build your app, which may be good. Then you have all the kind of things which take care of data sync, persistence, which are kind of full stack real-time frameworks. You have Firebase, which is the provider I'm going to focus on later on. But you also have the Google Drive real-time API. You have Meteor again. And then you have also different things you can try on messaging, which are very limited, in my opinion. So you have various challenges here. We've been talking a lot about single-page apps. But it may not be obvious, but not everyone already has a single-page app today. For real-time, the WebSocket is not persistent when you change your page. So obviously, you need first to go to a single-page app to really benefit from real-time. Otherwise, when you change the page, it has to reconnect and so on, and you're losing most of it. Then there are the questions around data binding. And this is a bit tricky. It can get complicated. Then it kind of merged the front-end, the back-end worlds. And developers have to get interested in the way data is stored, especially when you use some full stack persistent system. So you really need to get interested in best practices and how you denormalize your data. It's no longer the responsibility of the back-end team or database engineers. It becomes really a matter for everyone. And then again, you don't have necessarily direct access to database. So migrations can become a bit tricky. So as I said, I'm going to focus on Firebase. And why Firebase and Backbone together. As a quick comparison here, I want to show obviously the different things you have as an option when you've chosen to use Firebase. They've been really pushing integrations with everything. So that's a good thing. Whatever you like, even if it's Ember or React, you have integration with all of these because Firebase has been working on it. But basically, I think the Firebase API I'm going to show a bit later on is really simple. And it has a very similar approach to Backbone. Keep it as simple as you can. Also, it works well with modern collections. And I think the Backbone limits the fact that your collection has models and models have flat properties. It doesn't really work so well if you try to have arrays as properties and so on. It helps to structure your data correctly. So it's a good thing. And in addition, what we'll see in a second is the transition is, in fact, pretty easy. But you just get a two-way data binding, which is good. But when you get to compare with Angular for very simple projects, Angular may seem easier to have directly some amazing Y effect. With Angular, you have this kind of black magic. When you bind with Firebase, you build something. The user starts changing the input. And it's automatically saved and replicated to the other clients. So it's very efficient. You have this choice between representing the collection as an object or as an array. Because in Firebase, everything has a unique key. And you have a community around Angular and Firebase together, which is very active. And I think this is maybe the opportunity to get people using Backbone very interested in Firebase and showing how it can really help to build better apps. So Firebase and Backbone Fire, it used to be called Backfire. Just saying this because when you search for it on Google, it may be a bit tricky. It used to be called Backfire, but now they call it Backbone Fire. It's on GitHub. So a bit more context about Firebase. So Firebase is a backend as a service. So it's hosted. And it takes care of data persistence. What it basically means, I think, to all of you, is just a quick question. Who is mainly a client-side JavaScript developer and doesn't work on Backend here? So I think Firebase is really a unique opportunity for you because what it means is you no longer need a backend. You no longer need someone to write the API, to take care of setting up a database, and making the API work with the database. And so you're responsible for everything. You just take this JavaScript into your app, and you get started. You have persistence. You have real time. You have a full REST API at the same time. So it's very powerful. And you also get very powerful security. What Firebase has, it's security rules. It's just, in fact, being a JSON object where you can describe who can access what is, what are written rights. And it can be very, very well developed with complex rules based on the new data arriving, based on the existing data, based on existing data at different locations in your existing database. So you can really create something entirely secure. And in the same time, it's uniquely a client-side. You don't have a server, and that says. Also, they provide, but it's a side plug-in, so you don't take it all at once. But they provide a sign-up and login providers. So just with a few add-ons, you can have Facebook, Google GitHub, and so on connect integrated. And they take care of signing up, sending emails, and so on. One big thing, I think, and what I said earlier, is a multi-platform. So you've really created an environment here, which remains simple. The API is exactly the same everywhere. And you get JavaScript node iOS Android, plus a full REST API with streaming. So it means, for instance, if you're a fan of Go, you can also use it with Go. And the REST streaming API provides you with the data in real time, with standard web things. There's nothing really hidden here. Even the JavaScript, the JavaScript client-side script, you have the Firebase debug JavaScript. So you can go, if you're interested, you can go through the whole Firebase client to understand how it works and really understand it deeply. Then there's one thing we talked yesterday about. It's offline support. They don't actually have it right now for the web, but it's coming soon. And they already have it on iOS. And it makes app development really quick, efficient. And I won't go again through all the benefits, but it really makes a difference. And I think when they release it for the web, it's going to be huge because once you've really thought about your app in a real time perspective, and you have the architecture which works with real time, adding offline support is not difficult. So for people who are convinced today about offline, if you really have already maybe an offline app, it's easy to make it real time. At the same time, it really has the same background. So then they have integrations. And one little thing, again, for people who are client-side developers and are interested in this backend-as-a-service approach, they even provide hosting. But again, it's totally an option. You can just throw it if you want. So how does it work? The basic is you create a Firebase reference to your Firebase location. Once you've got it, you just use Set to update. With Set, you pass a JSON object. And it's very, well, it's completely the usual thing. And then you can listen for changes on this. So you have this onValue, and you get the data snapshot every time something changes. You can also use once it's provided. What you get is not directly an object. It's a snapshot, as they call it. You call the val method on it, and you get the real data. The reason for this is you have also a few other properties on the snapshot, which, for instance, help you with data order or things like this. Or you can also directly call other methods on the snapshot. So the usual demo, the to-do. And what I'd like to pinpoint is there is no timer. There is no interval. It's really instant. Yeah, with Backbone. So it just works. And what I'd like to show you now is how you do this with Backbone, and how you go to migrate from a static to real-time. And actually, it's just one line change. You just replace your existing collection with a Backbone Firebase collection. And it just gets, it doesn't get more complicated than this. You provide the URL to your Firebase, and it just goes real-time instantly. So one little thing is when you use a real-time collection, you need to keep Backbone models, standard Backbone models. You can't mix or you don't have to mix real-time Backbone models and real-time collections. And the good thing is now you can just forget about fetch or save, because it doesn't make sense anymore. Well, as soon as you call add or create, it's automatically persisted. It automatically, the other thing is it instantly triggers locally, and then it persists to the server. So you can, as an option, decide to wait for the server response to trigger locally. In some contexts, it makes sense. But otherwise, it's instantly triggered for everything locally. So that just the way it works. It doesn't change anything. You add, you remove, you create, and it just works. So another quick example to show you how simple it is, is, for instance, to create a chat. As I said, it's a very basic use case. And it's actually just a collection with a name and a message. What did I say? Oh, yeah. Who is? Oh, yeah, Adam. So you can also use Backbone Firebase model. This way, you just have a real-time model. It's useful for all the kind of things. Actually, for instance, I was thinking about real simple things you can implement today. I think user settings or user profiles are very useful here. For instance, for your user settings, you can use the Backbone real-time model. What it means is when the user changes the setting, you directly get it on all the different windows open, for instance. And you also directly get it on the different devices. So as I said about continuity, it's super useful when people are using your app on different platforms, different devices. So you can adapt your UI based on changes, again. And you can do the same for user profiles. For instance, your user changes his nickname. And it will automatically change for every client connected. So when you're in a chat, for instance, it's pretty nice. As a matter of fact, you don't have to be writing the URL all the time, like what I put in the examples. You can just use the ref, the Firebase reference, and pass it directly to your model. It also makes sense. And you can use this child method to access the different childs. You can also put directly the slash. I could have done a ref child user settings slash user ID. You don't have to go with child and child again and again. So to describe a bit more the Firebase API, you have a few simple things. So first is a set. So it writes or replaces data to a defined pass. So it really takes your data and makes it persistent here. The update one, I think it's very simple. It just merges what you pass to the location. Push is a bit different. It actually automatically creates a client-side unique IDs. So you don't need to take care of this. They do it instantly. And they make it in such a way that your data is ordered. So as long as you use push, when you retrieve your data later on, it will be ordered. So you can use it around with every client connected. And the data will always be in the right order. So that's kind of a good assumption. And that's something they really provide to you. And they make sure it works. You also have a very nice feature. It's a bit more advanced called the transaction. And I think it's interesting to think about client-side transactions like this. For instance, one use case for this is you have some badge with the Android count of, I don't know, the notifications or messages with this user. And you may have several clients who want to update this at the same time. So a very bad way of doing it would be to take the value at one and then set the value. That's not how you want to do it. Because if you have several clients doing it at the same time, you will end up with messed up values. So the way you do it is you use a transaction. And the transaction, basically, the function gets the current data as a parameter. And you can just change the data and return the new data. And Firebase takes care of making sure they've been using the latest current data to update it. The way it works is simply they send to the server the current data and the new data. And they do it as they will go back and forth until the current data is the right one. So it's very efficient. It works fine. And combining this with security rules, you can really make sure to have something that is both very performant, useful. It's on the client side, and it's still secure. Regarding how you retrieve data, so you have the on-value thing I showed earlier, you can also use once value, which will only trigger once, as expected. So when you do it on a collection, you do on-value. What you get is a snapshot of the whole collection. Then you can do a snapshot for each and go through it. The other way you can do it, which is a bit more getting into the real-time mindset, is you go with child added, child changed, child removed, child moved. All these things are really collection-oriented. And it really helps you think no more as I get the snapshot of the data at some point, which doesn't really make sense, actually, for a real-time collection. Because you get the data, and then it changes again. And you will get all the time the full block, which is not what you want. What you want to know is what are the new items, which have been removed, and so on. So using those child added, child changed, and so on, you can really get a good view of how it works. And if you go later on, check the source of the backbone Firebase integration. It's actually what it does. It matches these events with backbone. And it really makes that easy. The question you may have is, then that's fine. I have collection models, but for a real application, a real-life application, I need more. I need a way to query data. And you can do that. You can't do everything. You won't do this child contains this string, and so on. That's not what it's intended to do. It may come at some point. They're adding, and they're working hard on this. In addition, they've been acquired by Google a few months back. So it may help add more on this side. So you can do complicated things with this. You can use order limits, start at, end at. And it really helps you to build more complicated things. You have event guarantees. So Firebase makes important guarantees regarding events. Events will always be triggered when local state changes. Events will always eventually reflect the correct state of data, even in cases where local operations or timing cause temporary differences, such as a temporary loss of network. So it's not completely offline. But if you get offline while the app is running, it keeps working. Does the local event keep being triggered? And as soon as it gets back online, it sinks. Another little demo to show you that you can do fun things as well is play a Tetris. So I was playing with myself, which is not very interesting, I think. But it's pretty nice. So to finish on the API, you also get the connection status, which can be useful to display to the user, as we said, with offline yesterday, the connection state. And to let them know if it's been persisted or not, which is, I think, more important right now, as they don't have offline support yet. Because if it hasn't been synced and you leave the page, it's just lost. And one very useful thing when you get deeper into creating those full client-side apps is on disconnect. Because on disconnect is super important for our status. For instance, you have a user status. It is a way connected or idle. And with it, you can make sure that if the client disconnects, the data is automatically removed. And you don't end up with some ghost or things like this. So security rules. This is just a quick overview of what it is. You can get to that. It's really nice. They also have added now a full language, which makes it easier to create more complex rules. Sorry. Thanks. OK, so what are the challenges? Actually, you will instantly get working on a collection view. So myonet may be very useful here. But there are some caveats, especially with the data order. The binding yet doesn't really help have the same order in the backbone collection and the real-time collection. So you need to write the proper comparator for your backbone collection. Then pagination. I guess with the real-time application, at first, you want to avoid it. But if you start having very large data sets, you need to get back to this. And using start, add, end, add, and limit, you're able to build real-time pagination. And it's quite nice. A few issues come when you don't denormalize your data correctly, because you're loading by reference. And for instance, if you have a list of one simple case, is you are a user, you have work spaces or projects. And at some location, you store the list of projects of your user. But then when you plug a backbone real-time collection to this, it's not really perfect, because what you get with the collection is only the names or the names of the users. The names or the IDs of the projects. And you would like to get more info at the same time. But for instance, the name of the project is not stored at this location. It's stored somewhere else. That's the kind of things with loading by reference, which it's not yet super simple to do. But it doesn't get very complicated as well, because you just plug another reference on value and you're able to update it differently. Then again, what it means is you have to focus on how you denormalize your data. And even though it's super cool for our client-side developers to be able to build all this without any server, you have to get interested in how you structure your data. And you may not be used to it. Regarding offline, it's not yet on the web, but a quick hint for what's coming. As I've been working a lot on this on iOS, is what you will hate is once value. Because what does once mean once you have offline? You know, it will automatically trigger with the offline value, but then it won't trigger again. So at some point, your user will have to refresh the page to get the real data, which has been retrieved by the server. And there will be always kind of a delay, because if you don't reload the page, what you display is what the user got the last time he opened the page. So it may be a bit tricky. And if you really think about going offline first, I would consider using as least these things as you can and try to get more into the on-value way. Then another thing Firebase is adding and releasing soon are triggers, which really help you to go one step further. Because up to now, you usually had to have some Node.js worker listening to some things to, for instance, send an email when some data changes. You want to push notifications, emails with information, or things like this. And so it meant in the end, you still needed some Node server. I think what they are creating now is a way in the security rules to say, if data changes at this location, I want to make a request to this URL. And you can integrate this, for instance, with Zapier or other services, which will enable you to have direct actions without having to run some Node server at the same time. So I don't know how familiar you are with denormalization. What it basically means is what I was talking about earlier is you don't want to put all the data at the same place. It's not, I have rooms. In the room, I have the names of the people. I have all the messages and so on. Because it will get tricky. At some point, you will say, I just want to have the room name of this. I just want to go through all the rooms. And your data set will get huge. And it won't be possible for you to access one direct child. Because what you need to keep in mind is you can't ask Firebase to provide you with this location and just one level of children, for instance, and not more. With the REST APIs, they are providing a bit of this now. But it's never going to be real. Because on the server side, they have to load the full node to return you just what you're asking for. So if your data sets becomes gigabytes, eventually, you'll just get very slow. So that's not what you want. What you want is a bit more like this. You want a list of rooms with the name and maybe the type. You want a list of members. And for each room, who is a member of this? And then you want a list of messages per room. This will take some time, I think. Sometimes you think you've gotten better at this. And then you realize, oh, no, I should have done this again differently. So it's also about experience. But it's about thinking it at the beginning. And it's really a way that's something you need to learn and be interested in. So what's next? I think regarding the normalizations, there is an interesting Firebase blog post about denormalizing your data is normal. But you also have a few very interesting Firebase projects which are not all backbone related, but give you very interesting insights about what you can do as very complicated projects sometimes with Firebase. For instance, I've been active in the Firepad community. And it's an open source, operation transform-based collaborative text editor. So it provides a very large feature set. Many people use it, for instance, to create a collaborative code editor, a lot of services of peer coding or things as these have been written. It's very simple. But then it uses transactions in very smart ways combined with operation transform to build complex apps which are purely client-side. It's not like Google Docs or, I don't remember, Acerpad or things like this. Just about the talk coming is about geographical data. And that's interesting because Firebase, for instance, if you want to build a real-time app where you can see the trucks moving into the city on a map or something like this, you can do it with Firebase. Using these limits start at end at, it's something you can do. But it's a bit complicated. So they've created a library to do this. And then you have very more simple basic examples of apps like FireChat, which is more complex examples than I showed, and some Office Space Organizer. That's for me. Thank you again. And thank you for all the Boku team, Adam and Claire, for bringing me here. Thanks.