Forem: Renuo AG

Shopify's 2000

Josua Schmid — Fri, 19 Sep 2025 22:05:55 +0000

Since Renuo is a member of the Rails Foundation, @coorasse and me were invited to the speakers dinner at Rails World 2025.

We met people from Shopify and we started discussing. What do they even know about the one-man-agency-Rails we're using in our agency? They have their huge Rails 0.5 originated monolith and are proud of it. Don't they over-optimize for the monolith case? Far-from-agency-reality use cases, right?

What I did not know until that point was that Shopify has 2000 further Rails applications running. They know our agency problems better than you might think.

Small Dev Fascination

Josua Schmid — Fri, 12 Sep 2025 08:12:21 +0000

I host a meetup called Railshöck in Zürich. From time to time someone shows up and holds a presentation from another world. They have small companies with one or two employees and they custom-tailor their Rails workflow to an extent which fascinates me. They own their development stack so completely that it's difficult to understand what they do at all. But it works for them in their own bubble. Without the need to share conventions over a large company.

The latest two examples I want to mention are Christian Seldmair with Svelte on Rails and Sandro Kalbermatter with compony.

Svelte on Rails is the realisation of the fact that you may want to sprinkle some reactiveness into your frontend without having the flicker effect like with Stimulus connects (worked around with the morph-dom and turbo). It's quite an elegant niche solution for a very interesting Rails problem using vite and server side rendering.

And compony is sheer DSL madness made exactly for the brain of Sandro. But because it's so productive for him, he discovered a new software design pattern. It's called the Anchor Model. It solves the problem of singleton database entities (think enum).

The Testing Psyche

Josua Schmid — Tue, 29 Apr 2025 08:15:39 +0000

I'm only seeing dots when my Ruby RSpec test suite is running. But a lot is going on in my brain.

Are the failing tests related in an easy-to-fix way or not?

These are either very easy to fix, because they are close together. It's probably about one conceptual fix. Or the test file can be deleted because the implementation vanished.
I hope, this is related in a predictable way, like that I'm calling the service which is broken or vanished.
Oh-oh is there a case-distinction? I hope the FF correspond to the FF in 1.

Resolution

Factory not registered: "user". Good for me. I know that I deleted it.
Missing partial shared/emails/loyalty/_email_salutation. What now? This seems weirdly unrelated. No idea why this happens.
undefined local variable or method 'user'. Good for me. This is in fact related to 1.

web-console and processes

Josua Schmid — Tue, 15 Apr 2025 08:17:50 +0000

Sometimes I see No exception information available in web-console.

Digging in the web-console source finds me this:

If you happen to run on a multi-process server (like Unicorn or Puma) the process this request hit doesn't store %{id} in memory. Consider turning the number of processes/workers to one (1) or using a different server in development.

So I look at my config/puma.rb, change it and never see this error message again.

Catch JS Errors with Playwright

Josua Schmid — Wed, 26 Mar 2025 11:18:25 +0000

Selenium has issues. I'm using it with Capybara and the latest encounter was a Net::ReadTimeout. I switched to Playwright following Justin Searls guide.

One issue I encountered after the migration was that browser console logs were not accessible anymore with page.driver.browser.logs.get(:browser). We use them to fail tests on JavaScript errors.

One solution is to record them from the Playwright page with an event handler.

config.before(:each, type: :system, js: true) do |example|
  example.metadata[:js_console_messages] ||= []
  Capybara.current_session.driver.with_playwright_page do |page|
    page.on('console', lambda { |msg|
      example.metadata[:js_console_messages] << {
        type: msg.type,
        text: msg.text,
        location: msg.location
      }
    })
  end
end

config.after(:each, type: :system, js: true) do |example|
  if example.metadata[:js_console_messages].present?
    aggregate_failures 'javascript console messages' do
      example.metadata[:js_console_messages].each do |msg|
        if msg[:type] == 'error'
          expect(msg[:text]).to be_nil, "JS Error: #{msg[:text]}"
        elsif msg[:type] == 'warning'
          warn "WARN: JS warning at #{msg[:location]}:\n#{msg[:text]}"
        end
      end
    end
  end
end

The output of a failed test will look like this:

The previous solution to simply look at page.driver.browser.logs.get(:browser) felt more natural to me. I'd be happy to receive a hint on how to catch JS errors in Ruby more nicely.

Exploring Rust: A Rubyist's Perspective

Dani Bengl — Fri, 28 Feb 2025 21:24:18 +0000

At Renuo, we love Ruby. It's simple, elegant, and powerful. But let's be honest, Ruby isn't the fastest language out there.

Over the last couple of months, I've been exploring low-level programming, hoping to bridge the gap between the high-level world of Ruby and the lower-level world of systems programming. To do this, I started working on my first Rust project: a blazingly fast voxel "game" called rsmc. It features a terrain generator, meshing, a scalable client-server architecture, and custom serialized messages for high-speed communication. This project has been my playground for learning Rust, and in this post, I'll share some of the lessons I've learned along the way.

Why Rust?

Rust is one of the most appreciated programming languages, as highlighted in the GitHub Octoverse Survey. It offers memory safety, high performance, and strong tooling, making it a solid choice for both small utilities and large-scale applications. Many of the tools I use daily, like Alacritty and 1Password, benefit from Rust's speed and reliability.

Key Benefits

Performance: Comparable to C and C++, but with safety mechanisms that prevent common errors.
Memory safety: Eliminates null pointer dereferences, segmentation faults, and data races.
Modern syntax: Readable and expressive, making it accessible despite its low-level capabilities.
Powerful tooling: Cargo simplifies dependency management, builds, and testing.

For my voxel game, Rust's speed and safety make it an excellent choice for terrain generation, networking, and real-time interactions. Unlike dynamically typed languages such as Ruby, Rust catches entire categories of bugs at compile time, improving maintainability.

Beyond CLI tools, Rust powers game engines, operating systems, simulations, and even web browsers, proving its adaptability across different domains.

Bevy: Game Development Made Fun

Since my project is built with Bevy, understanding its core concepts was very important. Bevy's entity-component-system (ECS) architecture makes game development modular and efficient, allowing for highly decoupled systems.

Some of my favorite takeaways:

Systems: Keep them small and focused on one task. This way they are easier to test and extend.
Plugins: Encapsulate resources, systems, and components into distinguishable modules.
Events: Use events to the fullest extent to decouple systems and keep code modular.
States: Run systems only when they are relevant (e.g., Menu, Playing). This helps with UI and logic separation. In particular this PR: #32

Bevy makes structuring a game engine intuitive, and its Rust-first approach ensures safety and performance while keeping things flexible. If you're interested in learning more about the ECS approach to game development, I wrote a blog article about planning an ECS: Multiplayer in Rust Using Renet and Bevy.

Feature Flags: Shipping Less in Production

Feature flags allow enabling or disabling specific functionality at compile time, making it easy to toggle features based on configuration.

In my voxel game, feature flags help manage debugging tools like wireframe rendering and debug UI. What's neat about these feature flags is that debug code doesn't get shipped in production, reducing binary size and keeping the release build clean.

In Cargo.toml, you can define feature flags like this:

[features] 
egui_layer = []
terrain_visualizer = ["egui_layer"]
renet_visualizer = ["egui_layer"]`

And then use them in your code:

#[cfg(feature = "egui_layer")] {   
use bevy_inspector_egui::bevy_egui::EguiPlugin;
    app.add_plugins(DefaultPlugins);
    app.add_plugins(EguiPlugin);
}

The downside is that testing all possible feature combinations is a challenge. With just five features, you already have 32 different configurations to check. But that's the price of flexibility.

Cargo Watch: Automating Workflows

During the development of rsmc, I often needed to recompile code, and manually restarting my binary after every change quickly became tedious. I really wish I had discovered cargo-watch earlier.

Just install it and let the watcher do its thing:

cargo watch -x 'run --bin client'

Composition Over Inheritance

Coming from Ruby, where inheritance is common, Rust's approach felt different. Rust doesn't have classes. It uses structs and traits. This forced me to use composition over inheritance and think differently about code structure.

Here's an example from my terrain generator:

pub struct NoiseFunctionParams {
  pub octaves: u32,
  pub height: f64,
  // ... 
}  

pub struct HeightParams {     
  pub noise: NoiseFunctionParams, // Composition!
  pub splines: Vec<Vec2>
}

Instead of inheriting from a base class, HeightParams contains a NoiseFunctionParams struct. This keeps the code flexible and avoids deep inheritance hierarchies.

Macros: Code That Writes Code

Rust's macros are like Ruby's metaprogramming but more structured and powerful. They help eliminate boilerplate while maintaining type safety.

Here's a macro I used to define blocks in my project:

macro_rules! add_block {
    ($block_id:expr, $is_solid:expr) => {
        Block {
            id: $block_id,
            is_solid: $is_solid,
        }
    };
}

pub static BLOCKS: [Block; 14] = [
    add_block!(BlockId::Air, false),
    add_block!(BlockId::Grass, true),
    // ...
];

Macros don't affect runtime performance. They are a zero-cost abstraction, a great feature of Rust.

Rust's Learning Curve: Worth the Effort?

Rust isn't the easiest language to pick up. The borrow checker takes time to understand, and coming from Ruby, its verbosity stands out. Ruby achieves more with fewer symbols. While Rust's explicitness helps with maintainability and reducing hidden behaviors, it also means writing more boilerplate.

One of the biggest disadvantages to me is compile times. They can be frustrating since Rust enforces strict checks, but this reduces runtime errors. There's even an XKCD comic about it.

From my experience, Rust has its trade-offs. Catching many errors at compile time reduces debugging effort, but the strict rules and verbosity make writing new code slower compared to Ruby. That said, Rust's language servers provide excellent refactoring support, which makes working with larger projects easier.

For quick prototyping and iteration, scripting languages such as Ruby are still the better choice. However, when stability, performance, and long-term maintainability matters, Rust seems to be the better pick.

Conclusion

Rust isn't just another language. It changes how you think about programming. It makes you more aware of memory, safety, and performance. The learning curve is steep, but if you stick with it, the rewards are worth it.

I hope you enjoyed this journey into Rust! If you're a Ruby developer who has also tried Rust, what challenges have you faced? I'd love to hear your thoughts!

Multiplayer in Rust using Renet and Bevy

Dani Bengl — Wed, 03 Jul 2024 15:24:33 +0000

Here at Renuo, we specialize in web technologies such as Ruby on Rails, React, Angular, and Spring. One of our core company values is continuous learning: we love exploring new technologies even beyond our usual scope of expertise.

Inspired by Michael’s Unity Powerday, I decided to delve into how multiplayer games operate. As a team, we held a competition to implement FPS (First-Person Shooter) games using C# boilerplate. Initially, the sheer amount of boilerplate required felt overwhelming. Beyond that, I wanted to understand client/server data synchronization at a lower level of abstraction.

My recent experiences with Rust and Bevy convinced me to write this blog article to share my newfound learnings of game development.

Why Choose Rust

Advantages

Rust is a statically typed, memory-safe, multi-paradigm programming language that matches the performance of C. Due to its safety, concurrency features, and modern syntax, it has gained popularity among developers in recent years.

Some notable software written in Rust includes:

Rapier3d: A performant physics engine often used with ThreeJS.
Ripgrep: A performant command line search tool.
Alacritty: A performant, minimalistic cross-platform terminal emulator.
Warp: A performant, modern terminal IDE.
Tauri: A performant and lightweight alternative to ElectronJS.
Amethyst: A performant tiling window manager for MacOS.
Condorium Blockchain: A performant and secure blockchain technology.

I mean, there is no such thing as a perfect programming language Rust is merely a statically type low-level multi-paradigm perfect programming language
YouTube interview by Programmers Are Also Human, Rust is a perfect programming language.

Picking a game engine

There are currently 5 games written in Rust. And 50 game engines.
Interview with a Senior Rust Developer - 2:52

There are too many game engines available for Rust. An excellent resource is Are We Game Yet. I also recommend this article by GeeksforGeeks, which makes picking the optimal engine easier.

The Difference Between Bevy and Other Engines

While big game engines like Godot, Unity, and Unreal Engine come with graphical editors, Bevy focuses on providing a simple yet powerful, multithreaded system to manage game state with minimal code.

Understanding ECS

The ECS (Entity Component System) is a software pattern that emphasizes a modular design. It is commonly utilized in game and game engine development. This approach separates the data and behaviour of game entities into components, making it easier to manage and organize complex systems.

Components of ECS

Entities: Unique identifiers of a group of components (A u32 wrapper in bevy).
Components: Modular data pieces that represent specific Entity attributes. (A struct that derives the Component macro in bevy)
System: Logic that operates on entities and their components. (A struct that derives the Resource macro in bevy)

Systems in Bevy

Systems in Bevy are functions that take various parameters such as queries, EventReaders, assets, and resources and apply logic to them.

One powerful feature of Bevy systems is the Query interface. It allows you to fetch specific data for entities in your project. For instance, if no entity is found, the single_mut() function will raise an error. Multiple queries are possible as long as entities do not overlap.

Below is an example where the MyPlayer component doesn't contain any data but is used to denote that the entity belongs to the client player.

pub fn update_player_movement_system(
    mut keyboard_events: EventReader<KeyboardInput>,
    mut query: Query<(&mut Transform, &MyPlayer)>,
) {
    let (mut transform, _) = query.single_mut();

    for event in keyboard_events.read() {
        let mut delta_position = Vec3::new(0.0, 0.0, 0.0);

        match event.key_code {
            KeyCode::KeyW => delta_position.z += 0.1,
            KeyCode::KeyS => delta_position.z -= 0.1,
            KeyCode::KeyA => delta_position.x -= 0.1,
            KeyCode::KeyD => delta_position.x += 0.1,
            _ => {}
        }

        let new_position = transform.translation + delta_position;
        transform.translation = new_position;
    }
}

The example above has a flaw: the player position update has a fixed step. Instead of using a fixed-step update, consider using the time passed since the last step. This will ensure a consistent movement speed regardless of the frame rate.

Picking Networking Libraries

We need to decide on networking libraries after choosing Bevy as our game engine. Here are a few options:

Matchbox
Naia
Renet
Bootleg_networking
Spicy_networking

I chose Renet because of its popularity and my good experiences with its boilerplate. Additionally, I included Serde for efficient binary message encoding.

Sketching the scene

Before coding, let's sketch a simple scene:

Camera: Renders the scene.
Plane: Represents the floor.
Green Cube: Represents the player.
Red Cubes: Represent other players.

Attributes to synchronize:

Position: Vec3

Input method:

Keyboard (WASD): Used to translate the player.

Handling Player inputs

There are three main ways to handle player inputs:

Client-side: The client handles inputs, moves the player, and sends the position to the server.
Server-side: The client sends input data to the server, and the server responds with the position.
Hybrid: The client handles inputs and shares them with the server, which then responds with position synchronization.

The client-side approach can reduce latency, but is less secure. The server-side approach is more secure but adds server load. The hybrid approach offers a balance, but is more complex.

Planning

Client

Type	Name	Description
Component	PlayerEntity(ClientId)	Represents an enemy player entity.
Component	MyPlayer	Marks the current player entity.
Event	PlayerSpawnEvent(ClientId)	Emitted when a player joins. Adds a player object to the scene.
Event	PlayerDespawnEvent(ClientId)	Emitted when a player leaves. Removes a player object from the scene.
Event	PlayerMoveEvent(ClientId, Vec3)	Emitted by the player controller when a player moves.
Event	LobbySyncEvent(HashMap)	Emitted when the client receives sync messages from the server. Updates other player positions using their ID and position.
System	send_message_system	Shares MyPlayer position data with the server.
System	receive_message_system	Processes messages received from the server.
System	update_player_movement_system	Updates player position from keyboard input.
System	setup_system	Sets up the scene with a camera, a ground plane, and a mesh for the current player.
System	handle_player_spawn_event_system	Adds enemy players to the scene once they join in.
System	handle_lobby_sync_event_system	Updates enemy player positions and potentially spawns missed players into the scene.

Server

Type	Name	Description
Resource	PlayerLobby(HashMap)	Holds attributes of all players currently in the game. Used to synchronize these attributes with the clients.
System	send_message_system	Broadcasts player positions to keep enemy player positions in clients up-to-date.
System	receive_message_system	Updates player lobby position based on messages received from the RenetClient.
System	handle_events_system	Handles events such as ClientConnected and ClientDisconnected from the Bevy Renet plugin.

Deciding on a project structure

I separated the ECS components into specific modules to structure the Bevy project and used two entry points: one for the client and one for the server. Shared code, such as structures for Client-Server communication, can be placed in a global lib module.

src
├── client
│   ├── components.rs
│   ├── events.rs
│   ├── main.rs
│   ├── resources.rs
│   └── systems.rs
├── lib.rs
└── server
    ├── main.rs
    ├── resources.rs
    └── systems.rs

Defining various entry points is as simple as adding this to the Cargo.toml file:

[[bin]]
name = "server"
path = "src/server/main.rs"

[[bin]]
name = "client"
path = "src/client/main.rs"

Afterwards, the binaries can be run with the --bin argument:

cargo run --bin server
cargo run --bin client

Setting up Boilerplate

To integrate bevy_renet into the bevy project, I followed the Bevy Renet documentation. In my setup, I used these two default channels:

Unreliable: Used for sending and receiving messages for player attribute synchronization. (We don't care about every state change, we can pick the last one)
ReliableOrdered: Used for sending and receiving messages for player actions such as joining and leaving.

Synchronising player positions

Here's an example of sending player attributes from the client to the server:

pub fn send_message_system(mut client: ResMut<RenetClient>, query: Query<(&MyPlayer, &Transform)>) {
    let (_, transform) = query.single();
    let player_sync = PlayerAttributes {
        position: transform.translation.into(),
    };
    let message = bincode::serialize(&player_sync).unwrap();
    client.send_message(DefaultChannel::Unreliable, message);
}

Handling messages from the client on the server:

pub fn receive_message_system(mut server: ResMut<RenetServer>, mut player_lobby: ResMut<PlayerLobby>) {
    for client_id in server.clients_id() {
        let message = server.receive_message(client_id, DefaultChannel::Unreliable);
        if let Some(message) = message {
            let player: PlayerAttributes = bincode::deserialize(&message).unwrap();
            player_lobby.0.insert(client_id, player);
        }
    }
}

Sending attributes of all players back to the client:

pub fn send_message_system(mut server: ResMut<RenetServer>, player_lobby: Res<PlayerLobby>) {
    let chanel = DefaultChannel::Unreliable;
    let lobby = player_lobby.0.clone();
    let event = multiplayer_demo::ServerMessage::LobbySync(lobby);
    let message = bincode::serialize(&event).unwrap();
    print_lobby(&player_lobby);
    server.broadcast_message(chanel, message);
}

Synchronizing the client scene with the player attributes from the server:

pub fn handle_lobby_sync_event_system(
    mut spawn_events: EventWriter<PlayerSpawnEvent>,
    mut sync_events: EventReader<LobbySyncEvent>,
    mut query: Query<(&PlayerEntity, &mut Transform)>,
    my_clinet_id: Res<MyClientId>,
) {
    let event_option = sync_events.read().last();
    if event_option.is_none() {
        return;
    }
    let event = event_option.unwrap();

    for (client_id, player_sync) in event.0.iter() {
        if *client_id == my_clinet_id.0 {
            continue;
        }

        let mut found = false;
        for (player_entity, mut transform) in query.iter_mut() {
            if *client_id == player_entity.0 {
                let new_position = player_sync.position;
                transform.translation = new_position.into();
                found = true;
            }
        }

        if !found {
            info!("Spawning player {}: {:?}", client_id, player_sync.position);
            spawn_events.send(PlayerSpawnEvent(*client_id));
        }
    }
}

Conclusion

The multiplayer demo project demonstrates the intricate planning and attention to detail needed to synchronize player attributes between the client and server. This showcases the complexity of creating a seamless multiplayer experience at a lower level.

For more detailed code, visit the MIT-Licensed GitHub repository.

2 Simple Configurations to Supercharge your TMUX Setup!

Dani Bengl — Sun, 14 Apr 2024 11:22:48 +0000

Tmux is a terminal multiplexer. It is a tool for managing multiple shells inside a single terminal window. It is integrated into most modern terminal emulators like Iterm2 or Warp. In this blog article, I will show you two simple configurations that drastically improved my tmux experience.

Autoresizing panes

The main problem I had with tmux when starting out was that panes were not automatically resized as I was used from Warp:

Don't get confused by the remapped tmux prefix. The main thing to notice here is that I am using <PREFIX> + E to spread the panes out evenly.

What we now need is:

The command to resize the windows
The hook(s) for executing the command
Update the tmux configuration with the hook and the command.

Part1: Finding the command

According to the manual entry for tmux:

select-layout [-Enop] [-t target-pane] [layout-name]
                             (alias: selectl)
                 Choose a specific layout for a window.  If layout-name is not given, the last preset layout used (if any) is
                 reapplied.  -n and -p are equivalent to the next-layout and previous-layout commands.  -o applies the last
                 set layout if possible (undoes the most recent layout change).  -E spreads the current pane and any panes
                 next to it out evenly.

We can use the select-layout -E command to spread the panes evenly.

Part2: Finding the hooks

The first part is done. Now we need the hooks.

Unsurprisingly, this can also be found in the manual entry:

%window-pane-changed window-id pane-id
     The active pane in the window with ID window-id changed to the pane with ID pane-id.

...

window-resized          Run when a window is resized.  This may be after the client-resized hook is run.

Part3: Updating the configuration file

If you haven't moved the .tmux.conf to .config, you can find the default configuration file for MacOS at ~/.tmux.conf.

To execute the command on the resize and pane changed hooks, we can add these lines to the tmux configuration:

# .tmux.conf
...
set-hook -g window-pane-changed 'select-layout -E'
set-hook -g client-resized 'select-layout -E'
...

This is how the panes behave after adjusting the configuration:

According to the manual entry, we can also shorten the command to the following:

set-hook -g window-pane-changed 'selectl -E'
set-hook -g client-resized 'selectl -E'

Dimming Inactive Panes

Next to automatically resizing windows, we can also automatically dim panes that aren't active by using the following configuration:

set-hook -g pane-focus-out 'select-pane -P bg=colour233,fg=colour10'
set-hook -g pane-focus-in 'select-pane -P bg=default,fg=default'

Now, this is a much nicer alternative than the active border color. If you are wondering how I got rid of it, I used this configuration:

set -g pane-active-border-style "bg=#000000,fg=white"
set -g pane-border-style "bg=#000000,fg=white"

Remember that black and #000000 are not the same thing when configuring your terminal, as the color names are defined by your color scheme.

Conclusion

While tmux isn't as usable/powerful out of the box as the integrated tmux in Iterm or Warp, with some simple configuration, it can be significantly improved. The manual page for tmux is the go to source for looking up commands and events and will save a lot of time googling.

Tools and Sources

Screen recorder: CleanShotX
Keystroke recorder: KeyCastr
Terminal Emulator: Alacritty
Other configuration: My Dotfiles

Much Compliance and Config

Josua Schmid — Thu, 21 Mar 2024 10:05:54 +0000

Dear developers

Please refrain from creating GitHub repositories like this one:

The main thing you want to show me is your code. What you need is the following:

README.md
LICENSE.md (maybe, mention it in README.md)
main.js
package.json, package-lock.json
.env.sample (maybe)

These are 6 files. I don't want to juggle 16 files in my brain to find what I'm looking for in the repo root directory. Please use folders to hide what one doesn't need to see at a first glance.

If you want another example of how all this configuration madness spoils my greppability of code bases, have a look at what JavaScript did to Rails in my May of WTF post.

Extending Hotwire beyond Ruby on Rails

Dani Bengl — Fri, 08 Mar 2024 19:30:00 +0000

This blog article is inspired by a Hotwire Turbo streams tutorial for Sinatra.

When you search for Hotwire tutorials on Google, you’ll find that most of the results are related to Ruby on Rails. Even the Hotwire guides predominantly use Ruby on Rails as an example for implementing Turbo Streams.

This does not really come as a surprise, as the framework has been created by the same company behind the Ruby on Rails framework.

However, it’s important to recognize that Hotwire is not exclusively a Rails framework. In this blog article, I aim to convince you that Hotwire can be used beyond the Rails context, especially Turbo, its core feature.

Goals

In this blog article, I will explain:

Setting up a BunJS Application
Implementing client and server-side Web Sockets
Using turbo streams to update the UI
Creating a stimulus controller attached to the DOM

Step 1: Set up a BunJS Application

Initially, I considered using Java Spring for this blog, but I encountered challenges with Web Sockets. Instead, I opted for a much simpler TypeScript application.

Let’s start by initializing a new BunJS application:

mkdir bunjs-turbo-demo
cd bunjs-turbo-demo
bun init

Now, let’s run the application:

bun run index.ts
Hello via Bun!

Step 2: Implement a Simple Web Socket / HTTP Server with BunJS

Web Sockets serve as the backbone for real-time communication in our project. In this step, we’ll create a basic Web socket HTTP server using Bun. Web Sockets are essential for enabling bidirectional communication between clients (such as web browsers) and the server.

The Multiple Publisher - Multiple Subscriber Pattern

Our approach involves implementing the multiple publisher - multiple subscriber pattern. Here’s how it works:

Client Interaction:
- Clients (users' web browsers) initiate actions, such as sending chat messages or requesting updates.
- These interactions trigger Web Socket connections to the server.
Server Processing:
- The server receives messages from multiple clients.
- It processes these messages and prepares appropriate responses.
Broadcasting Updates:
- When a client sends a message (e.g., a new chat message), the server broadcasts it to all connected clients.
- This ensures that everyone receives the latest updates in real time.
Seamless Communication:
- Web Sockets allow seamless, low-latency communication.
- Clients can instantly receive updates without the need for manual page refreshes.

Here is a simple sequence diagram showing the core idea of this project:

Implement the server

For brevity, I’ve omitted the code for view helpers such as layoutHTML and chatRoomHTML. These helpers handle rendering HTML components and chat room layouts. While important, their details won’t significantly impact the core concepts discussed in this blog.

const topic = "chatroom";

Bun.serve({
  port: 8080,
  fetch(req, server) {
    const url = new URL(req.url)

    if (url.pathname === "/") return new Response(layoutHTML("Chatroom", chatRoomHTML()), {
      headers: {
        "Content-Type": "text/html",
      }
    })

    if (url.pathname === "/subscribe") {
        if (server.upgrade(req)) { return }
        return new Response("Couldn't upgrade to a WebSocket connection")
    }

    return new Response("404!");
  },
  websocket: {
    open(ws) {
      console.log("Websocket opened")
      ws.subscribe(topic)
      ws.publishText(topic, messageHTML("Someone joined the chat"))
    },
    message(ws, message) {
      console.log("Websocket received: ", message)
      ws.publishText(topic, messageHTML(`Anonymous: ${message}`))
    },
    close(ws) {
      console.log("Websocket closed")
      ws.publishText(topic, messageHTML("Someone left the chat"))
    },
    publishToSelf: true
  }
})

Implement the client

The application is incomplete without the client, which connects to the Web Socket server. Following the Web Socket server connection documentation, connecting to the backend is straightforward:

const client = new WebSocket("ws://localhost:8080/subscribe")
const form = document.getElementById("chat-form")
const chatFeed = document.getElementById("chat-feed")

client.addEventListener("message", (event) => {
  chatFeed.innerHTML += event.data
})

form.addEventListener("submit", (event) => {
  event.preventDefault()
  const formData = new FormData(form)
  const message = formData.get("message")
  client.send(message)
  form.reset()
})

Don't forget to add the route for the JavaScript file to the backend and include it inside your view using a module script tag. Also, make sure to implement the backend response.

The problem

As you can see here, every change in UI needs to be manually implemented. At the moment, we are listening to a single event and updating one single element. When the application grows in complexity, the JavaScript code grows, too. What if I told you that we can "almost" completely eliminate the client code by introducing Turbo streams?

Step 3: Implement Turbo streams

Turbo is a vital part of the Hotwire Framework. It enables you to dramatically reduce the amount of custom JavaScript you need to write.

The most relevant feature for this application are the turbo streams. They enable us to deliver page changes in the form of HTML over the wire.

Importing Turbo is as simple as including this snippet of code inside our layout file:

<script type="module">
    import hotwiredTurbo from 'https://cdn.jsdelivr.net/npm/@hotwired/turbo@8.0.3/+esm'
</script>

In order to use Web Sockets for Turbo streams in the frontend, we can use the following snippet from the stream documentation:

<turbo-stream-source src="ws://localhost:8080/subscribe" />

In order to update the UI when a message is sent, we broadcast the following HTML through Web Sockets:

<turbo-stream action="append" target="chat-feed">
    <template>
        <p class="notice">
           Anonymous: Hello World!
        </p>
    </template>
</turbo-stream>

This method of HTML updates stands out for its transparency and simplicity. Firstly, we select an element with the #chat-feed selector and then append to it the contents of the broadcasted template. In this case, a paragraph containing the user message. This also eliminates almost all the client-side JavaScript needed for page update.

Step 4: Implement Form Controller

Before introducing turbo, we added a simple event listener to reset the Form after the data has been sent to the server. We now need to bring the functionality back, but without reusing the old code. We could use a turbo-stream to reset the form or even a turbo-frame, but rather than using that, I decided to use another library of the Hotwire framework, namely Stimulus:

Stimulus is a JavaScript framework with modest ambitions. It doesn’t seek to take over your entire front-end—in fact, it’s not concerned with rendering HTML at all. Instead, it’s designed to augment your HTML with just enough behavior to make it shine.

https://stimulus.hotwired.dev/

This is a simple code snippet for the Form Stimulus controller:

import { Application, Controller } from "https://cdn.jsdelivr.net/npm/stimulus@3.2.2/+esm"

class FormController extends Controller {
  clear() {
    this.element.reset()
  }
}

const application = Application.start();
application.register("form", FormController);

This is what the form HTML looks like, with data attributes used to attach the controller to the DOM and hook the events up to the corresponding controller methods:

  <form id="chat-form" action="/submit" method="post" data-controller="form" data-action="turbo:submit-end->form#clear">
    <label for="message-input">Message:</label>
    <input name="message" data-form-target="input" required >
    <input type="hidden" name="clientId" value="${clientId}">
    <input type="submit" value="Send">
  </form>

The event that works best for form submission in that case is turbo:submit-end. Following the documentation of Stimulus descriptors, we can call the #clear() method after the form submission event. We are not using the submit event because this would clear the form prematurely.

Conclusion

Hotwire is a JavaScript framework that helps us make applications more interactive while keeping the JavaScript code to a minimum. While the framework has been created by the authors of Ruby on Rails, the framework itself is backend agnostic.
Turbo streams enable us to update client user interfaces asynchronously without the need for any (in some cases, just very little) frontend code.
Stimulus enables us to add simple JavaScript behavior to our HTML with the use of Stimulus Controllers and data-attributes.

Where can I find the source?

You can find the complete chatting application with additional features such as:

Client identification via Query Parameters
Random username generation
Real-time user list

The GitHub Repository for this project can be found here: https://github.com/CuddlyBunion341/bunjs-turbo-demo

standardrb, but more

Josua Schmid — Thu, 08 Feb 2024 18:46:49 +0000

Often project teams suffer from either too many or too strict Rubocop rules (NewCops) or from outdated ones because they locked the rules or Rubocop versions. standardrb provides a good middle ground for people who care but also don't care fanatically. Its default settings are optimized for long-term maintainability and no-bikeshed. But we at Renuo are still missing a lot of rules, especially from Rubocop plugins like RSpec or performance cops. Since standardrb relies on Rubocop under the hood, there's an easy way for you to use a default but extended configuration. Simply opt-in to the rules you want while relying on standardrb for the rest. This inverts the team discussion time needed for your style guide from discussing every rule to discussing opt-in-exceptions.

If you want to have a look at our approach: we created a gem called renuocop. Our config file documents what we think is not strict enough in standardrb.

The Full-Stack development experience

Alessandro Rodi — Thu, 12 Oct 2023 12:48:13 +0000

Rails World 2023 closes many doors that have been opened recently and marks a turning point for Ruby On Rails. That is why this year's motto can be summarized as "The One Person Framework".

The Web has certainly been a complex environment in recent years. This complexity was necessary to push browsers to the limit and use the most advanced features.

But in 2023, this is no longer necessary!

Assets distribution

Let's think about CSS. For years, we used SASS to take advantage of variables and nested rules. Well, that is no longer necessary. These are both features made available directly by CSS now.

So we can say goodbye to compiling SASS into CSS and enjoy the pleasure of writing directly in CSS. This makes us much faster in development and requires one less knowledge (SASS) for each Full-stack developer.

A full-Stack developer is precisely what our profession provided for before the advent of powerful javascript frameworks for creating truly fluid web interfaces! However, it is time to simplify! It is time to stop being Partial-stack developers and focus on productivity again.

Let's talk about JavaScript. The language has matured so much in the last few years, and it is (almost) a joy to write in JavaScript. The consolidation of import maps for the distribution of JavaScript and CSS assets finally allows us to remove another element from our stack: bundling.

In 2023, thanks to importmaps, providing the browser with dozens of separate JavaScript files instead of a single file makes no difference! No more bundling! It is not only unnecessary but even harmful! If we modify just one of our files, we can serve the browser a new version of that one file instead of the entire bundle. Long live simplicity!

An additional element that we can finally remove from our stack is the minification of JavaScript and CSS files. Thanks to algorithms like brotli (with a very Swiss flavour) we no longer need to minify and compress our files before distributing them. Cloudflare, Nginx, or Apache will take care of everything for us.

And there goes our stack thinning, and with that, our Full-stack developers can focus again on productivity instead of technicalities about how to distribute their work to Browsers.

Ruby On Rails, thanks to propshaft, closes a chapter. Welcome to 2023, where deploying JavaScript and CSS is a breeze. Welcome to the no-build era.

Hard drives are cool

Another element that has radically changed in recent years is the speed of drives. With the advent of NVMe disks, the speed is ten times what we had ten years ago. That is why our stack can be further streamlined. To start with a new web application, we can use the disk for databases (SQLite), caches, WebSockets, and background jobs.

Great! It means you can have a web app with all the latest and most complex features...and zero dependencies.

When your application is used by millions of users worldwide, you can think about further optimizations, a better-performing database, or gain performance with more efficient caching systems. Until then, productivity is the key word. No frills and no dependencies. You can eliminate SQL and NoSQL databases from your stack and focus on development.

HTML-First architecture

Let's get to the last chapter. The most controversial one, the one most discussed. The Hotwire architecture: HTML Over The Wire. Ruby On Rails started down this path in 2015 with Turbolinks, but it was not until 2021, with the arrival of Turbo, that years of work was consolidated.

Today, we can confidently say that HTML Over The Wire is the right technology for maximizing productivity. When we maximize productivity, this is always at the expense of performance. With this technology, we will never have the performance of a JavaScript-First architecture. But what is it all about?

When discussing JavaScript-First Architecture, I have in mind applications where the backend and frontend, properly separated, communicate via JSON. The frontend uses JavaScript, and the backend also, possibly. The server and client communicate via JSON. The server is "dumb", it provides data to the client, which, thanks to the Frontend Framework from screaming, "builds" the entire web interface.

The client then has the entire responsibility of building web pages.

A truly efficient architecture that takes full advantage of all the capacity of modern devices, which have no difficulty in taking on the "onerous task." An architecture that maximizes performance...at the expense of productivity, of course. Not coincidentally, the first frameworks in this universe, Angular and React, were deployed by Google and Facebook, which have their main focus on performance. And we could do with more!

GitHub itself, which is based on Ruby On Rails, now adopts React in many parts of their frontend to be able to offer the best experience to its customers.

When I discuss HTML-First Architecture, however, I have in mind the Web of twenty years ago. The server, "intelligent", no longer solely transmits data to clients but directly HTML pages.

The client/server communication protocol is based on HTML, and the client goes back to being "stupid."

What changes today is that the client and server can communicate via HTML but update individual page elements instead of simply navigating to the next one.

This concept of partial updates allows us to rethink very complex pages into smaller elements (just as React taught us!) and update only the parts we care about.

The implementation offered by Ruby On Rails is called Turbo, and it allows for SPA-like user interfaces and experiences without having to learn a new framework.

Your browser does not support the video tag.

This element allows a Full-Stack developer to build applications with a modern flavour within a majestic monolith, while continuing to work only with HTML at all times. No more client/server separation and complex synchronization to achieve modern, fluid interfaces. Just one application, the stack of which can fit entirely in one person's head.

When they tell you about Multiple Page Apps vs. Single Page Apps, you will know this comparison no longer makes sense. There are JavaScript-First Frameworks that can safely create MPA's via Server-side rendering, and there are HTML-First Frameworks which can provide the same experience as an SPA.

HTML-First vs Javacript-First architecture is the distinction that needs to be made today.

App Store, Android Store

Having come to this point, to think that one person can manage the entire stack for Web application development is not only likely, it is reality! One person can develop a feature from start to finish: from database design, background processes, business logic, to frontend design. The Web stack was complex, but we finally simplified it!

Yes, a Full-Stack developer in 2023 has the tools to build a feature from start to finish, without waiting for his colleague to "expose" the API.

But there is a world that has always been quite obscure to us web developers: native iOS and Android app development. Native apps do not allow us all the simplifications we discussed above. Native app development follows other rules, and here I throw up my hands and give up.

But Ruby On Rails, since a couple of weeks ago, has released the missing piece of the stack for creating hybrid applications: Strada.

Thanks to Turbo and Strada, even our Full-Stack developer can make something that will be approved within the App Store. A hybrid app allows you to start from your existing Web application and release it as a native App once it is properly "wrapped" in a WebView. Turbo-ios and turbo-android, together with Strada, make it very easy to add all the native elements needed to optimize the user experience.

To date, dozens of apps are already made with this technology in the App Store, and I challenge anyone to distinguish them from a native app. Web View indeed means Browser, and Browsers are really powerful today! With good design and good animations, they are indistinguishable from fully native apps. And the beauty is that it is still your Web app. You don't need to expose APIs, and rebuild your iOS and Android interfaces. Just reuse your existing ones! This is an incredible boost to productivity!

What's next?

At the beginning of the article, I wrote that this is a turning point, but what's next? The next few years will be focused on this simplification of the stack and on improving these new tools at our disposal. Improving productivity is also done through developer tools. We need time to improve the whole ecosystem around these technologies. There are many new things, and it takes time to absorb and digest them.

Ruby On Rails continues to point the way, often independently and controversially, and we, after our recent membership in the Rails Foundation, are intent on following it.

Check the Keynote of Rails World 2023, to hear from the creator of Ruby On Rails, the concepts I took inspiration from, to write this blog post.