Hacking real time messaging with Firebase
Daschevici, Artur Iulian
In a serverless world Firebase can fulfill a promise of providing your app with realtime notifications. Firebase can be a great shortcut when you want to have real time notifications between your client apps by leveraging the observable streams Firebase provides in your React components. After the talk building a real time notification system will be simpler to maintain and come with scalability built in. I will try to leverage the real-time Firebase database for building a subscriber component for my application so that I get notifications as they are available. 1. How would I normally do real time notifications: Using redis with PUB/SUB and websockets to subscribe to publish and consume data 2. What is Firebase: Firebase is a real time datbase that takes over some of the complexity of managing your data. It has many language wrappers and is very easy to use 3. Wrapping Firebase library in a react component: In order to preserve the one way directional flow in React you need to wrap your firebase library inside a component to take advantage of the lifecycle 4. How Firebase and React work with the Redux state management: Once the firebase library is wrapped you can map the properties and dispatch actions when new data is available via Redux 5. Putting it all together: This is a wrap up and lets you know how all the pieces fit together 6. Live Demo: We will have a component that does a very basic insert into a firebase bucket, and updates the firebase letting the other users know that new data is available, followed by a live demo of the app
 with Firebase. I'm going to start with Python and then went over to the docs. I did just told me and he's going to talk to us about real-time messaging with Firebase. Hello, like I said, Arthur, and I'm going to help you, hopefully, teach you to leverage Firebase for doing real-time messaging and notifications. You can find me on Twitter. I'm a full-stack developer for a healthcare startup in London. I get to work with a bunch of stuff every day, React Native, React, a bit of IoT, so all the cool new things. But yeah, pretty much nice technologies. I do enjoy it. I do enjoy writing code. I do enjoy solving problems. I do enjoy, you know, playing with new technologies. And of course, I do want my everything to scale to one zillion users. I wanted my product to be loved by everyone. And at the same time, I want it to be in control of it all. So I want to be able to solve any problems, know everything that's going on everywhere in my application. And that brings me to one of my guilty pleasures, which is over-engineering. In case you guys don't know, over-engineering is something like building a bike that does zillion other things other than being writable. So for example, in this picture, you're going to have a bad bike on the right. And, well, depending on how you look at it, you know, good bike, bad bike. Anyway, let's begin. So I started looking into the real-time notifications. And I immediately thought Redis could help me with this. Because Redis is open source. It has a lot of features. And it also has a Redis CLI to help you kind of prototype and figure out what's going on with the messaging inside the PubSub channels. But for this thing, you kind of need the DevOps because after a while, you kind of want to get it custom and all the advanced features. And then you need an app server, a front-end application, a load balancer, because we do want to scale, of course. Centralize logging, because if you have a bunch of nodes and already you have two servers, which is the one with load balancer, one is the Redis server. You're going to want to centralize those logs. And then it starts because log data is massive and you won't be able to parse it quickly enough. And then after a while, you get to have a system that takes up three of your developers and looks kind of like this. And you're dead center of it. But this is just a feature. And usually when you work on a project, you're going to have not one feature, but many. And at the same time, you're going to have to develop the other features. You're going to have to maintain continuous delivery. You're going to have to do bug fixing, keep your customers happy. So yeah, it's going to look like changing wheels on a moving car. And of course, we all familiar with this guy. And hopefully it's sometime in the future, but most of the times it's yesterday. So here is how Firebase can help us. It provides a wide variety of features. You get the real time database, of course. You have the crash reporting. You have Cloud Firestore. You have authentication. You have Cloud Functions similar to AWS lambdas. You have Cloud Storage, which is again for static assets. You have hosting. You have Test Lab for Android, which is running Android unit tests on Google's device farms. And you have performance monitoring. But this is like a feature overload, pretty much. What does this mean to you? Because everything I said before, blah, blah, blah. Nah, not relevant enough. So we get Free CDN and SSL out of the box. You have Easy Auth so that you don't really let your messaging queue out there unauthenticated. You have a free tier, which as a startup, you're probably not going to hit. You have File Storage and you have Auto Magical Scaling, which of course Google, you know, global scale, makes sense. You have quite a few wrappers for it. There's a case for various languages and libraries that you can use with any front-end framework you want. So there's AngularView, React, and there's a lot of them, pretty much. If you need it, you'll probably find it. To get started, basically you want to create the message queue, pretty much. And the message queue is the actual Firebase database, so the real-time database. And you create it, you create the new project, and you give it a name, select a region, and you're good to go. Your messaging queue will be in the real-time database section of the console. You need to grab your config. You have three options. You have the iOS, Android, and Web. We'll get back to these later and I'll show them in the code. But pretty much you have everything ready to go. You click it, get it, put it in your app, build an application, and you're able to communicate with the Firebase database. Now the auth is very simple again. You do, in this example I showed how you can do a simple email password authentication. You set it up and Google kind of encourages it because they won't let you write by default to the database unless you have some form of authentication. However, the roles can be configured, so if you want to disable everything, you can just do that, but I wouldn't advise it. It's not great to do. So so far, it seems pretty easy. I think I've gone through it in a few minutes, and this is pretty much what you have to do to set up the message queue in Firebase. My choice of framework, well, library, because React is not a framework, it's a library. My choice of a library for it is React. For React, you have a bunch of specific packages which either depending on what you have installed will make more sense. So for basic React, no state management, no anything. You can use React Fire. If you use for state management, Redux, then you're probably going to want to go for React Redux Firebase, and there's the plain JavaScript one which is provided by Google, which is the Firebase package. For my project, as buzzwords, you're going to hear Redux, because it's there for state management, React because it's the front end bit, Python because we're a Python conference and I used to be a Python developer. So Redux Saga for managing side effects, and Firebase, of course, because that's the whole point of the talk. And this is hopefully what it's going to look like at the end. And you'll see just I'm going to provide you with a new URL. You're going to open the attendee web app, and the hub I'll show on the big screen, and it's going to be the incrementing number of claps and showing the bubble growing. Hopefully this is what it's going to be. Okay. So let's have a look at the code first. For the back end, like I said, Python, and I use Python 3.7, you can kind of make out by the fact that there's compiled files, PYC files in there. There's the constants which I use for just holding all my config, the username and password, the API key, everything that I need to build the Firebase object. The Firebase Py will, is the file that I keep my Firebase interaction methods in. They're not methods, they're functions. And then I have the requirements. For those of you who are not familiar, this is pretty much the equivalent of a package JSON. Or yeah, I think so. That's it. The application only has two routes. One is when the user joins. So whenever you open the URL, you're going to get a unique ID. And that's just the ID, so nothing fancy. And I'm going to return it to the client so that you store it. And you can do updates later with the reference. And this is where I'm going to update the store. It's going to chain, it's going to trigger the chain of events of bubbling and all the cool stuff. And this is the other one, which is the clap route, which does the updates, the number of claps for that user ID on the Firebase database. And yeah, again, you update the Firebase for that user. Okay. And this is the application. Again, pre-standard boilerplate. I use the AIO HTTP. It comes with a library for configuring cores on the routes. The two routes are joined in clap. I set up the cores. Never do this in production. The rules are way too simple for it. I didn't really want to go into figuring out why I should set it in a certain way or not. I just used everything. And then you set up the cores for every route you have in your application. And this is the config. So you get your API key, your auth domain, a DBRL project ID, storage bucket, and sender ID. And then you just initialize your app. I love it how, so you see the Firebase initialize config. I love it how Python always does the funny names. It's very, yeah. So yeah, Firebase initialize the app and you have the object for your Firebase app. And then authentication. It's very complicated right now. You do the auth and then you sign in. You get the user object which has the token in it. I'm going to show you in just a minute how you use it. Yeah. And this is the Firebase. In Firebase, you grab the reference to the database. That's the first thing. So from the Firebase object we defined earlier, you get the reference. We want to initialize the data on it because when the user joins, it's going to have a collapse of zero. So do that. And then we insert the data into Firebase. And that's it. So basically you insert it. That's it. The user ID token at the end, you see here, you grab that object from before when you did the auth. And you always need to make sure you pass it in because you set up authentication. So you want to have it there. It expires in one hour. Hopefully by demo time it's not going to be one hour because I don't have that. Yeah. Okay. And the update is a little bit different in that you don't have the default data. Yet again, the reference, you get the previous number of cops and then you implement it again passing in the user ID token. So the user digital container ID token and it's going to be valid for one hour. The front end is a little bit hairier. You have a long list of files, folders. Actually, those are not files, they're folders. And there you have the actions for triggering store changes. You have the assets for static stuff. You have components which will render your UI. You have the index.js, which is the main endpoint. I'll cut that in� like a name of whateverch WHAT. All right? test this. Okay. I hate my voice. So where was I folder for the reducers? Okay. So the reducers are functions that will match in action and mutate the state. And basically that's the only place you want to mutate state. And most of the time you want to do it in an immutable manner. So basically create a copy of the store, mutate it, and return the new object. Roots. For the roots, I took them out of the main entry point because I wanted to have them separate and make them more readable. You can even split them. So as you go further and further, you're going to have a lot of stuff and it's going to be confusing if you don't split them out. Sack, those are for managing side effects. By side effects, I mean something like, you know, AJAX requests, long-running thing, and long-running processes, all that kind of cool stuff that if you do have an application, you're going to want to have. And the store is where you want to have the store definition and store configuration. But yeah, so far JavaScript applications, especially large ones, are really bad. And if you don't maintain some form of structure, you're going to wind up with something like a, you know, rubber band ball and try to get the one in the middle, you know, in the center. It's not going to be fun. This is the entry point. Like I said, store for the application state and the routes, which I conveniently factored out. These are the routes. And as you can see, it makes, even to the untrained eye, you will probably notice that it's a component and when you go to that route, it will render that component. It's pretty, and yeah, it's pretty cool to factor them out. The main component of our application and the one that does actually reflect most of the functionality I want to show is the hub. The hub listens to Firebase changes. And that's what we're going to do is exactly after the component has finished mounting, with rendering. The JSX, if anyone's, if anyone's not familiar, this is JSX. It's a templating language for React. It's three lines. It's quite simple and yeah, it's not nothing more to see here. And of course, always do validation on your props. It's good practice and basically your lint will complain if you don't, but I recommend it. It's an easy way to keep track of errors. Okay. Now, the component we saw before, we need to wrap that into a container. And we can do that with Connect. And we're going to map all the actions to the props. So in our case, it's just the one where we start listening for data. So, okay. Again, actions still pretty simple. You're going to have the listen. I showed you before, but really nothing really complex going on here. The action type is a string, actually. I just defined the action types as variables so that you can change them in one place. And usually, if you do work on an application, you want to do it like this, because it saves time refactoring. And these are the reducers. For example, any one of them, they're going to check for the action type and they're going to try to match it. If they don't, they're just going to return the default state. And always return the default state. It's a good way to not crash. But yeah, so far nothing. So we haven't seen any of the real-time stuff. We haven't seen pretty much anything. That's out of the ordinary. So, yeah. And then we have Redux Saga. Redux Saga is a nice way of... Collect it. Redux Saga is a nice way of handling side effects. So if you guys are familiar with thunks or epics, epics is newer, but if you are familiar with thunks, they fulfill the pretty much the same similar purpose, but they give much more fine-grained control over what you can do. So for example, you can throttle them, you can debounce them, you can cancel them in mid-flight. So that gives you really good control over what's going on. So yeah, the magic I was talking about is it's not a lot. Don't be confused by the slide, but... So yeah, this is where the Redux Saga is placed in the whole project, what whole Redux workflow is. It's basically somewhere in between the action and the reducer, and it communicates directly with the API. It's right there. So in our application, the way it's gonna happen is the UI will create an action, it will go into the Saga, and then Saga will perform an API call. The API will do some Firebase updates, and then it's gonna return, pop into the reducer, reducer updates the store state, and then you're gonna have the UI updated. And those are just the basics, unfortunately. There's another one that's a little bit trickier, and because Firebase is real-time and it's an event pipeline, more or less, you're gonna have to use an event channel. And this one will listen continuously for changes that are coming in. So yeah, let's have a look at the sagas. So we're gonna import Firebase, because we want to use it, of course, and then we have some Saga goodies for performing our actions. We have the, you know, the sagas come with a bunch of utils for managing either calling Ajax functions or dispatching other actions, and you also have the event channel, which we're gonna have a look at, because this is the guy that's gonna help us, you know, manage the real-time events coming in from Firebase. So the two points that need to be looked at are the fact that you need to listen to Firebase changes, and this is the database is just the Firebase object. If you remember in the Python slide, I showed the database with the, you grab the reference, that's, this is that reference, not from Python, but it's built beforehand. Sorry, I'm just starting. Okay, so yeah, you grab the database ref and you listen to changes on value. You can put anything in the, in place of on value. There's like three types of change listeners, and then you need to turn it off when you're done. And then we want to create a Saga and use the event channel and keep listening to it. But we're gonna listen as a server does, so it's pretty much, it's not gonna run continuously. It's more of a passive action and basically it observes for changes pretty much. And then we wrap everything nicely in a root saga. This guy contains all the actions that are being dispatched within the app, but you have the listen hub data action, which I showed you before. Okay, so I think we're gonna give the demo a go. So, okay, bear with me. can you guys hear me? Yeah, perfect. This is the URL. If you guys want to take it or I'm just going to quit out of this, let's have a look at the... If you guys have a QR code scanner, there's this. And if you want the URL shortener, there's the... No, shh. Wait, wait. That's the one. That's the bit.ly URL. If you have a QR code scanner, you can use this. If it works, it's kind of sad about the distortion on the thing. Did it work? Mm-hmm. Did the QR work? Okay, do you see the... Yeah, you have it? Okay. And now we have a few... Well, yeah, somebody joined and then you have the guys clapping. Yeah, pretty interesting. Not really. I wish I did it a little bit better. Oh, there you go. Another one. Somebody else joined. And this is going all through Firebase. If you want to go to the thing, it's going to be... You can use that link to join if you haven't already. If I switch to the hub. Don't push the link off the screen, please. And then... Yeah, what can I... Ah, yes. You know this. I think you guys used NG Rock before. So basically, what's going on? This is on my laptop. And you're communicating with the API on my laptop. This pretty much gives you a quick way to do demos. So somebody's being bad. Somebody's being bad. No, no, no, no. I zoomed in. And yeah, that's the link again. Okay, cool. You guys happy with it? Can I switch back to the slides? Want to play some more? How am I doing on time? Sorry. Hello? How am I doing on time? Ten minutes. Okay. Okay. So yeah. I'm going to stop it. Okay. Okay. You can find my code here. So the code for this demo is available here. Take it, play around with it. I then submit the configs. Because I don't want to skip my free tier on Firebase. Also, I don't want them to ban me. But yeah, it's there. And yeah. You can find me on Twitter. You can find me afterwards. Chat me up. Ask me any questions you feel like. And, you know, stay classy, Barcelona. Thank you. Thank you very much for 그렇게.​
 with Firebase.  I'm going to start with Python and then went over to the docs.  I did just told me and he's going to talk to us about real-time messaging with Firebase.  Hello, like I said, Arthur, and I'm going to help you, hopefully, teach you to leverage  Firebase for doing real-time messaging and notifications.  You can find me on Twitter.  I'm a full-stack developer for a healthcare startup in London.  I get to work with a bunch of stuff every day, React Native, React, a bit of IoT, so  all the cool new things.  But yeah, pretty much nice technologies.  I do enjoy it.  I do enjoy writing code.  I do enjoy solving problems.  I do enjoy, you know, playing with new technologies.  And of course, I do want my everything to scale to one zillion users.  I wanted my product to be loved by everyone.  And at the same time, I want it to be in control of it all.  So I want to be able to solve any problems, know everything that's going on everywhere  in my application.  And that brings me to one of my guilty pleasures, which is over-engineering.  In case you guys don't know, over-engineering is something like building a bike that does  zillion other things other than being writable.  So for example, in this picture, you're going to have a bad bike on the right.  And, well, depending on how you look at it, you know, good bike, bad bike.  Anyway, let's begin.  So I started looking into the real-time notifications.  And I immediately thought Redis could help me with this.  Because Redis is open source.  It has a lot of features.  And it also has a Redis CLI to help you kind of prototype and figure out what's going on  with the messaging inside the PubSub channels.  But for this thing, you kind of need the DevOps because after a while, you kind of want to  get it custom and all the advanced features.  And then you need an app server, a front-end application, a load balancer, because we do  want to scale, of course.  Centralize logging, because if you have a bunch of nodes and already you have two servers,  which is the one with load balancer, one is the Redis server.  You're going to want to centralize those logs.  And then it starts because log data is massive and you won't be able to parse it quickly  enough.  And then after a while, you get to have a system that takes up three of your developers  and looks kind of like this.  And you're dead center of it.  But this is just a feature.  And usually when you work on a project, you're going to have not one feature, but many.  And at the same time, you're going to have to develop the other features.  You're going to have to maintain continuous delivery.  You're going to have to do bug fixing, keep your customers happy.  So yeah, it's going to look like changing wheels on a moving car.  And of course, we all familiar with this guy.  And hopefully it's sometime in the future, but most of the times it's yesterday.  So here is how Firebase can help us.  It provides a wide variety of features.  You get the real time database, of course.  You have the crash reporting.  You have Cloud Firestore.  You have authentication.  You have Cloud Functions similar to AWS lambdas.  You have Cloud Storage, which is again for static assets.  You have hosting.  You have Test Lab for Android, which is running Android unit tests on Google's device farms.  And you have performance monitoring.  But this is like a feature overload, pretty much.  What does this mean to you?  Because everything I said before, blah, blah, blah.  Nah, not relevant enough.  So we get Free CDN and SSL out of the box.  You have Easy Auth so that you don't really let your messaging queue out there unauthenticated.  You have a free tier, which as a startup, you're probably not going to hit.  You have File Storage and you have Auto Magical Scaling, which of course Google, you know,  global scale, makes sense.  You have quite a few wrappers for it.  There's a case for various languages and libraries that you can use with any front-end framework  you want.  So there's AngularView, React, and there's a lot of them, pretty much.  If you need it, you'll probably find it.  To get started, basically you want to create the message queue, pretty much.  And the message queue is the actual Firebase database, so the real-time database.  And you create it, you create the new project, and you give it a name, select a region, and  you're good to go.  Your messaging queue will be in the real-time database section of the console.  You need to grab your config.  You have three options.  You have the iOS, Android, and Web.  We'll get back to these later and I'll show them in the code.  But pretty much you have everything ready to go.  You click it, get it, put it in your app, build an application, and you're able to communicate  with the Firebase database.  Now the auth is very simple again.  You do, in this example I showed how you can do a simple email password authentication.  You set it up and Google kind of encourages it because they won't let you write by default  to the database unless you have some form of authentication.  However, the roles can be configured, so if you want to disable everything, you can just  do that, but I wouldn't advise it.  It's not great to do.  So so far, it seems pretty easy.  I think I've gone through it in a few minutes, and this is pretty much what you have to do  to set up the message queue in Firebase.  My choice of framework, well, library, because React is not a framework, it's a library.  My choice of a library for it is React.  For React, you have a bunch of specific packages which either depending on what you have installed  will make more sense.  So for basic React, no state management, no anything.  You can use React Fire.  If you use for state management, Redux, then you're probably going to want to go for React  Redux Firebase, and there's the plain JavaScript one which is provided by Google, which is  the Firebase package.  For my project, as buzzwords, you're going to hear Redux, because it's there for state  management, React because it's the front end bit, Python because we're a Python conference  and I used to be a Python developer.  So Redux Saga for managing side effects, and Firebase, of course, because that's the whole  point of the talk.  And this is hopefully what it's going to look like at the end.  And you'll see just I'm going to provide you with a new URL.  You're going to open the attendee web app, and the hub I'll show on the big screen, and  it's going to be the incrementing number of claps and showing the bubble growing.  Hopefully this is what it's going to be.  Okay.  So let's have a look at the code first.  For the back end, like I said, Python, and I use Python 3.7, you can kind of make out  by the fact that there's compiled files, PYC files in there.  There's the constants which I use for just holding all my config, the username and password,  the API key, everything that I need to build the Firebase object.  The Firebase Py will, is the file that I keep my Firebase interaction methods in.  They're not methods, they're functions.  And then I have the requirements.  For those of you who are not familiar, this is pretty much the equivalent of a package  JSON.  Or yeah, I think so.  That's it.  The application only has two routes.  One is when the user joins.  So whenever you open the URL, you're going to get a unique ID.  And that's just the ID, so nothing fancy.  And I'm going to return it to the client so that you store it.  And you can do updates later with the reference.  And this is where I'm going to update the store.  It's going to chain, it's going to trigger the chain of events of bubbling and all the  cool stuff.  And this is the other one, which is the clap route, which does the updates, the number  of claps for that user ID on the Firebase database.  And yeah, again, you update the Firebase for that user.  Okay.  And this is the application.  Again, pre-standard boilerplate.  I use the AIO HTTP.  It comes with a library for configuring cores on the routes.  The two routes are joined in clap.  I set up the cores.  Never do this in production.  The rules are way too simple for it.  I didn't really want to go into figuring out why I should set it in a certain way or not.  I just used everything.  And then you set up the cores for every route you have in your application.  And this is the config.  So you get your API key, your auth domain, a DBRL project ID, storage bucket, and sender  ID.  And then you just initialize your app.  I love it how, so you see the Firebase initialize config.  I love it how Python always does the funny names.  It's very, yeah.  So yeah, Firebase initialize the app and you have the object for your Firebase app.  And then authentication.  It's very complicated right now.  You do the auth and then you sign in.  You get the user object which has the token in it.  I'm going to show you in just a minute how you use it.  Yeah.  And this is the Firebase.  In Firebase, you grab the reference to the database.  That's the first thing.  So from the Firebase object we defined earlier, you get the reference.  We want to initialize the data on it because when the user joins, it's going to have a  collapse of zero.  So do that.  And then we insert the data into Firebase.  And that's it.  So basically you insert it.  That's it.  The user ID token at the end, you see here, you grab that object from before when you  did the auth.  And you always need to make sure you pass it in because you set up authentication.  So you want to have it there.  It expires in one hour.  Hopefully by demo time it's not going to be one hour because I don't have that.  Yeah.  Okay.  And the update is a little bit different in that you don't have the default data.  Yet again, the reference, you get the previous number of cops and then you implement it again  passing in the user ID token.  So the user digital container ID token and it's going to be valid for one hour.  The front end is a little bit hairier.  You have a long list of files, folders.  Actually, those are not files, they're folders.  And there you have the actions for triggering store changes.  You have the assets for static stuff.  You have components which will render your UI.  You have the index.js, which is the main endpoint.  I'll cut that in� like a name of whateverch WHAT.  All right?  test this. Okay. I hate my voice. So where was I folder for the reducers? Okay. So the  reducers are functions that will match in action and mutate the state. And basically  that's the only place you want to mutate state. And most of the time you want to do  it in an immutable manner. So basically create a copy of the store, mutate it, and  return the new object. Roots. For the roots, I took them out of the main entry  point because I wanted to have them separate and make them more readable. You  can even split them. So as you go further and further, you're going to have a lot of  stuff and it's going to be confusing if you don't split them out. Sack, those are  for managing side effects. By side effects, I mean something like, you know,  AJAX requests, long-running thing, and long-running processes, all that kind of  cool stuff that if you do have an application, you're going to want to  have. And the store is where you want to have the store definition and store  configuration. But yeah, so far JavaScript applications, especially large ones, are  really bad. And if you don't maintain some form of structure, you're going to wind  up with something like a, you know, rubber band ball and try to get the one in the  middle, you know, in the center. It's not going to be fun. This is the entry point.  Like I said, store for the application state and the routes, which I conveniently  factored out. These are the routes. And as you can see, it makes, even to the  untrained eye, you will probably notice that it's a component and when you go to  that route, it will render that component. It's pretty, and yeah, it's pretty  cool to factor them out. The main component of our application and the one that  does actually reflect most of the functionality I want to show is the hub.  The hub listens to Firebase changes. And that's what we're going to do is exactly  after the component has finished mounting, with rendering. The JSX, if anyone's,  if anyone's not familiar, this is JSX. It's a templating language for React. It's  three lines. It's quite simple and yeah, it's not nothing more to see here. And of  course, always do validation on your props. It's good practice and basically  your lint will complain if you don't, but I recommend it. It's an easy way to keep  track of errors. Okay. Now, the component we saw before, we need to wrap that into  a container. And we can do that with Connect. And we're going to map all the  actions to the props. So in our case, it's just the one where we start listening  for data. So, okay. Again, actions still pretty simple. You're going to have the  listen. I showed you before, but really nothing really complex going on here. The  action type is a string, actually. I just defined the action types as variables so  that you can change them in one place. And usually, if you do work on an application,  you want to do it like this, because it saves time refactoring. And these are the  reducers. For example, any one of them, they're going to check for the action type  and they're going to try to match it. If they don't, they're just going to return  the default state. And always return the default state. It's a good way to not  crash. But yeah, so far nothing. So we haven't seen any of the real-time stuff.  We haven't seen pretty much anything. That's out of the ordinary. So, yeah. And  then we have Redux Saga. Redux Saga is a nice way of... Collect it. Redux Saga is a nice  way of handling side effects. So if you guys are familiar with thunks or epics,  epics is newer, but if you are familiar with thunks, they fulfill the pretty much  the same similar purpose, but they give much more fine-grained control over what  you can do. So for example, you can throttle them, you can debounce them, you  can cancel them in mid-flight. So that gives you really good control over what's  going on. So yeah, the magic I was talking about is it's not a lot. Don't be  confused by the slide, but... So yeah, this is where the Redux Saga is placed in  the whole project, what whole Redux workflow is. It's basically somewhere in  between the action and the reducer, and it communicates directly with the API.  It's right there. So in our application, the way it's gonna happen is the UI will  create an action, it will go into the Saga, and then Saga will perform an API  call. The API will do some Firebase updates, and then it's gonna return, pop  into the reducer, reducer updates the store state, and then you're gonna have  the UI updated. And those are just the basics, unfortunately. There's another  one that's a little bit trickier, and because Firebase is real-time and it's  an event pipeline, more or less, you're gonna have to use an event channel. And  this one will listen continuously for changes that are coming in. So yeah, let's  have a look at the sagas. So we're gonna import Firebase, because we want  to use it, of course, and then we have some Saga goodies for performing our  actions. We have the, you know, the sagas come with a bunch of utils for  managing either calling Ajax functions or dispatching other actions, and you also  have the event channel, which we're gonna have a look at, because this is the guy  that's gonna help us, you know, manage the real-time events coming in from  Firebase. So the two points that need to be looked at are the fact that you need  to listen to Firebase changes, and this is the database is just the  Firebase object. If you remember in the Python slide, I showed the database  with the, you grab the reference, that's, this is that reference, not from Python,  but it's built beforehand. Sorry, I'm just starting. Okay, so yeah, you grab the  database ref and you listen to changes on value. You can put anything in the, in  place of on value. There's like three types of change listeners, and then you  need to turn it off when you're done. And then we want to create a Saga and  use the event channel and keep listening to it. But we're gonna listen as a server  does, so it's pretty much, it's not gonna run continuously. It's more of a passive  action and basically it observes for changes pretty much. And then we wrap  everything nicely in a root saga. This guy contains all the actions that are  being dispatched within the app, but you have the listen hub data action, which I  showed you before. Okay, so I think we're gonna give the demo a go. So, okay, bear  with me.  can you guys hear me? Yeah, perfect.  This is the URL. If you guys want to take it or I'm just going to quit out of this, let's  have a look at the... If you guys have a QR code scanner, there's this. And if you want  the URL shortener, there's the... No, shh. Wait, wait. That's the one. That's the bit.ly  URL. If you have a QR code scanner, you can use this. If it works, it's kind of sad about  the distortion on the thing. Did it work? Mm-hmm. Did the QR work? Okay, do you see the...  Yeah, you have it? Okay. And now we have a few... Well, yeah, somebody joined and then you have the  guys clapping. Yeah, pretty interesting. Not really. I wish I did it a little bit better.  Oh, there you go. Another one. Somebody else joined. And this is going all through Firebase.  If you want to go to the thing, it's going to be... You can use that link to join if you  haven't already. If I switch to the hub. Don't push the link off the screen, please. And then...  Yeah, what can I... Ah, yes. You know this. I think you guys used NG Rock before. So basically,  what's going on? This is on my laptop. And you're communicating with the API on my laptop.  This pretty much gives you a quick way to do demos. So somebody's being bad. Somebody's being  bad. No, no, no, no. I zoomed in. And yeah, that's the link again. Okay, cool. You guys happy with  it? Can I switch back to the slides? Want to play some more? How am I doing on time? Sorry.  Hello? How am I doing on time? Ten minutes. Okay. Okay. So yeah. I'm going to stop it. Okay.  Okay. You can find my code here. So the code for this demo is available here. Take it, play  around with it. I then submit the configs. Because I don't want to skip my free tier on  Firebase. Also, I don't want them to ban me. But yeah, it's there. And yeah. You can find me on  Twitter. You can find me afterwards. Chat me up. Ask me any questions you feel like. And, you know,  stay classy, Barcelona. Thank you. Thank you very much for 그렇게.​
Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_0_131.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_132_251.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_252_959.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_960_1223.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_1224_2015.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_2016_3023.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_3024_3659.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_3660_3899.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_3900_5603.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_5604_13643.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_13644_17915.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_17916_19127.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_19128_21287.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_21288_25235.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_25236_25967.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_25968_27443.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_27444_28847.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_28848_34319.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_34320_42131.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_42132_42323.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_42324_43703.png Day_2__Artur_Iulian_Daschevici_-_Hacking_real_time_MVmoUPYbHew_43704_43819.png
with Firebase. I'm going to start with Python and then went over to the docs. I did just told me and he's going to talk to us about real-time messaging with Firebase. Hello, like I said, Arthur, and I'm going to help you, hopefully, teach you to leverage Firebase for doing real-time messaging and notifications. You can find me on Twitter. I'm a full-stack developer for a healthcare startup in London. I get to work with a bunch of stuff every day, React Native, React, a bit of IoT, so all the cool new things. But yeah, pretty much nice technologies. I do enjoy it. I do enjoy writing code. I do enjoy solving problems. I do enjoy, you know, playing with new technologies. And of course, I do want my everything to scale to one zillion users. I wanted my product to be loved by everyone. And at the same time, I want it to be in control of it all. So I want to be able to solve any problems, know everything that's going on everywhere in my application. And that brings me to one of my guilty pleasures, which is over-engineering. In case you guys don't know, over-engineering is something like building a bike that does zillion other things other than being writable. So for example, in this picture, you're going to have a bad bike on the right. And, well, depending on how you look at it, you know, good bike, bad bike. Anyway, let's begin. So I started looking into the real-time notifications. And I immediately thought Redis could help me with this. Because Redis is open source. It has a lot of features. And it also has a Redis CLI to help you kind of prototype and figure out what's going on with the messaging inside the PubSub channels. But for this thing, you kind of need the DevOps because after a while, you kind of want to get it custom and all the advanced features. And then you need an app server, a front-end application, a load balancer, because we do want to scale, of course. Centralize logging, because if you have a bunch of nodes and already you have two servers, which is the one with load balancer, one is the Redis server. You're going to want to centralize those logs. And then it starts because log data is massive and you won't be able to parse it quickly enough. And then after a while, you get to have a system that takes up three of your developers and looks kind of like this. And you're dead center of it. But this is just a feature. And usually when you work on a project, you're going to have not one feature, but many. And at the same time, you're going to have to develop the other features. You're going to have to maintain continuous delivery. You're going to have to do bug fixing, keep your customers happy. So yeah, it's going to look like changing wheels on a moving car. And of course, we all familiar with this guy. And hopefully it's sometime in the future, but most of the times it's yesterday. So here is how Firebase can help us. It provides a wide variety of features. You get the real time database, of course. You have the crash reporting. You have Cloud Firestore. You have authentication. You have Cloud Functions similar to AWS lambdas. You have Cloud Storage, which is again for static assets. You have hosting. You have Test Lab for Android, which is running Android unit tests on Google's device farms. And you have performance monitoring. But this is like a feature overload, pretty much. What does this mean to you? Because everything I said before, blah, blah, blah. Nah, not relevant enough. So we get Free CDN and SSL out of the box. You have Easy Auth so that you don't really let your messaging queue out there unauthenticated. You have a free tier, which as a startup, you're probably not going to hit. You have File Storage and you have Auto Magical Scaling, which of course Google, you know, global scale, makes sense. You have quite a few wrappers for it. There's a case for various languages and libraries that you can use with any front-end framework you want. So there's AngularView, React, and there's a lot of them, pretty much. If you need it, you'll probably find it. To get started, basically you want to create the message queue, pretty much. And the message queue is the actual Firebase database, so the real-time database. And you create it, you create the new project, and you give it a name, select a region, and you're good to go. Your messaging queue will be in the real-time database section of the console. You need to grab your config. You have three options. You have the iOS, Android, and Web. We'll get back to these later and I'll show them in the code. But pretty much you have everything ready to go. You click it, get it, put it in your app, build an application, and you're able to communicate with the Firebase database. Now the auth is very simple again. You do, in this example I showed how you can do a simple email password authentication. You set it up and Google kind of encourages it because they won't let you write by default to the database unless you have some form of authentication. However, the roles can be configured, so if you want to disable everything, you can just do that, but I wouldn't advise it. It's not great to do. So so far, it seems pretty easy. I think I've gone through it in a few minutes, and this is pretty much what you have to do to set up the message queue in Firebase. My choice of framework, well, library, because React is not a framework, it's a library. My choice of a library for it is React. For React, you have a bunch of specific packages which either depending on what you have installed will make more sense. So for basic React, no state management, no anything. You can use React Fire. If you use for state management, Redux, then you're probably going to want to go for React Redux Firebase, and there's the plain JavaScript one which is provided by Google, which is the Firebase package. For my project, as buzzwords, you're going to hear Redux, because it's there for state management, React because it's the front end bit, Python because we're a Python conference and I used to be a Python developer. So Redux Saga for managing side effects, and Firebase, of course, because that's the whole point of the talk. And this is hopefully what it's going to look like at the end. And you'll see just I'm going to provide you with a new URL. You're going to open the attendee web app, and the hub I'll show on the big screen, and it's going to be the incrementing number of claps and showing the bubble growing. Hopefully this is what it's going to be. Okay. So let's have a look at the code first. For the back end, like I said, Python, and I use Python 3.7, you can kind of make out by the fact that there's compiled files, PYC files in there. There's the constants which I use for just holding all my config, the username and password, the API key, everything that I need to build the Firebase object. The Firebase Py will, is the file that I keep my Firebase interaction methods in. They're not methods, they're functions. And then I have the requirements. For those of you who are not familiar, this is pretty much the equivalent of a package JSON. Or yeah, I think so. That's it. The application only has two routes. One is when the user joins. So whenever you open the URL, you're going to get a unique ID. And that's just the ID, so nothing fancy. And I'm going to return it to the client so that you store it. And you can do updates later with the reference. And this is where I'm going to update the store. It's going to chain, it's going to trigger the chain of events of bubbling and all the cool stuff. And this is the other one, which is the clap route, which does the updates, the number of claps for that user ID on the Firebase database. And yeah, again, you update the Firebase for that user. Okay. And this is the application. Again, pre-standard boilerplate. I use the AIO HTTP. It comes with a library for configuring cores on the routes. The two routes are joined in clap. I set up the cores. Never do this in production. The rules are way too simple for it. I didn't really want to go into figuring out why I should set it in a certain way or not. I just used everything. And then you set up the cores for every route you have in your application. And this is the config. So you get your API key, your auth domain, a DBRL project ID, storage bucket, and sender ID. And then you just initialize your app. I love it how, so you see the Firebase initialize config. I love it how Python always does the funny names. It's very, yeah. So yeah, Firebase initialize the app and you have the object for your Firebase app. And then authentication. It's very complicated right now. You do the auth and then you sign in. You get the user object which has the token in it. I'm going to show you in just a minute how you use it. Yeah. And this is the Firebase. In Firebase, you grab the reference to the database. That's the first thing. So from the Firebase object we defined earlier, you get the reference. We want to initialize the data on it because when the user joins, it's going to have a collapse of zero. So do that. And then we insert the data into Firebase. And that's it. So basically you insert it. That's it. The user ID token at the end, you see here, you grab that object from before when you did the auth. And you always need to make sure you pass it in because you set up authentication. So you want to have it there. It expires in one hour. Hopefully by demo time it's not going to be one hour because I don't have that. Yeah. Okay. And the update is a little bit different in that you don't have the default data. Yet again, the reference, you get the previous number of cops and then you implement it again passing in the user ID token. So the user digital container ID token and it's going to be valid for one hour. The front end is a little bit hairier. You have a long list of files, folders. Actually, those are not files, they're folders. And there you have the actions for triggering store changes. You have the assets for static stuff. You have components which will render your UI. You have the index.js, which is the main endpoint. I'll cut that in� like a name of whateverch WHAT. All right? test this. Okay. I hate my voice. So where was I folder for the reducers? Okay. So the reducers are functions that will match in action and mutate the state. And basically that's the only place you want to mutate state. And most of the time you want to do it in an immutable manner. So basically create a copy of the store, mutate it, and return the new object. Roots. For the roots, I took them out of the main entry point because I wanted to have them separate and make them more readable. You can even split them. So as you go further and further, you're going to have a lot of stuff and it's going to be confusing if you don't split them out. Sack, those are for managing side effects. By side effects, I mean something like, you know, AJAX requests, long-running thing, and long-running processes, all that kind of cool stuff that if you do have an application, you're going to want to have. And the store is where you want to have the store definition and store configuration. But yeah, so far JavaScript applications, especially large ones, are really bad. And if you don't maintain some form of structure, you're going to wind up with something like a, you know, rubber band ball and try to get the one in the middle, you know, in the center. It's not going to be fun. This is the entry point. Like I said, store for the application state and the routes, which I conveniently factored out. These are the routes. And as you can see, it makes, even to the untrained eye, you will probably notice that it's a component and when you go to that route, it will render that component. It's pretty, and yeah, it's pretty cool to factor them out. The main component of our application and the one that does actually reflect most of the functionality I want to show is the hub. The hub listens to Firebase changes. And that's what we're going to do is exactly after the component has finished mounting, with rendering. The JSX, if anyone's, if anyone's not familiar, this is JSX. It's a templating language for React. It's three lines. It's quite simple and yeah, it's not nothing more to see here. And of course, always do validation on your props. It's good practice and basically your lint will complain if you don't, but I recommend it. It's an easy way to keep track of errors. Okay. Now, the component we saw before, we need to wrap that into a container. And we can do that with Connect. And we're going to map all the actions to the props. So in our case, it's just the one where we start listening for data. So, okay. Again, actions still pretty simple. You're going to have the listen. I showed you before, but really nothing really complex going on here. The action type is a string, actually. I just defined the action types as variables so that you can change them in one place. And usually, if you do work on an application, you want to do it like this, because it saves time refactoring. And these are the reducers. For example, any one of them, they're going to check for the action type and they're going to try to match it. If they don't, they're just going to return the default state. And always return the default state. It's a good way to not crash. But yeah, so far nothing. So we haven't seen any of the real-time stuff. We haven't seen pretty much anything. That's out of the ordinary. So, yeah. And then we have Redux Saga. Redux Saga is a nice way of... Collect it. Redux Saga is a nice way of handling side effects. So if you guys are familiar with thunks or epics, epics is newer, but if you are familiar with thunks, they fulfill the pretty much the same similar purpose, but they give much more fine-grained control over what you can do. So for example, you can throttle them, you can debounce them, you can cancel them in mid-flight. So that gives you really good control over what's going on. So yeah, the magic I was talking about is it's not a lot. Don't be confused by the slide, but... So yeah, this is where the Redux Saga is placed in the whole project, what whole Redux workflow is. It's basically somewhere in between the action and the reducer, and it communicates directly with the API. It's right there. So in our application, the way it's gonna happen is the UI will create an action, it will go into the Saga, and then Saga will perform an API call. The API will do some Firebase updates, and then it's gonna return, pop into the reducer, reducer updates the store state, and then you're gonna have the UI updated. And those are just the basics, unfortunately. There's another one that's a little bit trickier, and because Firebase is real-time and it's an event pipeline, more or less, you're gonna have to use an event channel. And this one will listen continuously for changes that are coming in. So yeah, let's have a look at the sagas. So we're gonna import Firebase, because we want to use it, of course, and then we have some Saga goodies for performing our actions. We have the, you know, the sagas come with a bunch of utils for managing either calling Ajax functions or dispatching other actions, and you also have the event channel, which we're gonna have a look at, because this is the guy that's gonna help us, you know, manage the real-time events coming in from Firebase. So the two points that need to be looked at are the fact that you need to listen to Firebase changes, and this is the database is just the Firebase object. If you remember in the Python slide, I showed the database with the, you grab the reference, that's, this is that reference, not from Python, but it's built beforehand. Sorry, I'm just starting. Okay, so yeah, you grab the database ref and you listen to changes on value. You can put anything in the, in place of on value. There's like three types of change listeners, and then you need to turn it off when you're done. And then we want to create a Saga and use the event channel and keep listening to it. But we're gonna listen as a server does, so it's pretty much, it's not gonna run continuously. It's more of a passive action and basically it observes for changes pretty much. And then we wrap everything nicely in a root saga. This guy contains all the actions that are being dispatched within the app, but you have the listen hub data action, which I showed you before. Okay, so I think we're gonna give the demo a go. So, okay, bear with me. can you guys hear me? Yeah, perfect. This is the URL. If you guys want to take it or I'm just going to quit out of this, let's have a look at the... If you guys have a QR code scanner, there's this. And if you want the URL shortener, there's the... No, shh. Wait, wait. That's the one. That's the bit.ly URL. If you have a QR code scanner, you can use this. If it works, it's kind of sad about the distortion on the thing. Did it work? Mm-hmm. Did the QR work? Okay, do you see the... Yeah, you have it? Okay. And now we have a few... Well, yeah, somebody joined and then you have the guys clapping. Yeah, pretty interesting. Not really. I wish I did it a little bit better. Oh, there you go. Another one. Somebody else joined. And this is going all through Firebase. If you want to go to the thing, it's going to be... You can use that link to join if you haven't already. If I switch to the hub. Don't push the link off the screen, please. And then... Yeah, what can I... Ah, yes. You know this. I think you guys used NG Rock before. So basically, what's going on? This is on my laptop. And you're communicating with the API on my laptop. This pretty much gives you a quick way to do demos. So somebody's being bad. Somebody's being bad. No, no, no, no. I zoomed in. And yeah, that's the link again. Okay, cool. You guys happy with it? Can I switch back to the slides? Want to play some more? How am I doing on time? Sorry. Hello? How am I doing on time? Ten minutes. Okay. Okay. So yeah. I'm going to stop it. Okay. Okay. You can find my code here. So the code for this demo is available here. Take it, play around with it. I then submit the configs. Because I don't want to skip my free tier on Firebase. Also, I don't want them to ban me. But yeah, it's there. And yeah. You can find me on Twitter. You can find me afterwards. Chat me up. Ask me any questions you feel like. And, you know, stay classy, Barcelona. Thank you. Thank you very much for 그렇게.​
teach you to leverage Firebase for doing into the real-time notifications. And I to have a system that takes up three of your feature. And usually when you work on a project, develop the other features. You're going to have to maintain continuous delivery. You're going to here is how Firebase can help us. It provides a wide variety of features. You get the real time database. And you create it, you create the new it in your app, build an application, and you're able to communicate with the Firebase database. the roles can be configured, so if you want to Fire. If you use for state management, Redux, React Redux Firebase, and there's the plain is the Firebase package. For my project, as the whole point of the talk. And this is everything that I need to build the Firebase the client so that you store it. And you can do project ID, storage bucket, and sender ID. And very, yeah. So yeah, Firebase initialize the app you use it. Yeah. And this is the Firebase. In zero. So do that. And then we insert the data our application and the one that does actually the component we saw before, we need to wrap that into a container. And we can do that with and they're going to try to match it. If they have Redux Saga. Redux Saga is a nice way of... between the action and the reducer, and it API call. The API will do some Firebase updates, reducer updates the store state, and then you're that are coming in. So yeah, let's have a look at actions. We have the, you know, the sagas come nicely in a root saga. This guy contains all the code for this demo is available here. Take it,