XO Ruby Atlanta 2025 - Overreacting—From React to Hotwire by Igor Aleksandrov

What is discussed, and when

1. 0:00 – 5:00: Safari Portal, Docker, Jet Rockus, Savier
2. 5:00 – 10:00: Safari Portal, Stimulus
3. 10:00 – 15:00: Stimulus, Safari Portal
4. 15:00 – 20:00: Docker, Rodaus
5. 25:00 – 28:18: Stimulus

Notable quotes from "XO Ruby Atlanta 2025 - Overreacting—From React to Hotwire by Igor Aleksandrov"

• I'm CTO and co-founder of Jet Rockus software development company. I'm a Docker captain. So if you have any questions about containers, about deployment, about all this stuff…

  about Docker · at 1:01

• A react single page application that was called and that is actually called now Safari portal and we actually succeeded. We were quite successful. We got several awards as a tech company as a project.

  about Safari Portal · at 1:57

• Stimulus didn't exist five years ago.

  about Stimulus · at 5:35

• Based on GWT tokens and in Rails we have cookie based sessions. We've been using Rodaus. I highly recommend Rodaus for like everybody who wants to build an indications that…

  about Rodaus · at 17:33

Who and what is mentioned in this episode?

People

• Savier — Person · 1 mention · first at 0:39
  About Kamal about deployment. This is where I got this where I met Savier in Brazil. But today we'll talk about more front end stuff of Rails and like I will try to do my best before we'll proceed to the technical side. this is me speaking.

Companies & orgs

• Kamal — Company · 2 mentions
• Jet Rockus — Company · 1 mention · first at 1:01
  Technical side. this is me speaking in Brazil. I do rails since 2009 and I'm CTO and co-founder of Jet Rockus software development company. I'm a Docker captain. So if you have…

Products & tech

• Safari Portal — Product · 4 mentions · first at 2:01

Concepts & topics

• Rails — Concept · 5 mentions
• React — Concept · 5 mentions
• Stimulus — Concept · 4 mentions · first at 5:35
• Docker — Concept · 2 mentions · first at 1:05
• Turbo — Concept · 2 mentions
• Rodaus — Concept · 1 mention · first at 17:40

Full transcript with timestamps

0:20 So it will not be my typical [snorts] speech because usually I talk more about backend stuff about deployment. You can probably you can find my name in Kamal repository. You can listen to my talk about Kamal about deployment. This is where I got this this where I met uh Savier in Brazil. But today we'll talk about uh more front end stuff of Rails and um like I will try to do my best um before we'll proceed to uh the technical side. Uh this is me speaking in Brazil. Um, I do rails since 2009 and I'm CTO and co-founder of Jet Rockus software development company. I'm a Docker captain. So if you have any questions about containers, about deployment, about all this stuff, you can ask me and sometimes I do open source. Uh, I really like DH open source because as I told it can provide you a lot of benefits. Um, this is also me with my family. uh two and a half months ago in Atlanta airport. Originally we are from Russia

1:31 since March 2022. We lived in Georgia as a country. This is a country I really love. You should visit it uh if you want to have a great vacation. They have good food tradition, exceptional wine tradition if you like wine. And uh I'm a Eban visa holder. So that's it. So um five years ago we started building a react single page application that was called and that is actually called now Safari portal and we we actually succeeded. We were quite successful. We got several several awards as a tech company as a as a project.

2:15 Everything was great and uh we grew up together with the project and the team grew up. So everything was good and in 2024 we decided to switch completely back to Rails and now I will tell you the reasons the experience and what we got from this decision. So first of all um why I want to share this story because sometimes we make our decisions not because we want to do our best but because we just like some tools we like some technologies and we do not care about what will happen in in future in future perspective and besides this nobody like talks about simple stuff. uh every time I every time I open YouTube to watch some videos from the conference I I often close it very quickly because I don't understand a single word like sorry but this is how it's happened to me and I think it's good to talk about simple stuff because again developer uh junior developers come to the conferences and then watch this YouTube

3:21 videos because they want to see a real problem solving not something that they do not that they do not understand completely but like a simple real stuff. So um quick introduction what Safari portal was a year and a half ago. So it's itinerary builder with u that allows you to create beautiful itineraries for luxury travel legends tour operators. It was pretty big uh React application with uh a lot of line lines of code with uh more than three and a half thousand files and uh a lot of packages and dependencies. You know this front end technologies they have a lot of dependencies usually gigabytes of dependencies. We supported 22 languages and our team was somewhere around 12 developers both front end and back end.

4:15 And this is how it look like. You could create some nice itinerary share with your travelers. And uh we have some React track drag and drop features blah blah blah. All was scrolling all was like everything was great. This is how it looked like. We covered almost everything from transfer to your recommendation. Look very good. So speaking of technology, it was React create app uh Redux for state management, React Router, Axio, IATN. On the back end, we had Rails with REST API. So pretty much a common technology choice for single page application especially five years ago when we started it.

5:03 So why we decided to do it in React? Because everybody used React five years ago. Because five years ago, we didn't have turbo, we didn't had hot wire. There was a turbolink, but the turbolinks was just like a small part of what now turbies and rails was on rails on on version 6.0 with a webpacker. Do you like Webpacker? No. Stimulus didn't exist five years ago. But react react was a nice stuff. It was very major ecosystem with some parts of it uh appear every two months but but still every developer want to do things in react and we didn't have any problems hiring new people because everybody want to do things in react and like we as I said we succeeded the project still exists it grows up so we made the right choice The good part was that uh some things out of this out of this application were really really worked well like we were able to create a rich user interface with a lot of fancy

6:26 elements on it and for example we were able to do PTF generation just in browser because we already have everything in browser and we just what we had to do to to call a PDF export and boom we're done. developer experience was also good with hot reloading that again wasn't available in in Rails five years ago but everybody wanted it but there were some bad parts and the bad parts is that with every JavaScript technology almost every JavaScript technology but especially with what we started with five years ago with Redux you write a lot of boiler plate for each and every action that you want to create and sometimes um you don't want it and build uh build times we started with about like 1 minute to build our react application then it grew up up to 2 minutes 3 minutes 5 minutes 10 minutes so we ended somewhere around 15 minutes to build the front end application while deployment not the things that you want

7:27 to have yes the deployment complexity also grew up because we need to coordinate deployments between back end front end we need to make contracts uh for the API we need to coordinate back end and front end teams. And our code looked like this. For each single request to the server, we had to worry about some uh response statuses and blah blah blah. Use some locks and like I don't like it. Anyway, uh what was really going bad is that every task that appeared in our task tracker, it required us to switch the context between the React logic and the Rails back end and you know how it happens. Uh you you see a very simple task but every time you start to discuss it with the front end team or with the back end team every part of this team says that no no no no we're not we're not going to do this they will do front end will take care of this. Okay. when you go to a front- end engineer and he says no no no

8:27 no no no we cannot process process all this data go to the back end because this data should be processed on the back end and we will only display it so one year ago founder and uh CEO of Safari portal came to us and said that she want to have an next evolution of the platform completely different stuff so Safari palter portal uh within a year should become not just an itinary builder but a full cycle CRM with a lot of new stuff. For example, we had to build like task manager uh contact management uh financials with integration with different payment providers, payment tracking, custom form builder. The problem is that uh the budget should stay the same.

9:20 You know how it happens. So four new modules uh in 12 months like about 12 months about four new modules and with the same team size. Uh so we quickly understood that react uh is becoming a bottleneck here because as I said uh each new feature required us a backend developer, front- end developer, manager who will coordinate all this stuff with [snorts] them. Uh contract design, state management, planning, integration testing. So like limited developers, unlimited ambition, there was a situation that we had. Besides all this uh AI came to the industry. So one year ago uh the situation happened that almost everybody started to use cloud code chart GPT copilot and the biggest problem is that stakeholders also started to use AI and the question that we were asking is if AI can write things fast why don't you can why you still require this two weeks to add a new screen this is what Besides all this, uh, within within a

10:36 week, within a month, everybody got zero tolerance for bugs because AI can solve all the bugs. Why we having them? I I pretty much sure everybody felt the same one year ago. Uh the good news is that in 2023 2024 we got an amazing hot wire experience. We built a couple of projects. Some of them are quite successful like orbit and others are not but still and we built them completely without any front end any front end technology. We just use hot wire we just use stimulus and that's all. And we succeeded all these projects uh from our side.

11:21 They were built like a for with a team of one back end engineer and one front end engineer who was uh usually responsible for a markup for CSS and that's all. And we decided that we can probably try the same solution with Safari portal like why not? Of course there were like risks that we had to take because Safari portal was already an existing project. We we cannot couldn't start from scratch. But uh we know that we will face some problems issues for example how to share the authentication between the react and the server side rails application. uh how to coordinate again deployment of uh both react part and trails part. How to coordinate routes conflict manage conflicts and uh the the biggest issue is how to get how to provide the user experience the seamless user experience for our users. How to get consistent UI and UIX across two different apps. But still the potential uh payoff that we could have was

12:30 definitely worse than the risk because uh we just calculated everything and decided that we we can we can take we can take this risks before we'll proceed to actual problems and uh results that we got. I just want to have a quick hot wire dive so you will not for you will just remember everything that you knew before. So hot wire is actually an acronym for HTML over the wire and turbo drive is responsible for fast page navigation. This is what turbolinks were in uh 2020. Turbo frames and morphin is uh respon is responsible for page updates and turbo streams uh uh allows you to do changes over websockets and u other real time st uh stuff and there is also stimulus that sprinkles some JavaScript uh fancy code inside of your HTML application. So we decided that we will try to uh migrate the existing app to work inside of rails and together with rails.

13:42 So this is what we had before. Uh this is a very simple schema but of course it's not uh strict but I think you will get some understanding. So we had an container before that routed every request to the react in another container and this react application was getting loaded to your browser. The browser made some requests again to the to engin uh under API domain was resurrected to rails. Very common situation in what in in single page applications. I think like everybody else has almost the same. We decided that we will try to as I said to keep all the leg legacy features existing features inside of React. We will not rewrite anything but try to create new features in in rails with hotfire somehow share infrastructure between all this and um try to s to get some success in this.

14:42 So this is what we ended with. We have an incoming request coming to any proxy server. In our case it's kamal proxy maybe it can be tri or jinx or anything else. and it wrote everything to Rails container. Very simple. Rails handles everything with raster and puma. Uh it serves both static files and uh dynamic content. So the question is where is the react in this scheme? React is there. React is just a static file. It's nothing more. It does not require any any infrastructure from you. It does not require almost anything. If your rails all already serves some CSS, JavaScript, images, other files for you, why do cannot it serve react?

15:30 And this was actually uh like the innovation for us. The innovation is that you can surf react with the Rails controller in your development environment. you can redirect everybody to your React server that runs on port 8080. In all other environments, you can just read your public folder and that's it and it will work. Of course, you need to like change your routes somehow, but but still like why not? And the problem for us was is have to get React inside of Rails in production. And luckily we had we already switched to Kamal when we were doing this and we just we just uh decided to build react independently very similar to what we had before all these uh changes and uh at the end after Kamal has been built we copied everything to AWS and then in a separate job that actually run Kamal We copied everything back to uh to the instance where we actually ran command deploy command deploy and then

16:53 in docker uh file we copied the full front end folder from the instance to the image and we're done. Now we have an image of Rails that has uh pre-built React application inside of it inside of a public folder and we don't need anything else. we just can read it from the public for f folder just like every other every other assets that we had. Uh there was some still big question have to share authentication because usually what you have what you have in uh react you usually have authentication based on GWT tokens and in Rails we have cookie based uh sessions. We've been using Rodaus. I highly recommend Rodaus for like everybody who who wants to build an indications that will serve for for a long years. Rodaus is not just a not just a library. It's more a framework that allows you to build something above rails. It works it runs in a rack middleware and allows you to to create whatever you really needed.

18:04 So we did this. This is a part of our configuration and as I said is a framework so it has some hooks uh callbacks whatever you call them. So we said okay after we uh are getting logged in and at at this stage we already this is the only thing that we had to rewrite like completely we already moved our authentication process from react to rails. So the rails part was pretty straightforward. We just authenticated with cookie based uh cookie based session. But after we getting logged in, we started to redirect all our users to a special controller to a special rails uh pass that we call our GWT pass. And you will see what it does.

18:55 It uses Turba. It just sets up to the local storage. It sets up two tokens that React needs. Then we redirect our users back to the URL that was originally requested. But local storage already has access token and share token. React can read it and react can use it and boom we are authenticated in both front end I mean react part and the rails part. This is just a very nice example of how you can what you can do with turbo what you can do with standard rails tools uh that rail 7 and rails 8 has. Um yes uh at this time I wanted to give you some additional information about this slide I wanted to give you some additional information about view component and how we do it but I decided that Jeremy will do it better because he will give like a dedicated dedicated speech about this.

19:51 uh but yes we we are of course using them because in a big application it's almost impossible to like write everything from from scratch. So what we learned this is I think the most interesting part here. So rails is definitely a oneperson framework. We with this move with this risk that we took we got a result that our customer customer feedback is getting uh to production within within hours not days. We can literally fix bugs. We can uh respond to feedback with a single day and uh such things like AB testing and feature flagging became just a trivial.

20:34 We we don't need any additional tools. We just do it with our uh framework and that's all. and stakeholders they also can see some changes like immediately I literally can be on a call with the CEO of this of this project literally make changes and deploy them to production in like two three minutes and that's amazing this is the result that we couldn't get anyhow with what we used before and one of other things that we confirm it is that a single developer can finish a task from the beginning to the end without any additional help. So now we have the same team of about uh 12 developers and uh they can literally work on 12 different task at the same time. We need to combine the we don't need to combine this uh uh developers together to get work done. They can do it on their own.

21:34 Rails is uh Rails convention plus AI uh I cannot say to be honest extremely productive productive but more productive than other tools on the market because of the conventions because of convention over configuration because everything everything that we love in Rails in my personal opinion capilot and clot understands rails better compared to again other tools on the market because uh it's more like human readable so it's more AI readable and uh one developer with AI can sometimes deliver things faster than two developer uh two developer team before. But again this is because like two developer team were uh had to make decisions on API and all other all other things. And speaking of numbers, uh like a year ago we were about we we were doing about like 25 30 major tasks per months. Now we came up to like 50 45 55 60 task per month sometimes which actually like doubled uh our performance as again at the same

22:48 uh amount of developers. I love it. Some things were harder than we expected and this is actually big the biggest problem of all this stuff around rails. The biggest problem is that all the JS world is over centralized around React. You cannot get any you cannot get any libraries. You cannot get any good tools if you are not using React. For example, there is a React dates that is actually supported by Airbnb that allows you to quickly build this date selector in browser and there is no real alternative for it in vanilla JavaScript. There is easy peak but it's it's not even close to what React dates can do. Same situation is with with React Select.

23:30 everything that is on the market and uh does not support React. Sorry, but it's like piece of Let's be honest. Uh a lot of a lot of third party services, third party services that you will integrate with, they only have SDKs for React. And this is the reality. You cannot do and you cannot do anything. You become uh like uh sometimes you become useless. Absolutely. because you you you you just without React you you cannot build anything. Uh the solution here is that and thank you very much for SWAT and uh I know him personally. He's a great guy and for a martian they build this turbo mount scene and it allows you to build to like embed React big pieces of React into your application and it works it works really well. Uh for example here what is uh in this red boxes is a rail app and uh this is a react app that works uh inside this react component that works inside of the rail app mounted with turbo mount and

24:41 actually works and nobody understands how it works and how it build and we're using this in production. Believe me it's great. Besides all this uh there is again a Rails app. There is a turbo model window that is rendered uh above everything and it just works. Sometimes you need to embed uh Rails into React. For example, you have a fresh new Rails feature and you want to somehow share it into your React application, but you you don't want to build API for this because why do we need API if you have have uh server side rendering. So here uh this is a React application. This is the React part of our web app that still exists. And uh this is Rails model window that is rendered above the React application and even with this turbo navigation seamless turbo navigation and uh without getting this model closed. How does it work? Do you have any idea? I will show you. Iframes [gasps] and like yes all this model

25:56 window it works with an iframe it loads the rails cyhrame from the server renders it in react and you're already authenticated because we have this shared authentication and it's it's it's amazing. We have this uh iframe controller that is responsible to close this window when we need it. And that's all. Of course, we had we had some problems. We our react specialist, they had to learn like rails new layer. It was it was tough, but we managed to do this. Stimulus is something completely different from react and uh you cannot get you can get a lot of support with stimulus because uh unfortunately there are no big I don't know like huge examples of stimulus controllers. They are they exist but it's not comparable to react but again we we still we still love it. You will have like temporary productivity deep during learning but you still you still can do it.

27:03 Uh what is next? Uh the best thing is that we can gradually migrate the remaining react functionality. Eventually we will get rid of this big React app. we will come to a situation where we have we will have everything in rails with some react components but we we don't need to rush because hybrid approach that we have now it just works it allows us to like gradually migrate react into rails and nobody will even understand that they're using two different applications and we can focus on new features development not rewriting everything because stakeholders like owners CEOs wherever whoever is uh whoever actually owns the project they will never never pay you for rewrite something. It's it's impossible to to get this. But when you're uh releasing new features, you can gradually do this and nobody will even know that you're doing this. But you will be lucky. You will love it.

28:01 Thank you.

Questions about this episode

What is discussed in "XO Ruby Atlanta 2025 - Overreacting—From React to Hotwire by Igor Aleksandrov"?

In order: 0:00 Safari Portal, Docker, Jet Rockus, Savier; 5:00 Safari Portal, Stimulus; 10:00 Stimulus, Safari Portal; 15:00 Docker, Rodaus; 25:00 Stimulus.

What is mentioned in this Confreaks episode?

10 people, works and ideas are mentioned, including Rails, React, Safari Portal, Stimulus, Docker, Kamal. Each one on this page links to its own page with every episode that mentions it.

How long is "XO Ruby Atlanta 2025 - Overreacting—From React to Hotwire by Igor Aleksandrov"?

The episode runs 28 min; the transcript is about 4,033 words in 28 timestamped sections.

More from Confreaks

• All analyzed episodes
• Books mentioned on Confreaks
• People mentioned on Confreaks
• Topics mentioned on Confreaks