Reactive Rails From Bare Bones.

reactive rails from bare bones

Reactive Rails: Bare Bones Chat

Introduction

This is the second article in a five-part series on Reactive Rails. In the first post we wrote a brief primer noting the history that brought us to these notions of Reactive Rails. In this post, we’ll build the barest of applications–a base from which we can explore two rails tools with reactive features: StimulusReflex and the recently-released Hotwire.

All of the posts in this series are listed here:

Motivations

The ever-changing landscape of software development rewards personalities that love to learn new things. This has an obvious drawback: the desire to use that new thing as soon as it appears, even if it’s not fully baked. Whether or not to implement a solution using the new and shiny is an exercise in judgement (and restraint). We have to evaluate each new technology in a few ways:

cost to implement
functional range
support and adoption
stability of core assumptions
security
introduced uncertainty
effect on development speed
happiness

These are some of the factors in our minds as we evaluated these two technologies. Staying on top of the state of the art is a worthwhile endeavor. Actually using the state of the art means asking difficult questions. A decision to make use of new things should only come after these questions have satisfactory answers.

A decent way to evaluate is through experimentation.

Getting Started

We have two goals in mind: first, to find a solution that provides the functionality we need from a single page app without the associated overhead. Second, we want to add tools to our belt making this kind of activity easier in future projects.

Our specific application needs an interactive communication channel between users, with advanced chat and file/photo sharing capabilities encapsulated into a single view. Think of an advanced group text and you’ve got the idea. Required features for our prototype:

1) Any user must be able to easily differentiate their own messages in the view 2) Any user must be able to edit only their own messages 3) Every user sees updates in real time

This is a small subset of features we felt would enable us to compare and contrast the pros and cons of Hotwire and StimulusReflex in relative isolation. We kept the problem domain small enough that we wouldn’t lose focus, but complex enough to ensure we pushed some of the edges of these tools.

Hotwire and StimulusReflex appear to be roughly aligned philosophically and rely on similar underlying tools (Rails, ActionCable, and Stimulus), and so we can approach an apples to apples comparison between these two.

The Bare Bones

To form a foundation for both experiments, we built a lean, vanilla Rails application, intending to implement StimulusReflex and Hotwire solutions in separate branches. You can check out the base code for chatty here. We built it using Rails 6.1 and Ruby 2.7.2.

For models, we limited ourselves to three: User, Room, and Message. We’ve left out real authentication, and simply track the current user using a user_id in the session. Because we appreciate some style, we also incorporated Tailwind CSS. We opted for Webpacker over Sprockets and the asset pipeline. Setup will seed a single room in the database for everyone to share.

The result? A basic chatroom experience:

screen capture of a simple chatroom

Of course, this bare app requires a full page refresh when submitting new content, and doesn’t update other users’ views.

Next Up

At this point, we have a blank canvas from which to integrate both solutions and see where we are. The next two posts will explore StimulusReflex and Hotwire individually. Finally, we’ll compare, contrast, and summarize our thoughts.

Next: StimulusReflex

All of the posts in this series are listed here: