Faster Ruby: Thoughts from the Outside

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • PopRuby - Clothing and Accessories for Ruby Developers
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • Ruby on Rails

    Ruby on Rails

    It is to some extend the problem is in the semantic <%= render "foo" %> may end up rendering different partials based the context it's invoked from, e.g. current locale, etc.

    So the cache can't just be a simple hash.

    Additionally, once you have identified the template to render, if some locals are passed, you then need to lookup the compiled template for that specific combination of parameters, because `render "foo"` and `render "foo", name: "George"` end up compiling two versions of the same template.

    For that later issue we just introduced a way to declare what locals a template accept which should allow us to improve that part: https://github.com/rails/rails/pull/45602

  • aws_lambda_runtime

    An AWS Lambda runtime for crystal.

    I agree insofar as that there is no dedicated runtime for crystal in AWS Lambda, but it can well be used there or in fargate containers. I wrote a (proof of concept) minimal runtime for Lambda some time ago [1] and had pretty decent results.

    Given that both fly.io and Heroku have working buildpacks for Crystal/Lucky, I’d say you can serve pretty heavy load before you’d need to reach for more specialized machines. Of course, that depends on the nature of your application as well. Maybe my understanding of 'large scale' is different from yours, though.

    [1] https://github.com/lagr/aws_lambda_runtime

  • PopRuby

    PopRuby: Clothing and Accessories for Ruby Developers. Fashion meets Ruby! Shop our fun Ruby-inspired apparel and accessories designed to celebrate the joy and diversity of the Ruby community.

  • shipit-engine

    Deployment coordination

    > Usually that was in the form of long-running network calls.

    That's why doing a network call to another service in the middle of a request is pretty much banned from the monolith. Anything that doesn't have a strict SLO is done from background jobs that can take longer, be retried etc.

    Now you mention FedEx so I presume you were working on the shipping service, which by essence is kind of an API bridge so it's probably why it was deemed acceptable there, but that's far cry from what a typical Rails app look like, except maybe in companies that do a lot of micro-services and are forced to do inline requests.

    > that's not a use case that Ruby/Rails are built to elegantly handle.

    I'd argue the contrary, the elegant way to handle this is to perform these calls from background jobs. Look at shipit [0] for instance, it's syncing with the GitHub API constantly but doesn't do a single API call from inside a request cycle, every single API call is handled asynchronously from background jobs.

    [0] https://github.com/Shopify/shipit-engine/

  • crystal

    The Crystal Programming Language

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts