 Right. So, I'm going to keep my talk fun and short, because I know everyone's dying to go to the pub, you know. And it's also one of the beginner series. So, to bring more new people in, you know, get excited about Ember. It's like the future. Okay. So, people ask why? You know, why Firebase? Why can't we just use, you know, Rackspace? Or, you know, just, you know, get all the patch. And then, so, my question, you know, I would like to start the whole thing with a quote, because it kind of, it's kind of the essence of my talk, you know, which is basically that hardware is becoming, you know, a commodity, right? It's like, it's like, you know, most of the stuff that you see is happening, you know, today, is that you're essentially disaggregating from hardware, right? Which is what's happening, like, across industries. It's not just like hosting, you know. So, you know, you have, what you have like, you know, companies like Uber who have, you know, no equals. And like, you know, you have like Airbnb has no, so basically it's like the most part of people in the world, they don't own anything, but they control everything, right? And that's kind of where the whole thing is going. And just, you know, so, my point of that is that the same thing is kind of happening with, you know, developers as well. And so, you know, this is an actual startup. It's called, yeah. So, my point is that which brings the solution of web apps, because that is an actual startup. And it's like, so everything becomes a commodity, including your phone itself. Because the way they make that technology work is they shine some lasers down down the arm. And when you touch the fingers, they, you know, you block some lasers, then, you know, you kind of know that this is where you're swiping. And so, you know, your phone, your servers, your cars, everything is kind of becoming a commodity. And the innovation kind of begins and starts with software, you know, which kind of brings me to evolution of web apps. And it kind of had data centers, Samsung, and Heroku came along. And when I show Firebase here, I don't really mean Firebase just by itself. You know, you have to include things like Treeline, which is essentially, you know, things like AWS Lambda, which essentially allows you to write node functions that connect, you know, your S3 with your EC2 buckets. And so we're seeing the trend that's this kind of boss, which is like backend as a service, right? And so, you know, because the whole talk is about pro diving. So, and the other side of the story is, you know, actually the evolution of the front end, if you will. And, you know, what's funny about this picture is that that's literally my evolution. Because I've gone through like, you know, pure JavaScript and jQuery, you know, then Angular and eventually got into Ember. And so if you combine the two together, what you have is, well, Ember on fire. And so Firebase, you know, kind of has some limitations like, you know, the rest of us. And so the maximum number of like child nodes you have is about 32. So, you know, it can go beyond that. And, you know, the key that you have can only be up to six, eight bytes, which means you can only have limited number of keys, because eventually, you know, grow out of, you know, possibilities. And, you know, one shout out can only be 10 megabytes because they store the whole data as, you know, Bay 64 encoded binary data. And so, you know, things like, you know, 100 million noise in the operation. But know that really stops that. And you can, you can have, you can write data from SDK in the 16 megabytes and tops and or from the rest, you know, it's up to you. But if you don't like any of them, because my whole idea of this talk is to provide a different perspective, right? Because most of the previous talks about controllers and we talk about, you know, all this kind of a traditional Ember thing, whereas the way I would tend to build things, I would just build a bunch of components and services, and I would just wire them up, you know, with the router. Like I wouldn't use controllers or avoid them all together, no injectors, you know, and I'm kind of like very Ember 2.0 future looking. And so, and so if you have a Firebase object, like in the whole SDK, and you don't want to use either of them, what you can do is just monkey patch the Firebase object with 20 lines of code, which essentially converts it into an observable. And so, and so what that allows you to do is essentially treat this the whole thing as an observable. And for the purposes of prototyping, it essentially allows you to, you know, build collaborating drawing apps in like four lines of code. I wrote this like literally in four lines, and it's just a bunch of observables, and they, in going through some pipe, pipe through some filters, and eventually just, you know, start some data on the Firebase. And, you know, what you have is literally, it's just kind of, you can open like as many windows as you want, but, you know, it's kind of a, so things like open data sets as well, like Firebase, and, you know, lots of other places, they provide a lot of data that's open, and it's free, it's real time, you know, anything from, you know, airport delays to airquays, you know, cryptocurrencies, it's kind of the goldmine for prototyping. If you're trying to build something, at some point you're going to have some data, you know, to show off. And so, you know, what you could use, you know, you end up with projects like that, which is essentially all, all San Francisco, buses in San Francisco that, you know, in that radio, and one of my staff workers actually is, you know, trying to port us to London, because it's like, you know, every time I'm waiting for the bus, it seems like it's either late or, you know, never arrives, and, you know, create a domain, you know, where the hell is my bus.com, and just put it on every, you know, bus stop, so people can just go and have a look. But, you know, the only way, the only way, you know, this kind of thing is possible is because you have all the back and handle it for you, and you have all the data provided in real time, so all you have to do is just connect, you know, together with the few lines of code. And so, you know, instead of, and, you know, like, another point of that, like, instead of rest, you could either just write light, not workers, or just use Zapier, and that's what I've been using so far to prototype a lot of stuff, especially like things like hacktons, and, you know, even if you're at work and you need to come up with some, you know, decision, how you're going to go about this particular problem, the best way to come up with that is to, you know, build a few prototypes and see which one, you know, performs better, or whatever fits, you know, your criteria. And so, Zapier, for example, it has, I don't know, hundreds, it's not thousands of integrations. And so, just with Firebase alone, you have, well, you know, literally in, you know, three, four digits. And so, what it allows you to do is you can pick any integration you want. And, you know, in this particular example, you know, I just, I just picked email, for example, you want to send an email and you want to, you don't want to build a whole backend for an APS service. So, you know, if you just created the record in Ember, and, you know, saved it to the Firebase, that would essentially trigger the Zapier. And the way, the way it would happen is you essentially register from the account, it's free, and, you know, you just put in the Firebase account, URL, you know, it's simple as that, and then register for a mail gun or mind drill or whatever your source provider says, just check in your APIs right there, you know, and then URL, and then set up some some, some kind of events. Because those things that I've recorded here, they automatically become accessible in here. So, you know, if you're trying to send something like personalized email to someone, that's unexpected. Right. So, yeah, you can, you can basically select what you want, you know, it's deducted from what you recorded. And so what it allows you to do is to, you know, have whatever service you want running in literally, you know, in seconds, 50 minutes. And so, you know, what you end up is, you know, in a record, you can pick stuff up. And obviously, you can test this, the whole thing. And they provide very nice interface for that. And so, but it's Firebase good just for prototyping, you know, because that's, that's, that's kind of like, that's, that's how usually people start. That's kind of how I started. And so, you know, so the only questions, because those all, you know, it's only good for prototyping. And then some people say, it doesn't scale, or, you know, it doesn't have the features to handle, you know, all these other things and, you know, complex problems that they have. And so, I just like to have a look at it and say that, especially since the recent developments that are happening, and Firebase being brought by Google, and they do provide backups to all the people who are scared of losing their data, if you will, or just not having, you know, like, like, what if, what if Firebase goes away, you know, on all these kind of things. Although not likely. I mean, they do seem to be very active in hardware as well. I have been to the talk of, of Resin. And basically, it's, Resin is like Heroku, but for hardware. And so, if you combine that with Firebase, you can, you know, you can essentially build, well, an illusion of hardware products. And so, because what, what Resin does, it obstructs away all of the, you know, from writing code to deploying to all of your devices. And so, what you end up with a system is like with Tesla. Like, when Tesla reads their cars, and they had, they had like a flaw, right? What does Toyota do? They just recall the whole fleet, and just, you know, go into massive, massive loss, you know, millions. What Tesla did just pushed a firmware update over the wire to all the cars that are unavailable. So, like, Resin kind of allows you to do that. So, you know, even after you've sold your devices, or, you know, that kind of stuff. And Firebase, and I'm just linking to the blog post here, essentially, they allows you to sync everything between these devices without you actually managing it, you know, in a way. And so, and because especially since they are going into the hardware and all this pervasive thing, it provides nice security features. And so, so essentially, you know, you could, you could say it's like a full stack backend, if you will. And, you know, obviously, they're probably one of the biggest concerns is mobile. And so, you know, people always, you know, it's kind of like a big, huge topic right now. And everyone is always concerned about this. And they're always, there's like this massive war between, you know, native and JavaScript and the WebKit. And, you know, and this talk I've just been to, it's literally with the service workers, they managed to bring down the whole thing to, like, you know, nine seconds. And you can be able to interact with content, like literally, you know, after .2 seconds, because as everything else is being loaded. And so, I mean, and all the things that Miguel talked about, you know, in a previous startup, it's like, it's like, it's like, so, it's not, it's not just, it's not just, like on the backend, it's a full stack, it allows you to do all these things. But also, if you combine with all the other technologies that are out there, like service workers and animation API, you can essentially, you know, build anything at incredible speeds, which is kind of good and bad in a way, because that means competition is pretty, pretty high because the lower bar is quite entry. And so, you know, I figured I'm just going to give some examples of how Firebase tried to handle the, you know, is it just for prototyping kind of question. And so, I have used to in the past, but basically, they have, you know, work was they have the graphing libraries, they have integrations with the elastic search, and, you know, ability to essentially import like ridiculously size JSON files into the Firebase itself, and using as a storage. And so, what you end up with is an architecture that looks very much like this, where, you know, you're essentially providing all of your clients like kind of real-time thing. Like, it doesn't matter where you go these days, everyone expects stuff to kind of happen real-time in push notifications. And if you go to, you know, companies like Diff Show, they provide webhooks for push notifications, you know, to all of the clients. And, you know, so, especially like going forward, and like, you know, British Gash when they talked about it, and, you know, because you don't have to throw the page over time, you can get to the quote and, you know, X number of seconds. And I think it's kind of becoming increasingly more of a trend, especially since we're having all this internet of things coming along. And, you know, your toaster's a computer, and, you know, your fridge is a computer. And all these things, they, you know, they want to be kind of connected. And so, you know, at some point, you end up building applications, not just for, well, the web, really, but like for everything. And there's quite nice projects like NW, the JS, and, you know, things like that, which essentially allow you to, you know, use Ember to build desktop apps. And so, you know, things like SilentJS and, you know, Join U5, and all, like, they essentially allow you to use JavaScript on everything. And, you know, considering the recent developments, you can actually get to a really, really, you know, quite nice performance on, you know, almost matching or better than native. And so, I mean, I'm definitely a big believer in that, is that when you have very, very, very high concurrent applications, which is why you have, like, channels and go, and, you know, all these other things. It's like, state kind of becomes, it kind of, you know, the thing that British Gas talked about, fat controllers, you know, is exactly that kind of performance. When you have, and it's pretty much a kind of a limitation of human brain, in a way, is that you just can't handle this much of a complexity in different things that happen at the same time. And so, abstracting your way of thinking and your way of writing code is kind of important. And, you know, I truly believe that using things like Firebase and, or BOS, listen back in as a service, you know, allows you to essentially focus on the value that you're providing, as opposed to, you know, doing the DevOps stuff, you know, or worrying about, you know, what configuration they have and, you know, what kind of, you know, like load balancing stuff. You know, there's startups that provide load balancing as a service. And so everything becomes more and more commoditized. And like since the beginning, it's becoming desegregated from the hardware. So hardware just becomes like, you know, you can just off the shelf kind of, kind of the idea. And so, probably the best example I've heard is there was a talk, and the city of Netflix was talking, and he was like, you know, saying how you're using SSD now, and, you know, and all, you know, to improve the speed. And so this guy at the end that says, he started like a big rant, how, you know, how SATA is much better, more stable, more robust, can store more data. And the whole round was like, I don't know, it was like 40 minutes, right? And the student just, you know, stands there, and he just, just listens, listens, listens. And like at the end of this rant, he's like, I don't care. I rent them. And so, you know, and you can see like, you know, one of these ninja movies, which just slice you like that, and it then takes like two seconds, and you just slide off. Half like that. So, you know, I think it's kind of, it's kind of to summarize the whole talk about, about like, it's all about, you know, regardless whether you're prototyping or you're building something in production, it's usually, you know, the first to the market wins. And it's kind of, you know, get the first passion out. And, you know, it's kind of a bit of a prototypic along the way is going to save you a lot more, you know, towards the end of it. You know, in terms of like, you know, what decisions you have made and how much they affected you, you know, in the future. And so, yeah. There's Ember Fire. If you're doing crowd operations, it's, it's really good. It became, became really good probably like, when I started doing ever, which is like six months ago. It started becoming really good in terms of, you know, when the first started out, Ember Fire had its own syntax, but there's now, they just use Ember Deer syntax. So, there's no new syntax to learn. And, you know, it's been like ridiculously active in terms of, you know, development and those kind of things. For, for examples in the beginning, I, you know, if you're doing something like a drawing app, crowd is a bit, is a bit, you know, is a bit of a, you have to kind of wrestle with a bit. So, you know, it's, I just use pure Firebase. It really depends what you're doing. You know, if you're, if you're, if you're, if you're using it by data, Ember Fire is definitely the way to go. Yeah. Yeah. Yeah. Well, I would tend to start an apps with, with Firebase, not to use like, you know, pretend there or Ember Sound Grid because, because Firebase copies the data from your front end. So, you don't have to implement the whole thing twice. So, you essentially have like a, you know, it's kind of, I think what the future should be is like, why would you have to implement every single piece twice? You know, in the back end, the same thing in the front end. And the Firebase kind of Olivia is that, because it just allows me to, and it's very easy to, to switch. So, like, if you built the whole thing and, you know, Firebase just switched the adapter. And, you know, now you're using Grails API or, you know, another API or whatever. It's like, the everyday that makes it very nice to be able to switch to different APIs without barely any code change. How would you tend to handle file upload in a prototype with Firebase involved? Say if I wanted to store my files on S3, for example, and then save in URL or something like that in Firebase, how would you, what set up would you go for that? They're coming with a feature that essentially allows you, well, they're building S3 for Firebase to solve that problem. But, you know, right now, it probably just uses S3 or something like that. You know, there's quite a lot of integrations where you would just store the URL on Firebase, you know, but the actual file, you know, on S3 or, you know, some other hosting service. They are building, I don't know, they haven't announced it yet, but they're going to have, you know, the whole conversion to Temnio and the whole thing. Yeah, it's like Firebase, but Facebook bought it instead of Google. Do you have a real time functionality in the Firebase service? No. Firebase isn't as full stack as, well, personal as full stack. Like, in terms of latency, push is probably the best, but they only provide web sockets. Whereas in terms of a number of features, Firebase is definitely the best. You know, in terms of, like, because that's the whole idea about prototyping and building things as quickly as possible. And, you know, eventually, you know, you could potentially scale Firebase or switch to something else. It's just to build as fast as possible, as quickly as possible, as little as possible. And so, you know, it improves your decision making. It improves, you know, your ability to prototype stuff and, you know, build from there. It's kind of like, you know, for frameworks, which one to choose? You just build some applications of all of them. Then you pick one, right? Instead of just picking one, you know, you're going to make more of a decision. So, same thing. It's kind of, for me, it works to prototype stuff, like, you know, to build this stuff. And would you do it that way or that way, you know? And so, you know, which one will be faster? And which one, you know, you just build quick prototypes to decide which way you want to go. But, yeah. It's really gone uneasy. A question. If we use back end as a service, does that make us cheap? I mean, I mean, you technically, using back end as a service, even if you're buying stuff on Amazon or Rackspace, because you're buying, you're buying some. Well, you know, I just don't, like, yeah. It's just, you see the standard corporates, the corporate environment as well. Like, people who are now switching to EC2 or whatever. They stop having their own cyber box. It's always my cyber box, you know? Like, and they're building less secure systems than what EC2 would provide. Like, it's, I mean, it's work from corporations. It's insane. Like, they think they're more secure, but they're not. It's just, you know, it's like trying to build their own number from scratch. Probably, you know. It depends on the organization. So, some of the clients I work with are in control, and those have certain data where they need to be much more aware of what's going on with that data. And then using a service like EC2 or Firebase or whatever is easy and flexible for them because the risk of data loss or any sort of elk ride because of it is very low. Yeah. I mean, I think I've said this before, but I truly believe that everything in the middle will disappear. You know, have like, you know, interdevelopers or in agencies, and you have like, you know, infrastructure providers like Google, you know, or some clients you work with. And, you know, they provide the back end of the service, and the developers provide the innovation part. And everything between can't compete with either. So, they're just, you know, going to die out. Because you can't compete with Google, you know, infrastructure on scale, and you can't compete with any developers for innovation. So, you know, it's like, and so this is kind of like, you know, this is if you're any developer instead of you're building Google. Can I get a show of hands who's using a platform as a service like Firebase in an app today? And everyone else, you're building your own back end infrastructure with Rails or .NETs or something like that. Lots of those are stuff because our data is in the data center. They're obsessive security. Even trying to get hold of that data, you have to go through three different layers to actually get to it. So, the idea would be to use Firebase. I would be looking at Firebase to for real-time. And that real-time service to a customer is great because that's that's what you want to see. You want to make a change to your go really crazy, you know, easy stuff, you know, like I want to change my tariff straight away. You want to say that and then you're back on your site. You want to see the prices change. You want to know straight away. You don't want to wait like our back end systems do to date or two weeks or whatever it is. You take to that process. So, you'd want to have something like Firebase, but it's, again, we have a limitation which is security. And they're obsessed. They are, like, legally obsessed with the firewalls and which the data is going through the firewalls. And that's what I think this issue is. We can convince them, okay. That's always the opportunity to get rid of it. They're going to move, aren't they? There's a contention around personal information. Yes, it's DPA, data protection. You don't want to be giving that all that stuff away. And this is where it becomes an issue. So, Amazon, we've been looking at using Amazon as a, again, as a place to get the stuff up quick, get the servers up, running. As soon as you start saying, well, you've actually got to now make sure that the firewalls are all protected. A lot comes out. PCI compliance, you stop and then it starts loading on the services. You start loading on the extra services. They exist. You can buy the extra service on it and you start actually costing it up and it's actually more expensive up to a point. It's up to, when you're not, I'm not saying it started to worry about DPA, but most of all, and once you start crossing over into corporates, data protection, PCI compliance, Amazon, they are compliant. We've got compliant systems, but then if you then don't follow the rules, a compliant system can uncomply very, very quickly. For example, back in its service, brilliant. We were looking at it a while back, and it's just that extra level that kills us. Because we want to be fast. We want to be quick. We want to be innovative and Firebase is great. And we use Apogee. Apogee was a brilliant thing for building our first APIs. It was a proxy, very, very quick. It exposed our crappy APIs that we'd build in the post and get servlets. Very, very quickly, we build up an API and build calls into it. Apogee, brilliant. You say, oh, I want an enterprise version of that. It's about segregated our new PCI compliance through it. The cost went from zero, which is what Apogee was, the free version, up to £100,000 a year. Just go from no security, enterprise security. And it's all running on AWS. Apogee runs in AWS, but they've got an enterprise version of the enterprise version, £100,000 a year. Brilliant to print site. Pretty expensive, so you actually start to actually look at it as a corporate, more fortunately. Good for Princeton. You still use it, but that takes. All right, any more questions? Okay, give them a hand.