 and how you can use them in a front-end technology, like CREACT, and build your own modern single-page web apps. I have a super interesting slot being given to me that is just after lunch. So if you're feeling sleepy, don't worry. Even I'm jet lagged, you can go ahead and sleep. My name is Vipul. I go by Vipul and Sward on Twitter and GitHub. And I'm part of the real issues team, and I help triage Rails issues and contribute. And this is me on the Rails contributors list. When I'm not doing contributions, I spend most of my time at my company, which is called as BigBinary, which we spoke a bit about previously in the session of hiring. It's a remote, like completely remote team wherein people work from different countries. And most of them are from India, and it's based out of Miami. It's Ruby on Rails consenting, and we do things like React.js, React Native, et cetera. That's where my experience comes in from React. This is my second time in Taiwan. I was here last year. I spoke more about React in Ruby cons. And last time I went when I was here, it was pretty pleasant. That's what I got from the weather. And then when I was landing, just landing React.js and everyone of the speakers a message that the weather in Taiwan is hot with chances of rain in the afternoon. I'm like, what? I'm already coming in from summer hot city wherein I can't wear this. And I'm like, why? Again, I'm going to face that. And I went and quickly checked up what the weather is, because I'm in love in weather. When I go to the states, that's the first thing that I do, because they have like 48 different weather channels just to keep you focused on weather. So I see this, and I'm like, this is like 30 degrees. Why is he saying hot? This is because where I live, this is from Pune where I've traveled. This is my weather, and it's like six, seven degrees more. And this was even more surprising because the city in where my brother lives is currently around 42. So it's like, yay, I'm going in awesome. I'm going on a winter vacation. All right, so that's why I can wear this, because yesterday I was feeling pretty cold. All right, so moving on. Today, I'm going to speak more about this kind of architecture and what are the different components involved in this architecture, and take a look at bits and pieces of these, and how you can transition towards this kind of architecture, wherein you have isolated components interacting with each other. Traditionally, if you build a Rails app, like previously, we have started having services, microservices as well, but previously it used to be like you have a single monolith Rails app where in all of your representation logic or your backend logic, your views, et cetera, all were being served from one single Rails application. As we move forward, we started having different architectures like we move from monoliths to microservices, et cetera. Today, I'm not going to speak about those kind of architectures, but focus on how you can distribute, like how you can divide your main Rails application in terms of your front-end services or display and how they can start consuming your resources from your Rails API. So traditionally, what you had is this monolith, but slowly as we, like towards the end of the last decade, we started having a lot of services which came like, tried to understand and came to know that instead of serving this whole big view of HTML, why not just send small bits and pieces of say, JSON over the wire and using that JSON, update my front-end. So what started happening is many services started sending out or start giving out your updates in terms of JSON or similar services. So today I'll be speaking briefly, and this is like the five-minute version, in case you go to sleep in the middle of the talk, please pay attention for five minutes. So we'll be speaking about Rails API. We'll be going very deep into it, like what Rails API is and how you can build Rails API-only apps. We'll be speaking about peripheral services. There are many various different ones, like you can have export your services in JSON, you have API where communication takes place. We'll be going in depth with Action Cable, which is one of the fun things that I find with Rails 5, and other services like you can have authentication and multiple different services. So we'll be going deep again on Rails API, only applications Action Cable, and how they interact with each other. So you have your basic API app, which is slimmed down version. It is not going to do any kind of display activities. It's only going to keep to manipulation of your data and act as a data store, and just emit this information, which is then going to be consumed with services like you can have JSON, consumer services. You can have N number of back end, like front end services over here, which will consume a single point of source, that can be React, that can be Enber, that can be Angular, Meteor, any kind of front end technology. Along with that it can be services like you have your mobile-based services, which will again use a single point of service, like your API service to consume all your resources, and update those views. Partly why I want to speak about this is, as and when this transition has started happening, and front end, like various different front end frameworks have started gaining popularity. In today's day, like age, it makes sense that we have this kind of support for these kind of technologies, where you do not need a lot of interaction, but just need bits and pieces of data from the server. So Rails 5 progresses towards this, like tries to progress and support this kind of services in terms of having API-only applications. So two things that again are great interactions to Rails 5 are the API apps and action cable. I'll not be going through all of the different things that happen in Rails 5. Again, just a link over here, you can go over it and see blog.bigbanner.com. We have a blog series only for all of the different changes which are coming to Rails 5. You can get a better idea from there. They're around 40 plus, and we keep on talking about those. So to begin with, we'll see the first part, which is API-only applications. So what I mean by an API application, when you think of an API application previously again, we used to have this main application, and slowly we used to just have this web app wherein you were serving all your requests over your browser. Slowly and steadily, people started wanting to have support from your app and provide that support to your mobile apps. So what you ended up or some different service and what you ended up having is the service which is talking to your main data source in your Rails application and which is going to export some kind of API which again is still living in your main Rails application. Slowly, as it progressed, we started seeing that there was a lot of consumption of resources from these API apps. So instead of that, we ended up having services like, say, these are some examples like developer.github.com, twitter.com, these are some of the API applications. The main objective was just serving API and serving data from that particular API. This is one of an example of how this might look. Many of you must have used or created an API. Everyone knows JSON, right? Awesome. So this is an example of how emojis are represented by API in on GitHub. Good thing, curious thing to note over here is some of the services started consuming their own resources to have their service display the data on their web app as well. Or consider these services as external and then have these services being consumed. For an example, twitter.dev.twitter, they consume their own services as well to show information in their apps. So this slow progression leads us to this architecture that we were speaking about, that having your own service of API and consuming that service itself to display however you want to manipulate your views in other different services, like your web app, your mobile app, or any different service. When you think about this and you end up like, okay, I need to build an API now because I'm starting with a new project and I want to build an API so that I can have mobile first approach and build my API for mobile consumption or web consumption. So one thing that comes to my mind is like, why exactly should I use Rails? Like I can instead of doing that, I can use maybe a Java service or I can end up using, if I'm familiar with Sinatra, I would go with Sinatra because it's like, it doesn't have so much different things that Rails has, like Rails is huge. So why should I actually use Rails? To think of it in bad terms, when you think about it, if you already know Rails, you're pretty much familiar with the Rails development environment. You're pretty comfortable with the different things that Rails provides you with. It has, and this is one of the main important things that it follows is convention over configuration which is one of my favorite things that it does is any developer who comes, he knows what environment he's going to face. It has powerful testing, inbuilt security, like it has like providing message verifiers, cookie verifiers, signatures, et cetera. It provides you inbuilt support for parameter passing. You don't need to think about what has been coming into the request. It provides you easy code reloading and other things again from the development environment. It provides you with NISP header responses so that you don't need to do like, craft your own custom header responses to be provided by your APIs. And along with this you have again, bundled together a lot of beauty of active record, action mailer if you're using mailing services, you have action, like active job, and then recently added action cable. My important thing, like my favorite amongst these is as and when we are progressing amongst these two like services, front end services, we have, like we come to see that there are a lot of services which we do not need to have rails and we can just store them, go ahead and store them in something like Firebase or MongoDB and just consume from them. My favorite reason for using these is active record. How many of you hate or love active record? See I said hate and love so everyone can raise. So that gives you, like active record is pretty powerful and if you love it, it gives you like pretty good handle over manipulating your data and exposing that data. Along with this or like the main source of interaction for your service is going to be action pack, which is your controllers and all the different things that happen in your controller. So action pack is going to provide you with very good like inbuilt things like your resource, routeful resourcing. It is going to provide you with URL helpers like blog underscore, edit blog path or things like that. It is going to provide you with inbuilt caching support, authentication, redirect, again, creating of headers, manipulate and like respond to accepting and responding to multiple different content types. Instead of crafting your own different codes, it provides you with easy generators and again it has very powerful support for plugins so that you can easily embed a lot of plugins, third party plugins which you can use in your application. So here's one example like RAC cause, which we'll see towards the end, which is again for having cross-origin requests. The simplest way to start creating chatty is the name of application we'll see towards the end is just say Rails new and this is on the RC version right now. If you're using that, just say Rails new, the application name and just pass hyphen icon API. The important part is you're just spiced when you're creating a new Rails application, you're just saying hyphen icon API and that's it. You're done, you have created your API app, you can start using it. So what basically this does is instead of having this whole bunch of things which are provided with your basic Rails app, it slims down a lot of things, it slims down a lot of middlewares that are in your basic Rails app and instead of, it removes them and gives you a slimmed down version of that. It removes, importantly it does not have any views, it removes a lot of craft from your action view because now you're not going to use your basic templates or your views, you're going to rely a lot on JSON templates, like JSON based resources. It also provides you with action controller API which is different from your action controller base. Again, it is slimmed down version of your bigger controller. How many of you have heard of action controller metal or used it? AC metal? Yes, so before API, when I wanted to use or provide a small slimmed down version, we would use action controller metal and instead of that metal, you would include whatever different number of modules you would like to use in your controller to expose a slimmed down version of your controller. So API comes, action controller API comes with same defaults for providing you with getting started with API controller again which is slimmed down. This is a slur default stack. I don't want to go deep in that but it has basic support for say send file, sending of files, static file, like supporting static file, request ID is login, like login support, callbacks, et cetera. All of these are like middle ones which are like the default stack for API app. You can again, based on your needs, you can add more middlewares or you can remove them, make your app even slimmer if you don't use something like you don't use a send file from your API app, go ahead and remove it. And the aim being that you want to keep your app simple enough and make it even more faster. On the action controller side, again your controller is slimmed down and it has basic support for say URL for, it has support for redirecting, it has support for rendering and bunch of different things which are listed over here. Like parameters passing, patterns wrapper, instrumentation, forces a cell, et cetera. And on top of this, you can like go on and add multiple different other modules, include those modules for having, let's say like translation, you would like to use translation, go ahead and include that. Or you would like cookies, you would include that and extend your particular controller. I am not going to deep into how your API app should be because that is literally a completely different talk. My main point of like trying to focus was how Rails is moving towards a way that you will have slimmed down versions of your app so that you could support these kinds of and actually develop and have an environment where you're only focused on building your API services. You can again extend and reduce however your app needs to be. My next focus, point of focus is going to be action cable and how that is relevant and why I like it. So this is something which has been like pretty exciting thing. It was introduced at the last RailsCon. And it allows you to have web socket-based, like real-time communication-based updates in your Rails apps. What is action cable? So how many of you used any of these services or have used something like web socket? Everyone else writes HTML, I'm just kidding. So if you or have heard of these services. So these services allow you to have something as called as PubSub or Publisher subscription-based model wherein previously what you used to do is, hey, I have pressed this button. I want to have more information about this page. Go ahead and make a request to that web server and render the whole page. That was pretty huge. Then we moved on to the thing like, oh, I don't need to do that, I have jQuery. Why not just get this part of page, get that as HTML and just go and append that to a particular page. So I will say, hey, I pressed this button. Go get that part and update over here. Or you would have a page wherein you would have some interactions like a dashboard and based on that you would like to update some information getting it from the backend server. Many of you like, even I, what we would like to do is have polling that is every one minute go and try to fetch some data from the server. Has something changed? Yes, something has changed, go and update my page. This is expensive on your server as well as on your client because you are unnecessarily going and pinging your server. Hey, give me some data. Instead of this, the alternative model is you have a subscription to your server saying, hey, I'm opening a connection. If there is any change on the server, let me know about that change. Instead of I asking you, you let me know about it. So that's what how PubSub works. You create, you have a publisher, you have a subscriber. Your client is going to subscribe to some updates. Think of these in terms of Redis. Everyone has used Redis or have heard of it. So Redis has in the same terms PubSub which is, I don't know if it's quite used or not, but I use it a lot for having like same PubSub ideology. Where in you have a channel and on that channel you're going to publish or subscribe to some updates. Similarly, we'll map those concepts to ActionCable wherein you have dedicated server side components which represent your Redis side of components. Where in you have your connections that is how you connect to your Redis and then you have subscriptions that is on this. I didn't do that. And then you have subscriptions that is on this connection. We are going to subscribe to certain part of updates. You don't want all the updates, you only want updates related to say a message. And on the client side, you'll have similar components which in ActionCable you can implement using JavaScript or CoffeeScript, your choice. And the main important concept being here of consumers, your main important function of your client is going to be that of consumers and whatever it is, there's an update. You will see that data and update your pages. We saw this. So on the server side, so we look into deep on both of these sides. On the server side, we have four important things or three important things over here which is connections, channels and subscriptions. Map these again to your Redis. You have a terminology wherein you have a connection to Redis. You have a channel where you're listening to a channel on Redis. And then you have subscriptions which is actually going and receiving and sending of data on that particular channel. So let's take a look at how connection will be represented in your ActionCable. So connection you can think of in terms of when there is a client, we have a server running to receive more connections. When a client comes and loads and says, hey, I want to create a web socket from this page to the server. It will go and create a connection with your server. That connection is going to be represented by this object behind the scenes on your server by a connection object. Here is the place where you're going to use to specify connection-specific information like how you identify this connection. So let's say a user is connecting by his user ID. You will use that for identifying this connection which you can use later on. Or you can provide things like authentication. Do I allow this connection to this particular user or not? And this is the basic fundamental thing that is going to be used throughout your backend. Then we have things like channels. Again, these are like a channel similar to how you have in Redis wherein basically you'll have the main channel over here which is application cable channel similar to how you have application controller. Here you can define your application-wide information regarding like have all those things that you need to do all across the applications at one place. And then based on multiple different things like you may have an update channel, you may have a user channel, or a message channel, you can have different channels. After you have these channels, you are ultimately going to end up using these channels by way of subscriptions. And these are the things that actually go on inside your channels. Like you see over here, we have subscribe method. So this is the main entry point when the client is trying to connect with your server, whenever there is a connection being created, the method subscribed is going to be called when you can perform some setup method, like say identify this connection and store that this client has been connected to me or not. And then you can have your custom actions over here which can be anything like post broadcasting some data back to your client. On your client side, you have two different notions. One is of consumer connection and the subscription that is used for connecting to that particular connection. So connection, like your main connection of your app is again going to be a global connection. It is going to be an object, this is again picked out of how it is provided as is. We create our main connection by means of application cable dot create consumer. If you notice over here, what we have is this create consumer method over here which is provided by action cable. What this says is, and we are not passing any parameters over here. So what this says is when this is used from inside your real application, create a connection and try to create a connection to the default URL, to the default server where I am being loaded. So the URL over here for like in terms of web socket you need to provide to which server I need to connect to. So this is kind of picked up automatically from your application template. This is important to note because in cases of your apps, your apps may live on multiple different apps. Here is the place where you're going to say, hey, my Rails app is running on Ruby on Rails.org. Passing the URL over here, WS, whatever the protocol is, and ask it to connect to that particular server. After you have created this connection, ultimately you're going to use this connection to create what are called as subscriptions to channels. We have discussed about connections on server, subscriptions on server. These are going to be represented on your client in terms of subscription. What I'm seeing over here is on load of my page, create a subscription to this particular chat channel. So I've loaded the chat page and what I'm saying is go ahead and create a connection. I want to receive updates from chat channel and then I can pass custom parameters identifying what chat channel do I want to connect to. I have a chat based service. I'm saying, hey, I want to go, I have gone to the best room or a specific room. I want to listen to all the updates which are being sent there and that's how you can identify it by parameters. We have these two things. We have a server, we have our client-based things represented by connections, subscriptions, subscribers. We are going to tie these together by means of two things. One is streams and the other one is broadcastings. Both of them have their own different uses. Is this visible behind? Yep, okay. So streams are what we are going to see as an example later as well are the basic, we have multiple different methods for streams like you see over here. Streams are the basic way of saying, hey, when some update is being done, stream this data, whatever broadcast is done on this channel, stream it straight through the WebSocket and send it towards the client. That's all the stream methods do. Here it says stop all stream, stop all connections which are active, stream from, stream from a channel, this channel, and a connection identified by chat room. Remember that previously what we were doing is we were passing the room over here. The same room is made available in your params hash. Params hash I'm going to use to identify the connection I'm going to create over this particular channel. Similarly, we can also use another method which is stream for. It is a convenient way of using your active record objects directly. It will automatically create the ID for you and start streaming based on this particular active record object. After you have the streamings, other way of communicating is that of like you have these stream set up, you want to actually send the data over it. What you're going to do is call the broadcast to. Everyone is awake. This is the main thing that you need to know. Broadcast is the way that you're actually going to send information from your server to your client. What you're doing over here is we are identifying. So in previous case, what will happen over here is I will say chatchannel.broadcast to the message room, the name ID, that ID. Identify that ID and send the payload. This is going to be the payload, right? Similarly, you can broadcast directly to some active record object and say, hey, I have some new comments on this post. Go ahead and update all the posts, all the comments for this particular post. Make sense? Yes, no, I don't care. All right, on the client side, when the broadcast happens, similar to how you have web sockets. Again, how many of you use web sockets? Oh, quite a few. On web sockets, you have a structure like websocketconnection.on, and then you provide a block on the client side which says, hey, on receive of some data, do this. On connecting to a client, do this. On connecting to a service, do this. Similarly, we can map those concepts on our client side in ActionCable like we have provided over here, on received. We also have on connect. So on receiving, whenever a broadcast is done, the method received will be called with the data that is provided. So in previously, we had this payload, this payload of title and body will be received over here in this data. After receiving this data, then we can take this data and then go ahead and send it towards some custom method wherein we use that data to update some part of this page. Here, I'm just doing like append HTML. This is not going to be a final objective, but here, we're just using this data to create some HTML out of it, and then we are appending it to the page that, oh, some update has occurred. I received something from the server. Go ahead and update my page. This, like, WebSocket communication is two-way. So from your WebSocket itself, you can send something back to your server. And ActionCable makes it super easy to call your server, like, your methods on your server as well. So here is how what you would do is say this dot perform, and this is something like from within your subscription, you would say perform and some method name. By calling this, what will happen is it will perform or call some custom method that you have defined in your channel. So what will happen is it will call the follow method in your message channel and deliver this payload, message ID. You can also send some arbitrary data to chat channel where it will call the received method on the server itself. But this is important to follow here is that you can call custom methods and this is ultimately what you will end up doing is call some method which is going to be performing different actions based on what kind of interaction you want to do from a WebSocket. So we have all of this setup. We have a server. We have a client. Then to start, you actually start using this in your services. There's something that you need to take care of. We need to allow requests to be from different origins. So WebSocket needs to be like Rails by default says that the request should be from the same origin. Why this is so that some requests, some random requests from some different domain should not be allowed to execute some task on your particular application. So that's why we already have this setup in Rails. You should allow, you should add your domains from where you're going to run your action cable service so that your action cable service can actually communicate. And then you'll have disable request forgery. How many of you know what is request forgery? Or CSRF? Yeah, CSRF everyone knows. So to allow this, like CSRF is basically to disable, like not allow cross-site scripting. So to allow our service to actually do that by default Rails has CSRF. To allow the WebSocket to communicate, we would need to disable a part of it and that is what we are doing over here. All right, we have done all this and how we are actually going to run our action cable service. So one important change which Rails by brings is it started using PUMA as the default server. It used to use Bebrick before and one of the important decisions to add PUMA was that action cable needs to have concurrent connections and this is what action cable gets a lot of power from having PUMA as the default server so that PUMA is a concurrent server so it allows to have concurrent connections or gone-going from your own particular server. There are multiple different ways of deploying your action cable server. It can be embedded within your Rails application or it can be like you have a Rails application then you have independent action cable server which is just going to get connections and interact with those connections. We'll take a look at that kind of way of handling your action cable connections. Finally, we have the third piece of our architecture which is the front end. I'm just thinking about React.js over here. It doesn't need to be that. It can be your own favorite framework. I don't mind whichever framework you like. It can be Angular, it can be Ember. I'm just going to say a bit about React.js. I'm not going to go pretty deep. Just a few points about React.js. How many of you have heard of React.js? How many of you have used React.js? Cool, so just to give you a brief about it, this example is straight away taken from the Getting Started guide on Facebook. What React tries to do is it tries to define your app in what are called as components. So here, what I'm doing is I'm defining a hello message component by using react.createclass and I only need to have one important mandatory method, which is render. This render needs to supply or return back what HTML I need to display on my page. Important thing to note over here is I'm using HTML from within my JavaScript and what is being used over here is called as JSX which is JavaScript XML notice. What's that? Yeah, that. So it allows you to have this kind of syntax from within your HTML and it allows you to embed your custom, your JavaScript data inside of your HTML. What I'm doing over here is the data that I'm passing over here when I'm rendering, but render I mean actually display the component at some mount node. I will be passing some information over here. So this is my component. I'm saying render this component on my page and when it is rendering, use this information. Again, just basic HTML over here. Yeah, it's a bit bigger component. What it is doing is it is a simple timer. It is just what it is doing is it is having initial state. Initial state is kind of like your constructor where you're defining the initial mutable state of your component, something that you're going to change. A tick is a method. So we have a timer over here, timer object which is every one second it is going to update the data. Seconds elapsed. I have component did mount which is a lifecycle method. What it does is when the component is rendered, it is going to say every one second, set an interval that the tick method is going to be called over here which is going to increase the seconds. And we have component will unmount that is on unmounting. Go ahead and remove the interval that was created. And finally, we have the render method over here. Now why is this important or pertinent to our, like relative to our example is that here I'm not doing anything like dot HTML dot append or dot HTML like dollar dot do something, manipulation on my page. All I'm doing is I'm just changing the seconds elapsed in my particular state. Set state is actually to change the state of this method, like component. Why this is important? It fits perfectly in terms of your action cable or service like that, wherein you're not going to perform any changes when some new data has been provided to you by the server. All you're going to do is some updates are being done. Action cable will send it, update it over here. The data will be received over here. It will just update the data, react will take care of, or the service will take care of updating your view based on whatever the information is. This helps to reduce a lot of complex and custom logic for updating your views. A bit about life cycle because we are going to use it. React has this life cycle of component creation, component mounting. These are some of the methods, like will mount, dead mount, initial state for initial, like mutable state. Props, which are like properties which are passed as parameters to the component which are non-mutable. Render what is actually being rendered and other methods like which we are not interested in like component will and mount and some other custom methods. I'm not going deep into that. You can read this book that I finished after a year. I don't know how that board got over. So you can read this book, React.js by example, which goes through a lot of actual app examples instead of going through chapters. It goes through apps and tries to see how you can build apps. And with that, I'm done with the main three parts. Again, sorry, that was for later. Don't see that. I'll be going through these two examples now as demos. Before that, is everyone awake? Hey, can you clap? Oh no, I'm not done. So I'm going to do two demos basically and what those demos are going to be is that one is the main application examples. I have not done like build custom example. I'm just picking up the example which is available made available by Action Cable. And I've just modified it to be a reactive version like React.js version of it. So here I have the main, this is not visible, but that's okay. Here I am running, yes. This is the Rails application. I'm running the Rails application which has Action Cable tied up with it. And this is a very basic application. If you can see over here, yes, it's running on localhost 3000. Is this visible? Yes, no. So it is very pretty primitive. What it does is it has four users, hardcore users. You can just log into one of those users. So I'm going to say, I want to log in with notorious big. And then I want to listen to messages, like live comments on some messages. And we have some message like the schnitz over here. And it is a message over here and it is just basic architecture, posts, and messages, like message and comments on that message. We have message over here and like, whenever I comment over here, it goes back to the server and is going to update. This is on the, like this is not in incognito, this is in incognito. What I'm doing over here is I'm running as a different person over here and I'm going to go on the same message. And what I expect is when some person from here, and hopefully that works, whenever I type something from here, it should send it here. Oh, it worked. Yes, it worked. So this is right now, it is on the same application. It is running from Rails. It is all doing the things inside of Rails and I have five minutes left. Awesome. So all of this is done from one single application. This is all okay, but my main like focus of this presentation was you can have this Rails application, but you can have other applications like I'm running a node application over here just to make sure that I'm doing that and I'm not lying. Here is a node app. Yes, I know how to do node. I'm saying npm start, it is starting on localhost 9000. Yes, and here we are on localhost 9000. So this is being served from my node application which is a very basic ReactJS application and again what I've done is it is hard-coded to listen on messages that message ID with message ID one. So you see this message over here is again being saved over here. So we did not have this, but a week ago or a week or two ago, we package like a end-page package was added and will be supported officially by Rails for Action Cable and then you can start using this Action Cable package from your node applications as well. So let's see if this works. This is my Node.js application. This is my Rails application. We are running on different servers. This works as well. Yes, it works. I have to scroll though. You see this? I hope so. Oh, let's do this. Yay. Post. Nothing is happening there. Yay. So this is awesome because now we can have a Rails server act as a point where it is not doing anything but just communicating over a web socket and API to update these different apps like mobile app, your node app, your Ember app and communicate over this particular web socket which is sending tiny bits of data and updates which is pretty awesome. I'll just go briefly over the example. Oh yeah, and it works. So this is like how this is basically a setup. We saw how the subscriptions are made. We have the subscription which is creating, subscribing to the comments channel. In our React component, what I'm saying is when the component is mounted, call this setup subscription and in this setup subscription, I'm going to create the subscription passing the message ID to which I want to listen and then say follow, a method which is on the server and on receiving of this data received, all I'm doing is just updating the state and the React component will take care of, like take care of updating my web page. On my server side, I have to do nothing else but just set up this state where it's follow, where it is receiving data and saying, oh, you want to listen to this message ID? Go ahead, listen to this message ID. Then to actually deliver it, you will call the broadcast to this message ID, send all the data whenever a new comment has been created. In conclusion, the takeaway that I would like to have is you have these monolithic apps. Now, when you come across that, you have a requirement wherein you want to build an isolated more alike. In our case, we have some examples where a client already has a front-end app and they want to extend it or build something on top of it. A very good way of doing that is having Rails API or slim down version of this API and provide all these services which then can be consumed again by these multiple different services like React, Ember, et cetera, mobile, which makes pretty much sense to have this kind of architecture for just manipulating your data source. With that, I'm done, thanks. We have 30 seconds with 30 seconds question. I saw the reaction cable repository and the subscription adapter not only support ladies and the PG. So is there any way, is this easy to, I want to use that maybe NQ or Firebase? Yes, so this question was about having different adapters. I was picking all in terms of Redis. So the communication or receiving of data behind the scenes happens in terms of an adapter. You can have by default, we support Redis, we support Postgres, you can define your own adapter to use that kind of PubSub service behind the scenes for managing all the PubSub that is happening on ActionCable. So yeah, you can do that. Does it work with React Native? I need to experiment with that but I would love to have that work. The only thing that I would need to see is the WebSocket support on React Native. It would basically work in WebViews but on like ActionSocket support for like NativeSocket support, I need to check. But it will work on WebSockets, like WebViews. That would be awesome, thanks. Sorry? Yeah, that would be awesome, I hope it works. Yeah, yeah, yeah. I wanted to do that but like I was sleeping. So awesome, thanks.