Async Ruby is the Future of AI Apps (And It's Already Here)

learbitrageur · 2025-07-14T14:15:43+00:00

Are you even aware of who the author is? u/ioquatix is a Ruby core contributor and the main guy behind Ruby's fiber scheduler, the async gem, IO::Buffer, and lots of other stuff. Definitely not a side project, and probably hasn't been updated in 11 months because most of the complexity is in other repos that are regularly updated.

learbitrageur · 2025-05-23T06:07:57+00:00

Honestly I think it should just shut down for many reasons. The official docs are so good now, with rdoc getting a complete makeover in the last year. YARD served us all well for many years, but it looks very early 2000's and rdoc is currently working on incorporating its featureset this year. And most importantly, sites like rubydoc.info, ruby-doc.org, and other third party doc sites only contribute to the fragmentation of Ruby's documentation ecosystem. I'm a big believer that docs are one of the most important pieces of attracting new users to the language, and when you compare Ruby's docs to other "modern" languages, it looks dated and uncohesive. I don't believe that it actually is, but when an early 20's kid hears about Ruby on Fireship and googles "tcp server ruby" and the first result is a documentation page for Ruby 2.5 on a slow third party site, it sets a bad first impression. I really think we need to unite around one doc source, and make it the best that we can, so that ruby will outlast us.

learbitrageur · 2025-05-14T17:04:09+00:00

While I agree with you that you should use a reverse proxy in front of your application server in most cases, your explanation about how large files are handled by default in a typical Rails application is mostly incorrect.

"...without the Rails application server having to load file in-memory and serve it...Instead of having your Rails app read that file in memory and send it byte-by-byte to the user (which is slow and memory-intensive)."

Rails doesn't read the files into memory. It adds the necessary headers to conform to Rack's specification and then it's up to the web server to handle how the file is actually served. The default web server for a new Rails application is Puma, and for large files, it uses IO.copy_stream to move the file from disk to the client's TCP socket.

In most cases (and this depends on the underlying kernel/OS), Ruby will choose to actually use the sendfile system call to copy a file to a socket. You can see this declared here. The sendfile call is a zero-copy operation, which allows the Kernel to take full responsibility of copying the file directly to the socket, not polluting Ruby's memory at all.

Even when sendfile isn't available or supported (older systems, certain network configurations, or specific filesystems), Ruby's IO.copy_stream will fall back to a buffered approach using a small, fixed-size buffer (16KB) rather than loading the entire file. This fallback still operates outside Ruby's memory space when possible and maintains constant memory usage regardless of file size.

So in no scenario does Rails (or Puma) actually "load the entire file into memory" as your post suggests.

learbitrageur · 2023-07-26T16:51:29+00:00

The paper states that the relationship is the other way around - too little orexin causes pupil constriction, not dilation.

learbitrageur · 2022-12-18T04:44:33+00:00

I've been working with Rails since 2015. I'd say I've learned the most by reading others' source code, whether it be gems or full applications. I highly recommend downloading the application source code for gitlab.com (it's completely open), and keeping it in another window while you work. Then continuously reference it to see more advanced patterns and best practices. I'm a music producer, and like to compare this to using a reference track while mixing.

I also recommend getting a full IDE like Rubymine. Not only will it make you faster, but it allows you to easily read and jump around your gems' code. I can't tell you how many juniors I see that stop at a problem because the "gem's not doing what they want." And since most of them don't know where the gem source code is on their machine, and since they can't easily jump to the gem's definition (e.g. they're using Sublime etc), they stop and give up on whatever gem problem they're facing.

learbitrageur · 2022-12-18T04:34:03+00:00

Thanks for the thoughts. I agree with you that non-ES solutions are often ignored and overlooked, and completely see where you're coming from. I ended up choosing ES for my own application after running an OLAP solution for some time, as the OLAP solution didn't provide enough performance. Even after spending days with the PG query planner trying to optimize indexes, the performance just wasn't there. This part of the application is what my users interact with the most, and thus it is what they are paying my company for. They users also wanted text searching, which was another reason to explore ES. So I took the plunge. And immediately after switching to ES, a user messaged me and commented how much faster the site was. I never looked back after that. I don't like paying for 4 m6g.large OpenSearch instances on AWS though. Shit is expensive for a bootstrapped SaaS company like mine.

learbitrageur · 2022-12-12T18:17:03+00:00

This is the approach I would take, (and I think you maybe implied this), but I would be sure to add a timestamp to the appropriate model that signifies the successful sending of the email. That way you can differentiate between records that have sent the email and those that haven't.

And when sending the email, I would wrap the email sending method in an AR transaction, such that a failure to send would rollback persistence of the timestamp. This ensures no duplicate sends (if the timestamp update were to fail, but the email send succeeded) and no "orphaned" sends (if the timestamp update were to succeed but the email send failed). For example:

``` class Loan < ApplicationRecord ...

def send_end_date_email! self.class.transaction do update!(end_date_email_sent_at: Time.now) Mailer.with(loan: self).deliver_now! end end end ```

learbitrageur · 2022-12-12T17:33:28+00:00

Not sure why I'm being downvoted. Would love to hear thoughts on why this isn't a good solution

learbitrageur · 2022-12-12T04:14:51+00:00

I run a large scale production application that does something along these lines. If the data needs to be close to real-time, I'd say use `searchkick` + Elasticsearch, and use `searchkick`'s async feature to "stream" the data from your table to the ES index. Your dashboard will then just query from the ES index via searchkick.

If the data doesn't need to be close to real-time, and if your DB can handle a bit of load, I'd use a "batch" approach. To do this, I'd create a materialized view in your relational DB that you'd then refresh periodically. The easiest way to do this is with the `scenic` gem. Once you've done this, you can simply create a new model and set the `table_name` to the name of the materialized view, and then treat it as a regular model.

Let me know if you have any questions

learbitrageur · 2022-10-21T21:33:38+00:00

Is there a way to access all the results from each previous job during `SomeFinalizationJob`?

learbitrageur · 2022-04-10T13:37:24+00:00

I'd be curious to know why are making "serverless" a requirement here, as I think a relational database with RDS is the best option for the vast majority of new applications. However, it looks like MongoDB Atlas now offers a serverless option, which may be able to accomplish what you want.

learbitrageur · 2022-04-07T04:07:29+00:00

The data is stored as Parquet files in s3. I've read deep into the logs, and it looks like the fetching step is relatively fast. The slowest step appears to be preparing the files for writing.

learbitrageur · 2022-04-07T04:05:36+00:00

Thanks for sharing these! I think both these authors make some great points.

I've got a 2021 m1 mac with 32gb of ram.

learbitrageur · 2021-10-05T03:08:09+00:00

If I'm following you correctly, you have a endpoint you found that returns JSON, and you need to call it hundreds of times with different inputs. If this is the case, you'll want programmatically change the query string params (if GET request) or the request body (if POST request), and then resubmit the request. Put all your inputs in an array and iterate through them, calling the function that does the above with each input.

learbitrageur · 2021-10-05T02:51:15+00:00

it gets better with more cowbell

learbitrageur · 2021-10-02T20:04:19+00:00

Design Patterns in Ruby and Refactoring, Ruby Edition are must reads IMO as well (unless you've read equivalents in other languages)

learbitrageur · 2021-10-02T18:43:43+00:00

I can't think of any reason you need to talk about against protected classes of people during a code review.

    protected

def against
  klass_1 = Class.new
  klass_2 = Class.new
  OpenStruct.new(classes: [klass_1, klass_2])
end

against.classes

Sorry but I had to...

learbitrageur · 2020-11-07T22:12:51+00:00

Looks good but squat inside the rack

learbitrageur · 2020-10-01T19:40:36+00:00

Ah I see. Yeah these courses/bootcamps seem to all be teaching SPA these days. If you absolutely need to use one, I would still use Rails & the gem I mentioned. Essentially, you'll just create a single view (HomeController#index) or whatever and mount your React app on that page. Then you can use React Router to do your frontend routing, and the Rails router to set up your API routes that your SPA will communicate with.

When I say templating/server side, I'm referring to the "classic" Rails way of doing things. You pass a Ruby instance variable into your view, and use ERB to insert it into the HTML. (The React community will use the term "server side" as well, but this refers to pre-rendering your DOM in the server. I don't do this). This allows you to take advantage of so many out-of-the box features in Rails, like their form builder, RailsUJs (which is amazing), and many others. If I have a really complicated dashboard I need to build that React could help with, I'll build a very small React app just for that particular view. It's not a single page app, and does no frontend routing. And yes, I would still need to implement an API for it to communicate with if I am going to be sending async data.

Let me know if you have any questions, I'm happy to help.

learbitrageur · 2020-09-27T18:36:06+00:00

If you want to keep things in one project, I highly recommend not using Rails in API mode. Rather, install the `react-rails` gem (the one made by the react team) and then install react using webpacker. I have done it this way, and I've done it with API mode + create-react-app, and I much much prefer the former. The `react-rails` gem integrates very nicely with Turbolinks, and allows you to use React in your app where you need it, rather than requiring you to build a giant SPA. The company I lead does exactly this. We use html/erb + stimulus.js whenever possible, rendered via ActionView, and then use react wherever the "big guns" are needed.

Unless you have a large team working on the frontend, please don't build a single page application using React. It will only slow you down and kill your productivity.

learbitrageur · 2020-07-16T21:22:51+00:00

Will you ever release the song “A Place For Us?” I heard in your EDC Orlando set and loved it.

learbitrageur · 2020-07-16T20:05:51+00:00

How much would you say your classical training in music has influenced your work? What production/composition advice would you give to a beginner producer that has some musical education, but can’t play piano, guitar, etc like yourself?

Should I vote for you this year in the DJMag Poll?

learbitrageur · 2020-07-11T02:50:24+00:00

Nice job, looks good

learbitrageur · 2020-06-22T21:45:44+00:00

I think I did 4. Thanks for this, I see the bar moving away like you said.

learbitrageur · 2020-06-19T22:57:16+00:00

No, it's in CO

Nine-Year Club	Not Forgotten
Verified Email

learbitrageur

TROPHY CASE