We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Cloud beyond scaling

00:00

Formal Metadata

Title
Cloud beyond scaling
Subtitle
Realtime applications on the web with AngularFire and EmberFire
Alternative Title
Cloud beyond scaling: realtime webapplications
Title of Series
Number of Parts
170
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The cloud is more than just AWS vs Azure, scalability and big data. In this talk we will take a look at how BaaS offerings like Firebase can make it a walk in the park to build realtime collaborative applications. We will cover the building blocks for doing this, as well as how it fits in nicely with frameworks like Angular and Ember. We will also talk about why this is valuable and hopefully leave you with enough knowledge to be inspired about possible usecases in your own business.
Scaling (geometry)Real-time operating systemKeyboard shortcutComputer programmingFormal languageComputing platformSoftware developerCollaborationismFront and back endsOnline chatClient (computing)Message passingFunction (mathematics)LogarithmSoftware frameworkService (economics)Computer programmingScaling (geometry)Endliche ModelltheorieBitExtension (kinesiology)Software developerWeb browserType theoryDomain nameProjective planeWeb 2.0MathematicsMultiplication sign2 (number)Web-DesignerReal numberCASE <Informatik>Cloud computingReal-time operating systemCartesian coordinate systemNumberDigitizingSoftware testingState of matterWebsiteAuthenticationComputing platformArithmetic meanScalabilityMoment (mathematics)SpacetimePhysical systemBroadcasting (networking)Dynamical systemElectronic mailing listPoint (geometry)Message passingCollaborationismOrder (biology)Client (computing)Different (Kate Ryan album)DatabaseWindowProcess (computing)Level (video gaming)Information technology consultingAngleServer (computing)Programming languageUniform resource locatorNatural numberPairwise comparisonFront and back endsWeightSystem callBookmark (World Wide Web)Greatest elementJava appletComputer animation
Set (mathematics)Query languageEvent horizonType theoryMach's principleExecution unitCommon Language InfrastructureJava appletAndroid (robot)Function (mathematics)Video game consoleServer (computing)Client (computing)Revision controlDatabase transactionFluid staticsComputer fileTime domainContent delivery networkContent (media)Web-DesignerKeyboard shortcutSoftware frameworkDatabaseComputing platformHookingUniform resource locatorCartesian coordinate systemGreatest elementFluid staticsContent delivery networkEvent horizon1 (number)WeightTouch typingAssociative propertyMathematicsWeb pageMultiplication signCASE <Informatik>Domain nameSlide ruleSystem callCodeData structureServer (computing)Java appletType theoryTouchscreenPairwise comparisonCategory of beingProduct (business)Web applicationComputer fileDatabase transactionQuicksortBlock (periodic table)Client (computing)Android (robot)Formal languageoutputComputer configurationSubject indexingBitRevision controlBuildingBit rateDemosceneDemo (music)Process (computing)Line (geometry)Web 2.0Basis <Mathematik>Right angleService (economics)Electronic mailing listLevel (video gaming)MereologyComputer animation
GoogolAnnulus (mathematics)Computer wormGame controllerScripting languageoutputDemo (music)Function (mathematics)Video game consoleSoftware frameworkKeyboard shortcutCodeInclusion mapMessage passingObject (grammar)MathematicsPlug-in (computing)Keyboard shortcutMereologyFunctional (mathematics)Endliche ModelltheorieTemplate (C++)Cycle (graph theory)DemosceneSpacetimeView (database)CuboidBitWeb browserComputing platformExpressionReal-time operating systemTrailSoftware frameworkAxiom of choiceCodeModule (mathematics)Data conversionMultiplication signCategory of beingCollaborationismDatabaseWindowSpeicherbereinigungGame controllerWeightCartesian coordinate systemSlide ruleMessage passingMechanism designCASE <Informatik>Complete metric spaceLine (geometry)Free variables and bound variablesDifferent (Kate Ryan album)InjektivitätGoodness of fitInstance (computer science)Observational studyClient (computing)TwitterAngleSingle-precision floating-point formatDot productProcess (computing)BuildingServer (computing)Web pageDirection (geometry)Data miningData storage deviceRight angleComputer animation
Message passingOnline chatEmailDatabaseEndliche ModelltheorieMessage passingView (database)ImplementationMultiplication signComputer animation
Real-time operating systemScaling (geometry)Well-formed formulaScripting languageMessage passingGroup actionoutputFunction (mathematics)Data modelProcess modelingServer (computing)CodeInclusion mapExtension (kinesiology)Software frameworkEndliche ModelltheorieMessage passingCartesian coordinate systemType theorySingle-precision floating-point formatView (database)Line (geometry)Sampling (statistics)WebsiteNatural numberCodeGame controllerCategory of beingGroup actionSemiconductor memoryCASE <Informatik>MereologyCore dumpNumberPoint (geometry)Computer configurationRoutingDifferent (Kate Ryan album)Web pageUniform resource locatorSerial portEntire functionComputer animation
Software developerMobile WebComputer animation
Endliche ModelltheorieKeyboard shortcutGame controllerData modelQuery languageElectronic mailing listSocial softwareGame theoryGraph (mathematics)CollaborationismReal-time operating systemService (economics)Pairwise comparisonCartesian coordinate systemConfidence intervalBitCASE <Informatik>CurveDemo (music)CollaborationismHypermediaWeb pageLine (geometry)Different (Kate Ryan album)Internet service providerMathematicsType theoryMultiplication signGame controllerReal-time operating systemExtension (kinesiology)RoutingData modelMagnetic-core memoryComputing platformSampling (statistics)Front and back endsLogic gateDecision theoryKeyboard shortcutRevision controlPhysical systemMessage passingSoftware frameworkAnalytic setEndliche ModelltheorieGame theoryBuildingData structureGraph (mathematics)Collaborative softwareTablet computerWhiteboardElectronic mailing listVideo gameUltraviolet photoelectron spectroscopySingle-precision floating-point formatComputer animation
Demo (music)Decision tree learningExplosionWeb pageGamma functionHardware-in-the-loop simulationGreatest elementStructural loadWeb pageCASE <Informatik>Real-time operating systemCodeNumberEndliche ModelltheorieSampling (statistics)Projective planeView (database)SpacetimeTable (information)Computing platformFlow separationWeb browserDatabaseGraph coloringElement (mathematics)TouchscreenComputer animation
Scalar fieldView (database)WindowTunisAddressing modePort scannerClique-widthPointer (computer programming)Annulus (mathematics)SummierbarkeitElectronic data interchangeData modelGraph coloringMathematicsService (economics)BitData conversionEndliche ModelltheorieGame controllerKeyboard shortcutGraph (mathematics)Functional (mathematics)Graph (mathematics)Software frameworkDatabaseCASE <Informatik>Grass (card game)Category of beingMereologyComputer animation
Computer hardwareComputing platformReal-time operating systemPoint (geometry)DatabaseCASE <Informatik>BitUniform resource locatorSampling (statistics)Complex (psychology)Type theoryReal-time operating systemComputer hardwareAngleFamilyMathematicsComputing platformLimit (category theory)Computer clusterData storage deviceWebsiteScalabilityWeb 2.0Socket-SchnittstelleCollaborationismScripting languageGoodness of fitComputer configurationFormal languageDimensional analysisRegular graphService (economics)Installation artFocus (optics)CuboidInstance (computer science)Vapor barrierComputer animation
Transcript: English(auto-generated)
So, now I think it's time to get started. Thank you all for coming. I know it's tough to get people to come to each individual talk because there's a lot of awesome talks going on at the moment. So I'm glad to see you guys here.
As you hopefully know, the topic is kind of my look at cloud beyond scaling and some of the stuff that you can do utilizing the cloud beyond some of the stuff that you've probably already heard a thousand times by now.
So, this is me, just a short introduction. My name is Christian, and I'm a Danish developer, and I've been for nine and a half years by now, mostly working in .net with web development and, well, for most of the time doing e-commerce sites
but also working along with BI consultants and so on and doing some stuff in that space. The agenda for today is that, first of all, I'm just going to talk a bit about what I mean with this whole beyond scaling thing.
And then I'll talk a bit about real-time on the web and kind of what that means in the scope of this talk. Then I'll give a short introduction to Firebase and then look at some of the ways that you can work with Firebase
along with some of the frameworks that you might already know. So covering a little bit of Angular, then showing how it wires up with Firebase, doing the same thing with Ember as well, and then finally we'll look at some use cases that you guys can hopefully have for technologies along these lines.
Well, starting out, just so you get the whole story, I used to work at a company where we, like probably a lot of you, were starting to move to the cloud, and being a .NET shop, that meant moving to Azure.
And that was kind of what we were doing with all of our new projects and also with some older projects that were kind of in a state where it was possible at the time, I would say. And the basic idea starting out was,
as you've probably heard a million times at different talks, about scalability, elasticity, about how you could outsource hosting and get fast provisioning, which is all very awesome. But at some point we also got to talking
if there was more business value to get from this. Not that I'm in any way, you know, not thinking that the cloud in and by itself provides a lot of value, but we just felt like there was more to get out of this whole switch.
And one of the places we started looking was in these backend as a service, in that space, you could say, of cloud technologies. And kind of some of the things that were resonating with us was the idea of, for some types of projects,
being able to do some kind of rapid development and also combining different clouds, not just being with Azure, but also seeing what others could provide in the same space. It was also about kind of not having to stick with either Windows or Linux,
but being able to use the best tools out there no matter where they ran. And also, to some extent, getting beyond having to work with people because of their favorite programming language. Why should that matter?
If the domain is interesting enough, if whoever you're working with knows enough about a certain domain, they should be the people to work with, not just because they are C-sharp developers, Java developers, or whatnot. So, yeah, that was kind of some of the initial thoughts in this.
And of course, still being a .NET shop, we started looking at Azure Mobile Services, which is definitely interesting in and by itself. But it's also very much the straightforward use case,
you might say, for back-end as-a-service systems because it provides you some way of working with data that is simple, provides you with authentication and push notifications, and some kind of services for recurring jobs, which was pretty much the same types of applications
that we were already building. So it certainly has its use cases, but, again, we were looking to do something a bit different. So we stumbled on nobackend.org. I don't know if you guys know this site at all. But it covers some of the different platforms out there.
And, yeah, we had a look across some of these and found that there were actually some really interesting ideas amongst those that could also enable us to do new types of applications. One of the things that kind of caught our interest
was being able to work with real-time data. At the time, I was working a lot with BI people and making sure, basically, that companies were allowed to see their data real-time and kind of navigate their company based on that data.
So it needed to be as current as at all possible. And just going back a few years, really talking about real-time on the web, that was more or less about refreshing the browser each X number of seconds, right? So we didn't really have anything to do in that space.
Of course, the natural thing for us, again, being a .NET shop, we did look at SignalR, which is really awesome in this space and in doing real-time collaboration
and in working with WebSockets. And it's fairly easy to get started with. This is pretty much all that you need on the server side that you inherit from a hub. And then you implement your messages. And then, through Dynamics, you get the ability
to call your clients and broadcast messages and so on. And at the same time, on the client side, you can connect to this hub, call the same messages, and, of course, react to messages coming back, as you see here. And even though that's all nice and well,
then it does take quite a bit of plumbing for some of the cases that we were looking at, really, because you still need some way of hooking up a backend and working with your models and doing all the stuff that we're used to.
And that was when we stumbled on Firebase. Has any of you heard or used Firebase before? So I only see one hand. That's not a whole lot. But, yeah, that's awesome, because I am going to pretty much take you into the bottom level of this.
But, yeah, the whole idea of Firebase is to give you a really easy way to work with data real-time. So the basic concept is that if you think of everything in the database as being an endpoint that has a URL and everything being structured
in kind of the same matter as a JSON document, then in that regard, it is very similar to a lot of other databases that you've probably heard of, but that is pretty much where the comparison ends,
because when you start working with it, instead of just querying a node or doing some type of query like you're used to, then the idea is that you subscribe to some node in this model that you're working against, and then when changes are done to the model,
you have an event that is fired, and you can react to these changes. So basically doing all this is extremely simple, which was one of the first pleasant surprises I had looking at this,
because really what you see on the screen is all you need to know of the API to get really, really, really far. So basically you have a couple of ways of putting data in. In this case, I'm sticking with the JavaScript edition of the API. They are in other flavors as well.
But basically you have a way of setting data. You can set it with a priority, which is pretty much specifying the index so you can sort things if it's an array you're working with. And you can push data, which just creates a reference, and then you can optionally pass that a value as well.
So it's just a way of making it easier to deal with lists. And then you also have some querying capabilities that you can say that you only want items starting at a certain priority, and you can limit it to a certain priority. And then basically the most important thing of it all
is that, like a lot of other APIs, you have this on method that allows you to subscribe to different events. And all the event types are the ones that are listed at the bottom. So basically the value event
is always called when you hook up to the database. So it gives you the entire data object that you're referencing. And then you can listen to when children are added or changed or removed or just moved around the structure.
And in those cases, you'll get a snapshot back instead of the entire thing. And also, when you get started, the documentation is actually pretty good. They have some really nice examples and some quick starts.
So I was fairly surprised that it didn't take more than 5, 10 minutes that I had the first thing running and was actually able to start thinking about the problem that I was actually trying to solve, you know, the business problem. And, of course,
actually I left this slide out the other times that I've been doing the talk because I have no association with Firebase as such, so I didn't want to, you know, get too much into the whole sales thing, but people have kept asking. So I just put in this slide just to give you some idea of what it costs to get started.
And basically, you know, I think this is fairly cheap and is definitely affordable for most types of products and especially in comparison to other databases. Kind of in the same category,
just to give you a little bit of a look behind the scenes, then the technologies used to build Firebase are Scala and Netty and then JavaScript and Node.js. So it tells you quite a bit about it all being, about being reactive and about building a reactive framework,
which is what it is. As I shortly mentioned earlier, then there are quite a few APIs for working with Firebase. So no matter where you're coming from, I would think you have some option of working with it. The big obvious thing, of course,
is web development and doing this in JavaScript. Along the same lines, you would have an option of doing a server side with Node.js. They also have an API for iOS and OS X, Java and Android. And then if all else fails, there is the REST API, which is still really, really simple to use.
So it shouldn't be a stumbling block to anybody. But of course, we all like to see the API in the language that we're proficient in, right? And actually, after I started speaking about this subject, I got in touch with a couple of people at Firebase and they told me that .NET is actually on their roadmap.
So it's also coming to my own platform eventually. And well, actually, just while I remember to say so, again, even though I'm not associated with Firebase, they were kind enough to send me a bunch of stickers. So if you guys want some swag afterwards, have them up here with me on stage,
which they were kind enough to allow me to do. So getting back to the coding part of this. As I mentioned before, then working with Firebase is pretty much a matter of signing up. Then you get a URL that you are pointed to.
And then you can create a Firebase reference and then set values on it and, of course, listen to all of these events. So listening to the value event that will always be called and then the child added, child changed events, and so on is no more work than what you see here.
And with regards to transactions, which is probably an obvious question that some of you will have, then the kind of the general idea is that they try to run your changes locally right away.
Then it tries to commit it to the Firebase servers. And, of course, if that is successful, then the call back is called. And if there's a conflict, then the client will receive the new value and the transaction will be rerun. This is working fine for at least all of the cases I've been using it for.
And as a kind of side note, they started also providing their own hosting platform quite recently, actually. So I'm not even using it for my demos, even though I've been looking at it shortly.
But Firebase Hosting is basically a way of getting all your static files served. So it gives you a way of serving them via HTTPS. And then you get a CDN and you can choose your own custom domains and so on and use it with no tooling.
So it is extremely simple. And I would actually bet that quite a few applications will only need static pages because you'll just be serving some of the JavaScript that you'll be writing and then a bunch of HTML and CSS pages. So this is really, really kind of a lean way to get started
without the hassle of a vast platform when you're not in need of such a thing. Well, just going back to the story that I went through,
then when we started looking at these things, the shop I was coming from was at the same time moving from working with WPF and wanting to do more web development. And it kind of makes sense in this day and age because we want to target every platform out there.
And as of today, still the only way to truly write once and run everywhere is still writing a web application. And for a lot of our customers, we didn't really need native support. But one of the concerns that a lot of people who had been working with WPF for a long time had
was that they would kind of miss out on two-way bindings. A lot of these people have been working with earlier frameworks where they didn't have two-way bindings and they thought it was a pain always having to kind of write your code twice mirrored, if you could say it that way.
So they were really kind of afraid of going back to that. And it was actually a kind of something that we had to take into account when switching to the web. And first off, then, when you're looking at two-way bindings on the web,
then there's kind of two ways of going about this that the frameworks out there use today. One of them is wrapping each of your properties so that when you, instead of calling the property directly, you call a method. And then that'll make sure that it is, well, it uses some publish-subscribe mechanism
to make sure that your changes are propagated. And the other way around is to watch your model for changes. And in that way, you can avoid having to wrap your objects and that way change that things go from being properties to being methods
and that you have to do this whole conversion every time you pull data from the server, which, again, depending on what you're building, in some cases might actually be a bit of a nuisance. But, yeah, Angular does the latter, and frameworks like Ember, for instance,
which we'll also be looking at, does more of a wrapping kind of thing. So, yeah, we ended up going with Angular after having looked at this space for quite a while. Basically, part of the reason for that choice
was that it was really starting to take off. It was nice to have a platform that we knew was backed by a fairly big company, so we felt fairly safe that it wasn't going away. And even though a lot of people said at the time that we didn't really have any winners yet
with regards to which platform people were going to choose for doing single-page applications, then we were starting to see a trend, as you can see on that slide. And actually, later on, I've become even more confident that a lot of good stuff will still happen with Angular,
as Rob Eisenberg lately joined the team to implement some of his good ideas from Gerandle into Angular as well. So, yeah, I still think it's a good platform if you want to use a framework. And just for now, keeping me out of the whole discussion of whether you want a framework or not.
But in that case, it's a good way to go. And, yeah, how many of you have worked with AngularJS? Okay, fair amount of you. So basically, this is just to get everybody on board. And this is pretty much the simplest thing
that you can do in Angular. And as you can see, this just has a placeholder where I can put a name in my template, which is kind of marked with having this controller,
which defines a certain scope that we are working within that our model will be contained within. And then you'll have to declare that controller in code as well. The simplest way of doing that is just having a function that is named accordingly.
And then through dependency injection, you can kind of acquire different things that you want to use from the Angular framework with the basic thing you'll pretty much always be needing, being a scope, which is where all your functions
and all of your model will be bound to. So in this case, I just set the your name that I was displaying in the template to my name. And then I add a function that allows me to show what is in that and then add that through what is called a directive, which is ng-click, which wires all that up.
So I'll be able to call that function when pressing a button. And getting in a little bit deeper with this, the way that this works in AngularJS
and the reason that it's actually so simple to work with and that you don't have to do anything yourself out of the box to work with this is that they have this watch apply digest cycle. And, yeah, basically you can also access this yourselves.
And the idea is that you watch some part of the model, some property, and you can either do that by specifying the name of the property or by a function, which just returns that value from the scope,
and then passing in a handler for what you want done afterwards. And then you can apply changes to a model in kind of the opposite way, if you would call it that, that you can also pass it this kind of expression or you can pass it a function that you want to apply.
And this all allows Angular to keep track of what changes are made to the model and then doing its magic behind the scenes. And it does this through what is called a digest cycle. So basically you can call this digest method yourselves,
but I pretty much took it in here for completeness sake because as with garbage collection in .NET or things like that, it's not normally something you would call yourself. It just goes on behind the scenes. And then building on that,
and then once we had that kind of knowledge build up in-house, we were starting to look at AngularFire because we wanted to utilize Firebase, and even though it's already fairly simple to work with, we might as well look at these kinds of plugins that makes it really, really trivial. The basic idea is that you go from having this two-way binding
to actually having three-way binding. So now you can bind from your view to your model that you're working with to a database. And essentially what that gives you is a real-time application, right? Because if I make a change in my browser
and that is propagated to the database and the database makes sure that it's propagated to all the clients, then we're done. And we can all be working on the same model in real time and collaborating. And it's, yeah, to me it was just, you know, astounding how simple this really is,
that we're all used to working with two-way binding and pretty much just add a concept of binding this model to a database, and now we have brand-new capabilities that we weren't able to work with before, really. Once you get started with AngularFire, they also have a pretty good documentation by now
and also some really good examples. Again, getting up and running with this is a matter of minutes, so I really encourage you to try it out yourselves and just give it a go. But I also want us to try it out right now
if you guys are up for it. So, yeah, just a short run-through of the code. This is a little deeper than the Angular stuff we did before, because in this case, I first off declare a module, then I import this Firebase module as well
that I need to use, then I set up my controller much like I did before. This is just the real way of doing things because if you just write a function, then when it gets minified, then the variable names change, and then your dependency injection goes out the window. So this is basically what you do working with Angular.
And then you can get your scope injected as before, but you can also get this Firebase thing. And once you have that, then you can create your Firebase reference, and then you can write a function that just adds a method
for adding messages in this case. So, again, really, really simple, and especially for you who have been working with Angular, this is pretty much what you're already doing with just a line or two of wire-up,
and then you get a real-time application. So if you guys feel like it, I would like you to try out the application that you just saw. I just put it on that URL. So you guys should be able to see what you are writing.
And here you actually see the Firebase database,
and you see your messages rolling in as things change. If you notice, then when they roll in,
then they light up so you can see which things are being added and if things were being deleted and so on. So you can kind of see what's going on with the database at all times. And this view is just an implementation like the one you saw before, just displaying the raw data.
So, again, really simple way of using this whole conceptual model of working with real-time data. And, yeah, for those of you not holding a phone, this is what it looks like.
So this is where we came from. And even though, as I mentioned before, I didn't end up going with Ember, then I still thought it was a significant point to show you guys that this works equally well with Ember. So you shouldn't kind of let yourself deter
if you have a different framework that you like. Actually, I recently saw that they are doing stuff with React as well, which is also looking to become really nice and really easy to work with. Yeah, even though not being too knowledgeable about Ember myself,
I'll just give a short introduction to the concepts that we need in this case. First of all, then templating is done using handlebars. So where Angular is trying to be very much self-contained, then Ember has a philosophy of using existing frameworks,
which mostly means using handlebars and jQuery. And then the more essential thing and one of the core concepts of Ember is working with routing. That is basically how you structure your application when you're starting out.
So as you see here, first of all, you create an application, and then you can map to certain paths, and then you can set up a model that you're working with on that specific route.
And the whole modeling part is quite extensible in Ember. And kind of allows you to define your whole model, which types of properties you're working with, and so on. And that is actually what is allowing you to collaborate with Firebase as well
in the way that we'll see. So the Ember Fire framework was introduced a little later than the one for Angular, but I think it is starting to get on par, especially because since then, both of them have kind of been taken under the wing by Firebase themselves.
So they have references from their main site, and they also made sure that the APIs aligned more than they did first off. So right now, if you've been working with one of them, you're actually fairly easy to get started with the other one as well. And I think it's really nice that they're kind of taking this entire view
of kind of the market of working with single-page applications and giving you different options. And yeah, as you see, the documentation looks pretty much like what you saw before, and they also have really nice examples to get you started if this is your speed.
Basically, what you're doing in code is that you create this application, and then what you need to do to plug in Firebase is that you use this Firebase adapter, which is just a way in Ember to attach an adapter to your model
so it can do more than just being an in-memory model. In this case, that makes sure it's wired up to Firebase. And then for some of the more advanced stuff when dealing with modeling, you'll need an application serializer as well, which is also just in the package, so you'll just add that as well. And that is all that you need to do.
So again, this shows you how it works in its entirety. So you do the stuff that I just went over, as you see at the top, and then you declare your model. In this case, like before,
I have a sender of the message, who it is from, and a text. And then I define my route with this type of model. And then I declare a controller for it.
And I implement the action that I need, which is, again, to be able to send a message. And then I just work with the Ember.data stuff, as you normally would. And then, of course, make sure to save at the end.
I actually made the same sample, if you guys want to try it out, at this URL. It should look pretty much like the one you saw before.
And of course, these chat examples
are pretty much just to give you an idea of how this works, because you could be doing something a lot more creative than a simple chat application. But really what I want to give you, when you leave here, is just the confidence to try this out and see how extremely simple it is to get started.
And if you're passing chat messages or whatever data structure, it really doesn't change much. It pretty much stays simple and easy to do. So just to do a bit of a comparison
of the two frameworks, then, as you can see from this list, a lot of the differences really come down to the differences of the underlying single-page application framework. But, yeah, now both are officially supported. And the data models align pretty well
after the late changes that they have made. And then it's a matter of, if you like, working with a system that supports the watching or the wrapping version of working with two-way bindings.
And then, of course, there's a matter of size and learning curve. Ember is quite more extensive to get started with, and I would argue that the learning curve is quite a bit steeper for most people coming into this. And then, of course, conceptually they are different because there's a difference
between working with controllers and routes right off the gate and then, or, and scopes right off the gate, or working with routes and models, as you saw in the samples before. Yeah, and then there's the matter of it being self-contained versus having dependencies on other frameworks,
which in both cases has its ups and downs, right? And in the end, both will definitely get you where you need to go. It's just a matter of how you like to get there. And kind of in overview of all of this,
then, of course, these types of services, of backend as a service providers give you will never be a one-size-fits-all. So I'm not trying to advocate that no matter what you are building, you should be doing this or that you should use it as your main store or anything along those lines.
But there are quite a few awesome use cases that you probably weren't able to build just a few years ago. And at least if you were, then it would probably be hard to find somebody who would be willing to fund it because it would be quite a bit of work to get running as smoothly as you can today.
So, yeah, use cases. I've kind of divided that into two overall just to kind of spur some ideas and hopefully and probably you guys have better ideas than I do. So I'm just trying to juggle your minds a little bit.
But, yeah, the obvious use case, as we already saw, was doing chatting and social media and stuff like that. But also when working with sharing data in everyday life, it would be useful to be able to work with grocery lists,
anything where you're collaborating with either the Mrs. at home or with colleagues or what it might be. Then it's obvious that you want to do this real time and not have to update your application all the time to see if new changes run in if you're actually doing stuff at the same time.
Also for teaching tools, you see a lot of places that people to a higher extent try to get taught from home or at least not on premise. Then there might be some awesome situations where you could use it for gaming, of course.
And then being a huge sports guy myself, I'm hoping that some of the betting companies will actually pick up on this as well because they tend to have these platforms where you can live bet and you still end up having a page that is just refreshed and refreshed and refreshed. And this could be done a lot more elegantly,
this type of tool. And then of course focusing more on business type applications and what I've been using it for actually has been working with actionable data, making sure that business decisions are available in real time on dashboards and stuff like that.
And that includes, of course, listening to analytics data and pushing that out using a system like this. And then building graphs, dashboards, and again, collaboration tools, and of course doing customer support
has suddenly become quite easy because you could do something that would start out as a chat application but basically extend it with whatever data you need to provide for your customers to provide the best type of service. And again, it would be fairly straight simple to do. Then I have one last demo
that I want you guys to see if this will collaborate.
And I could use a little more space here.
So this is just a real quick sample that I put together because the actual platform that I was working on, I'm not allowed to just go around and show people, especially because some of the data on there is actually mission critical for that company. So I just made a really simple example
where I'm working with a model in the same way that you saw before. But in this case, it displays data of car sales, completely something I made up. So don't mind the numbers too much. And yeah, when the page loads,
see data pop in. And then I could add some other car. It could be a panda, some color I didn't use already.
And then put in some for this as well. And then once I click, things are updated real time. And of course, if more browsers had been on,
they would update as well and need a bigger screen. The element I just added is added here at the bottom. And even if I go in this direction and choose to remove it again,
then you'll see my data update instantly. And what this kind of also shows is that you'll still be able to work with one model and actually display the data in several kinds of ways. Of course, that is what they're already doing in the database.
But in one of the things I've been working with, we were actually allowing people to, in one view of the page, have data in tables and work with that data. And do updates and kind of, if they had some ideas of certain trades they might make,
then we could do some calculations and push those out. And people could actually be working on those projections and so on while sitting in different ends of the country and having a talk about this. And it all just flew between them in this nice and smooth fashion.
And, of course, you should see the code for this as well. And as you saw earlier, this is still just expanding a little bit on the same concepts as before,
that we have a chat controller. Then we have a repeater that looks at the cars which are in my model. And then I have something that can display a marker for the color that was picked on this thing. And then I have the two canvases that I can bind to.
But, of course, the framework that I use to display the graphs isn't part of Angular or any of this, so it doesn't really know much about these bindings. And that's actually when I show you how to kind of get out of this. And this is just my two-way bound model
for updating these values, as you saw me use before. And then what I do is that I make this service that knows how to get the data for these bars.
So it just does some conversion once I get it back from the database. Because in this case, the data model won't fit completely into what I'm doing. So I just implement a small service that will convert these things. And the same thing for getting the Pi data.
And then the actual thing of interest for all of this is that, again, wire up to Firebase. And I, in this case, use, as you saw before, I explained the watch method
of how you could react to changes being made on a model client-side. And because this is not part of... Because the graph tool doesn't know about these updates,
then I need to do this, that I watch the cars property. And when it changes, then I update my charts. So it's basically all the wire up that I need to do to plug something in that doesn't at all know about these concepts, about this way of working with data,
which I still think is pretty nice and pretty awesome. And then, of course, a function to save it all.
So the takeaways that I hope you guys have from this talk is, well, first of all, to look at the cloud as more than hardware for rent and really look into some of these use cases. This is just one of them and one that I found interesting
and that I've been using. But there are plenty of other platforms showing up that look interesting and give you some awesome capabilities without you having to do much work for it, actually. Also, you know, hope it shows kind of how some of the barriers with working with different languages
has been lowered with using these types of platforms because even though I showed the samples in JavaScript, then anybody could have pushed data to the database using whichever BI they felt like. So it also enables collaboration in that sense. Of course, I hope you learned a bit about Firebase
and how real-time has become really easy and got some sense of working with Angular and EmberJS. And I would be extremely happy if someone actually went home with a good business case. So they would be using this for more than just last.
And that's it for me, unless you have any questions.
Oh, that is pretty much the focus of the database. So as I shortly demonstrated, then you can, you know, limit your queries and in that sense do things. But it is in no way meant to be a data store as such. It is meant for it to be a way of allowing you
to handle changes to data. And that is why in most cases I would still have my regular data store and then have this on the side for doing these things because it still allows me to not have to deal with all the complexities of building a real-time application, wiring that up to a back end, handling all the edge cases and so on.
Oh, yeah, it uses WebSockets and kind of in the same way as SignalR.
It tries to use WebSockets, and if there aren't WebSockets in your browser, then it has fallbacks doing long polling and, yeah, same things as you would see in SignalR. Good point, though, that I didn't mention that.
I haven't been pushing the limits of it, to be honest. But, yeah, from what I've seen, it scales pretty well, and there are some pretty big companies using this already.
But I won't try and guess on any explicit limits. I wouldn't know. If you really have an extreme case, then, yeah, I think you should just try it out. And that's the awesome thing. You can try pushing data to this, and it'll just take you 15 minutes, half an hour, and then you see if it's actually sufficient,
because, you know, at the end of the day, talking about performance is always complex, because there's a lot of aspects. So, yeah, in the end, I would just give it a go and see if it tumbles over.
Yeah, the question was if you could have your own instance installed of Firebase and have it running in your own data center, and you can. Kind of what they initially offer is that, you know,
that you sign up for it, and that is this back-end-as-a-service deal. But you can contact them, and they do have an option where you can actually, you know, buy into installing it in your own center, and they will help you do that. But I think that is pretty much a per-case thing, so they'll talk to you about what it should cost
in your specific case. They don't just have a package out of the box for it. But they have people doing that.
I'm not sure I understand the...
Oh, yeah, but it's not bound to the DOM in that sense, but it would, as you work with Angular in any sense, and you manipulate stuff, of course you'll be able to do the same things. If things change, then they are propagated.
I think that's it. Thank you guys for coming. And remember that if you want a sticker, then I have a bunch up here.