Lightning Talk: Building Real-Time App with React/Redux/Rails/RethinkDB

Summarized using AI

Lightning Talk: Building Real-Time App with React/Redux/Rails/RethinkDB

Steven Yap • June 24, 2016 • Singapore • Lightning Talk

In this lightning talk, Steven Yap, founder of Futureworkz, discusses the challenges and solutions involved in building real-time applications using a modern stack comprising React, Redux, Rails, and RethinkDB. Steven humorously notes his journey to attend the Red Dot Ruby Conference and introduces himself as a full-stack developer and agile coach. He defines real-time applications as those that can update data without requiring a page refresh.

Key points discussed in the presentation include:

- Real-Time Application Needs: Steven emphasizes the necessity of establishing a WebSocket for real-time capabilities, particularly using Rails 5's Action Cable, alongside addressing complexities with user interface updates involving jQuery.

- Challenges in Real-Time Data Handling: The talk highlights issues such as broadcasting messages to the appropriate clients and maintaining synchronization between data models and views.

- Decorative Programming Approach: Steven advocates for a decorative programming approach, which focuses on defining the end state rather than the process. This helps simplify updating the view with React, as its components render automatically when the underlying data array changes.

- State Management with Redux: He introduces Redux as an efficient way to manage application state in a functional manner where 'actions' invoke 'reducers' to modify state seamlessly. This approach makes debugging and testing easier.

- Backend Broadcasts Using RethinkDB: The backend leverages RethinkDB for message broadcasting, allowing for real-time updates when data changes occur, all while maintaining tidy and understandable code.

- Collaboration of Technologies: The amalgamation of React, Redux, Rails, and RethinkDB leads to a system where the view, state management, and back-end logic are clearly defined and coordinated.

In conclusion, the talk emphasizes that using these technologies together can simplify the development of real-time applications and ultimately enhance the enjoyment of coding in this domain. Steven encourages attendees to embrace the decorative and functional approaches in building efficient applications.

Lightning Talk: Building Real-Time App with React/Redux/Rails/RethinkDB
Steven Yap • June 24, 2016 • Singapore • Lightning Talk

Speaker: Steven Yap, Founder, Futureworkz

Building real-time app is painful for the frontend, painful for the backend and even painful for the database. We will share how we build a real-time CRM app using React, Redux, Rails and RethinkDB (we call it the R4 framework) that is easy to reason and easy to build. Put fun back into real-time app development!

Speaker's Bio
Steven Yap is a full-stack coder, agile coach and development consultant. He balances his life with Buddhism teachings and seeks enlightenment through coding and the work he is involved in. He founded and runs Futureworkz, a Singapore Agile agency since 2005. Steven Yap hosts the monthly Ruby Meetup in Ho Chi Minh, Vietnam - Saigon.rb.

Event Page: http://www.reddotrubyconf.com

Produced by Engineers.SG

Help us caption & translate this video!

http://amara.org/v/ONqI/

Red Dot Ruby Conference 2016

00:00:13.340 okay hi guys I'm Steven I'm gonna talk
00:00:16.020 about building real time X we bla bla
00:00:17.850 bla bla
00:00:18.390 okay I'm messing up or in I'm a
00:00:20.880 Singaporean from Singapore
00:00:22.260 alright I'm actually Korean serving my
00:00:24.240 national service that's why I couldn't
00:00:26.550 join the Ruby conference yesterday in
00:00:27.900 this morning yeah and I only managed to
00:00:30.240 actually sneak out this afternoon
00:00:31.529 through the jungle as you can see in the
00:00:33.390 picture over here just to deliver this
00:00:35.280 talk to you guys all right okay just
00:00:41.820 it's just joking for the record of this
00:00:44.190 video in the YouTube
00:00:45.510 I've actually approved queries for my
00:00:47.489 commanding officer to come here by the
00:00:49.469 top alright this is for the record
00:00:51.210 okay all right a little bit about me I'm
00:00:54.600 Steven this is my profile I'm a
00:00:57.870 programmer myself consultin this the
00:00:59.969 company I will aim we do awesome Ruby on
00:01:01.949 Rails development just at you guys here
00:01:03.180 I also host a Saigon RB the Ruby meetup
00:01:06.689 in Ho Chi Minh so you will do it on the
00:01:09.479 first Tuesday of every month so if I
00:01:11.189 mean what you mean
00:01:11.880 please come and look us up all right
00:01:13.619 what is the real-time app basically just
00:01:15.840 define data user that doesn't need to
00:01:17.759 actually refresh the app to get new data
00:01:19.520 okay and the first thing that we need to
00:01:21.659 do right is that you get a web socket up
00:01:23.549 and this can be easily achieved in Rio's
00:01:25.799 5 action Kiba
00:01:26.850 okay but that's just not all there's
00:01:29.070 other challenges some of it that we
00:01:30.900 actually face right is actually updating
00:01:32.729 the view using jQuery you need to do all
00:01:35.250 the prepend pria prepending appending
00:01:37.799 changing the inner HTML and it's really
00:01:40.140 very troublesome and messy and next
00:01:43.649 thing that we need to do is doing all
00:01:44.939 the broadcasting when you broadcast the
00:01:46.710 right message the needed changes to the
00:01:48.540 right clients and we also need to look
00:01:51.210 at chain reaction when the application
00:01:53.700 is sufficiently complex there will be
00:01:55.470 things like one view updating a model
00:01:57.450 which of the another model and then
00:01:58.890 after they upscale another model again
00:02:00.450 another view again
00:02:01.799 yeah and all these challenges arises
00:02:04.380 because we're trying to sync the data
00:02:06.299 with the view we are actually trying to
00:02:08.910 control the flow and the mutation of
00:02:11.039 order data
00:02:11.970 and with all these right there's
00:02:14.310 actually another way to solve all this
00:02:15.840 problem you can try to do decorative
00:02:17.700 programming which is actually trying to
00:02:19.710 describe the end result without
00:02:21.090 describing how to achieve it we don't
00:02:23.070 need to care about how the data or the
00:02:24.720 view is actually mutated so let me give
00:02:27.510 you some of the example like in the view
00:02:29.790 we use react yes okay so this example
00:02:34.890 there's a code about a really on
00:02:37.050 the Left I have the real gist component
00:02:39.210 and what this does is that you simply
00:02:40.620 renders out the messages that it was
00:02:42.870 given so we just need to say if there's
00:02:44.790 no messages I will just return no no
00:02:48.360 messages available and if there's
00:02:49.800 messages I'll just list I was just a
00:02:51.690 theory up yeah and given an array we the
00:02:55.860 react component will always render
00:02:57.420 according to the array and when your
00:02:59.160 array change rear gs will automatically
00:03:01.680 change it yeah so this very decorative
00:03:03.480 which I need to say how the end state
00:03:05.070 needs to look like and we don't have to
00:03:06.570 care how the dome is actually being
00:03:08.010 manipulated okay so decorative approach
00:03:11.190 to our views and then we don't have to
00:03:13.290 do all the trouble something or
00:03:14.700 prepending appending adding here and
00:03:16.410 there changing and there and then we can
00:03:18.000 see our view and state very clearly very
00:03:20.850 easily all right and then we can and we
00:03:23.760 move on we need to handle a lot of
00:03:25.410 different data and stay in our front end
00:03:27.600 alright and we try to use redux which
00:03:29.730 the javascript idea alright so so in
00:03:34.230 this example in this example we take a
00:03:38.130 very functional approach to us our fun
00:03:39.870 and state management and whenever we
00:03:41.610 have a change which is what we call an
00:03:42.959 action we write a function what we call
00:03:45.900 reducer they will mutate the state
00:03:47.549 currently and return it like in this
00:03:49.320 case right give it a new change call and
00:03:51.209 message we will simply add the message
00:03:52.950 into a state and just return it and we
00:03:55.049 like react render it accordingly all
00:03:58.799 right and using this decorative
00:04:01.620 functional approach to us our fun and
00:04:03.510 state management we make our fine state
00:04:05.730 the data or the mutation very easy to
00:04:08.549 understand and he also makes it very
00:04:10.890 easy to test ok and can we actually
00:04:14.010 apply decorative style to our back-end
00:04:16.169 the answer is yes and we can use it as a
00:04:18.930 soft rock casting messages problem in
00:04:21.000 real time yeah
00:04:22.320 so in real in broadcasting message
00:04:24.659 in order create update and delete
00:04:27.819 operation with the database you often
00:04:29.500 need to update the views what are the
00:04:31.449 different changes for the clients why
00:04:34.060 it's needed and all these broadcasting
00:04:35.620 messages will be found in your active
00:04:37.449 red car active job callbacks all over
00:04:41.050 the shop all right so we we will be
00:04:43.509 reading DB it provides us a decorative
00:04:45.250 style to broadcast messages and this is
00:04:48.310 sample code in our action cable channel
00:04:50.740 room okay we tell written DB for any
00:04:53.889 changes in the message table that has
00:04:56.680 the current if the receiver has the
00:04:59.860 current a user ID please stream to me
00:05:03.400 order changes alright just broadcast to
00:05:05.889 me Auto changes so we just say what we
00:05:07.659 need and that's decorative approach and
00:05:09.969 this is a sample that what we think the
00:05:12.550 view and she stream it to ask you tell
00:05:13.870 us what's the new value and what's the
00:05:15.099 oval you and then our Redux would take
00:05:17.740 care of the statement state change
00:05:19.419 management and then update you pass a
00:05:21.069 new state over down to our react GS and
00:05:23.860 they will render it accordingly
00:05:25.539 so everything is decorative so in
00:05:28.389 reading DB we take a decorative approach
00:05:30.969 towards broadcasting changes and we can
00:05:33.610 we can keep our broadcasting code in us
00:05:36.219 inside our channel subscription and it
00:05:38.050 makes everything very tidy okay and it's
00:05:40.719 very easy to understand which client
00:05:42.699 this user role means what kind of
00:05:44.620 changes okay so why of them up we have
00:05:48.190 our react yes which is a almost like a
00:05:50.500 pure function of the view okay and then
00:05:52.870 we have a Redux which is like a single
00:05:54.339 sort roof because it contains all the
00:05:56.139 state and you manage all the state and
00:05:58.930 then after that you still have our rails
00:06:00.789 doing the back business logic and
00:06:03.400 holding the WebSocket connection and
00:06:05.710 then we have seen that the reading DB
00:06:07.960 which is like a single source of
00:06:09.159 broadcasting okay and with all these we
00:06:12.099 have the benefit that we are able to
00:06:13.689 reason our back break easily
00:06:15.310 stalling errors data errors logic errors
00:06:18.360 broadcasting errors we can we know where
00:06:20.589 to find them and then it makes doing
00:06:23.229 real-time app development much more
00:06:25.300 easier and when it's easier it is more
00:06:27.879 fun these some resources for y'all
00:06:29.800 thank you very much
Explore all talks recorded at Red Dot Ruby Conference 2016
+17