Forem: R.J. Robinson

[Boost]

R.J. Robinson — Fri, 18 Jul 2025 16:40:29 +0000

R.J. Robinson

Jul 18 '25

🚀 Build LLM Agents in Ruby with FlowNodes — a LangChain Alternative

#webdev #ruby #rails #llm

Comments

2 min read

🚀 Build LLM Agents in Ruby with FlowNodes — a LangChain Alternative

R.J. Robinson — Fri, 18 Jul 2025 16:40:21 +0000

Finally, Rubyists get a clean way to build LLM workflows without swimming in TypeScript or bloated Python frameworks.

This was inspired by PocketFlow — a ~100-line Python framework that blew me away with its simplicity.
I loved the graph-based pattern so much, I built FlowNodes to bring that same power to Ruby. Now I use it in my own projects, and it just works.

⸻

💡 What is FlowNodes?

FlowNodes is a minimalist Ruby framework for building LLM-powered applications using a graph-based flow architecture — inspired by PocketFlow, rebuilt for the Rails ecosystem.

Think of it as:

🧠 Agents without chaos
🧩 Workflows without brittle prompt-chaining
🪄 RAG pipelines without rolling your own spaghetti logic

All while staying in Ruby. No extra services. No lang-* wrappers.
You can even integrate it with RubyLLM, which supercharges its capabilities.

⸻

🧱 Why I Built This

I wanted something that:

Didn’t require Python glue code
Didn’t assume I wanted 14 layers of abstraction
Let me define clear flows: “User input → Tool → Decision → Output”
Could run inside my existing Rails stack — not in some weird sidecar

FlowNodes does exactly that. It’s a Ruby-first approach to orchestrating LLM workflows.

Fun fact: I once rewrote the core in ~88 lines using metaprogramming… but debugging it was hell. Readability wins.

⸻

🧪 How It Works (TL;DR)

Define your flow with simple Ruby classes:

class GreetingNode < FlowNodes::Node
  def exec(params)
    puts "Hello, #{params[:name]}!"
    "greeted"
  end
end

class FarewellNode < FlowNodes::Node
  def exec(params)
    puts "Goodbye, #{params[:name]}!"
    nil # End the flow
  end
end

greeting = GreetingNode.new
farewell = FarewellNode.new

# Connect nodes: greeting -> farewell
greeting - :greeted >> farewell

flow = FlowNodes::Flow.new(start: greeting)
flow.set_params(name: "World")
flow.run(nil)

You’re literally just connecting logic like a graph. It’s simple, explicit, and debuggable.

⸻

🧰 Features You’ll Actually Use

Graph-based node chaining (not magic, just clean)
Async & parallel batch support
Built-in retry and fallback logic
Validated parameters
Lifecycle hooks (prep, exec, post)
Thread-safe and production-ready

The core gem is under 500 lines — you can grok the whole thing in an afternoon.
Performance metrics, observability, and memory stores are coming — but the philosophy stays lean and fast.

⸻

⚙️ Real Use Cases

Toolchain-based LLM agents
Context-aware email/report generators
Batch RAG queries across PDFs or embeddings
Multi-step AI flows inside your Rails apps

You don’t need LangChain. You don’t need Python. You just need Ruby.

⸻

🛠 Ready to Try?

gem install flow_nodes

Or add it to your Gemfile:

gem 'flow_nodes', '~> 0.1.0'

Tutorial (built with AI):
📚 https://code2tutorial.com/tutorial/927c15a8-5bba-45d8-a999-6ee873562c5a/index.md

⸻

🗺 What’s Next

Coming soon:

Flow visualizations
Built-in memory stores
Native Rails generator support
Community-driven use case templates

⸻

👋 Feedback Wanted

If you’re a Ruby dev curious about LLMs but tired of fighting Python wrappers, try FlowNodes.
Let me know how you’d use it — or what’s missing to make it battle-tested.

Testing GraphQL-Ruby Mutations With RSpec

R.J. Robinson — Fri, 19 Jul 2019 15:09:41 +0000

xpost from medium - love Dev.to so much, wanted to share here as well.

To start with, a little OpEd on how much I love working with GraphQL. I started tinkering with it about a year ago, and have since completed a project at work where we did a rewrite, the results have been amazing. Pros and cons aside however, I needed a way to test.
This might not be the best solution for you, but this is what had worked on my team, and for our use case.

The tests needed to cover a few aspects. Did the user have access? We use our own Pundit hack. Were the proper arguments sent? And did the response come back as expected? This sounds like a basic controller test, so from there I treated it as such.

Usually, in an RSpec controller test, we have a #get or a #post method that allows us to interact with that endpoint, and I wanted to continue with that pattern. These usually return a #response object with everything we would want to test.

module GraphQL::TestHelpers

  attr_accessor :gql_response

  # The returned results of a GraphQL query
  # @return [data] this is the bulk of the return to test.
  # @return [error] any time a query, mutation, subscription throws and error
  class GQLResponse
    attr_reader :data, :errors

    def initialize(args)
      @data = args['data'] || nil
      @errors = args['errors'] || nil
    end
  end

  # basic query to interact with the GraphQL API.
  # @param [query] required The query string that would be passed to the schema.
  def query(query, variables: {}, context: {})

    converted = variables.deep_transform_keys! {|key| key.to_s.camelize(:lower)} || {}

    res = MyRailsAppSchema.execute(query, variables: converted, context: context, operation_name: nil)
    @gql_response = GQLResponse.new(res.to_h)
  end

  alias_method :mutation, :query
end

Once I defined the #query and #mutation methods, passing in the arguments were easy.

mutation createBook($bookInput: BookInputType!){
  createBook(bookInput: $bookInput) {
    book {
      title
      author
      pages
    }
  }
}

#Arguments== 

{
  bookInputType: {
    title: "Testing GraphQL-Ruby Mutations With RSpec",
    author: "me", 
    pages: 1

  }
}

Say we have a simple book application, and we want to create a new book.
Below are the tests, and while this seems very basic, I hope it's clear enough to understand the ideas behind it.

require 'rails_helper'
require_relative '../test_helpers'
include GraphQL::TestHelpers

describe 'CreateBook', type: :mutation do
  describe 'Creating a Book' do

    let(:user) {build_stubbed(:user)}
    let(:mutation_type) {"createBook"}
    let(:mutation_string) {<<- GQL
      mutation createBook($bookInput: BookInputType!){
       createBook(bookInput: $bookInput) {
          book {
            title
            author
            pages
          }
        }
      }
    GQL
    }

    context 'when a user has all the required permissions and parameters' do

      before do
        mutation mutation_string,
                 variables: {
                    bookInputType: {
                      title: "Testing GraphQL-Ruby Mutations With RSpec",
                      author: "me", 
                      pages: 1
                    }
                  }
                 },
                 context: {current_user: user}
      end

      it 'should return no errors' do
        expect(gql_response.errors).to be_nil
      end

      it 'should return the book object' do
        expect(gql_response.data[mutation_type]["book"]).to include("title" => "Testing GraphQL-Ruby Mutations With RSpec")
      end
    end

    context 'when a user has not passed required parameters parameters' do

      before do
        mutation mutation_string,
                 variables: {
                    bookInputType: {
                      title: "Testing GraphQL-Ruby Mutations With RSpec",
                    }
                  }
                 },
                 context: {current_user: user}
      end

      it 'should return errors' do
        expect(gql_response.errors).to be_truthy
      end

    end
  end
end

Why did I decide to do it this way? A few reasons. One, I wanted to treat the mutation like any other post request. Data goes in, data comes out. I see a lot of tests trying to do some crazy things just to hit the resolver inside their mutation. I don't really think that's needed. Using the existing interface with the GraphQL Schema should test what you need to. Hope this helps, and I how you provide some feedback. I would love to see how everyone else tests.

I can be found on twitter. :) @rjrobinson

How Intermittent Fasting Improved My Productivity and Other Helpful Tips

R.J. Robinson — Tue, 28 May 2019 20:07:26 +0000

I became a developer a few years ago. I would say around 2014/15 is when I really went for it and signed up for a coding boot camp. I was in pretty good shape. I would work out frequently, and I could easily squat 225, and run a few miles without stopping. My clothes fit fine, and I didn't feel bad about taking off my shirt. Then of course... I started sit/standing in front of a computer for 8-10 hours a day. Fast forward past the long days of being a junior developer, and way past my divorce, and I had gained almost 45 pounds ( and not the good gain ) while almost doubling my body fat percentage.

I was depressed. It was not a fun time in my life. Then the depression started to affect my work, and it was a wake-up call. I had already gone through a lot and I couldn't lose my job on top of it. Luckily for me, I caught that issue early. So, I did what any normal warm-blooded American would do and I started new diets. Several of them. Keto, Atkins, meal prepping. But... it was the cheating on my diet that affected me. Diets were not working. But due to the long term meal prepping ( almost 18 months ), I knew how to measure calories quickly; That was the real trick.

I have been a productivity fiend for a few months. I didn't want to get bogged down with being unproductive. That was only adding to my depression. I felt good when I accomplished tasks. It was like a little dopamine was released, so I wanted to be able to maximize that feeling, so productivity became the goal. How can I do more work, with less time?

It all came down to thinking about what had to be done. I read a book called Get $hiT Done (GTS), and the main point of that process was to write things down so that you didn't have to think about them all the time. I didn't realize how much I just forgot to do things. Writing things down on paper ( or iPad in my case) got me programmed to doing so, and then I could just cross something off the list. Boom. Dopamine! All the feels.

So how could I apply this to my diet? Well, as I mentioned earlier, I had been meal prepping to control how many calories I should take in. The what was answered. What never dawned on me was the when. I had heard about IF (Intermittent Fasting) from some friends, and I thought... that's 2 fewer things to think about for the day. I'm sold. IF, for the everyday reader, is basically a feeding window. You pick a block of time where you can eat, and then you fast for the remainder of the day. Say for instance that you fast between sundown and sunrise, that is called a 13hour fast. One you should start with. The health benefits of IF are seen throughout all of history which is why I suppose that a lot of religions participate in it.

Over the past few months, I have migrated to an 18 hour fast. I only eat between 1 pm and 7 pm, sleep for 8hours, have black coffee in the morning, and I lost almost 22 pounds the first month. I slept better. I was clearer in my mind. I was grumpy AF around 12. But I got more work done. I got more everything done. Because of meal prep, and IF I had time to go to the gym more. Work on side projects. Long walks with my dog.

As developers, we think about a lot of things. Another fun thing that we do is automate it. Automate your calorie intake. Stop fighting with people which food truck you should go to. IF helped me. hope it helps you.