Rage: Fast web framework compatible with Rails(github.com)
github.com
Rage: Fast web framework compatible with Rails
https://github.com/rage-rb/rage
113 comments
Also this doesn't show how database access is handled which is the hard part. If you are not touching the database, you can run Rails on falcon and get fiber based concurrency.
If you run falcon on rails and access database, then you have to explicitly checkin/checkout a connection to be safe. Details here - https://github.com/rails/rails/issues/42271.
If you run falcon on rails and access database, then you have to explicitly checkin/checkout a connection to be safe. Details here - https://github.com/rails/rails/issues/42271.
So what would be a better benchmark? Perhaps a "standard" "real world" app, like https://github.com/gothinkster/realworld
> The RealWorld Demo is a large community-backed open source project that showcases all web frameworks client or server-side through a building an example app that is much more substantial than the typical TodoMVC toy demos or the stripped out scenarios you find in benchmarks. As Conduit, a Medium clone of sorts, your application has to handle real issues like authentication, routing, and async data loading. It has a standardized specification [...]
Or something simpler?
> The RealWorld Demo is a large community-backed open source project that showcases all web frameworks client or server-side through a building an example app that is much more substantial than the typical TodoMVC toy demos or the stripped out scenarios you find in benchmarks. As Conduit, a Medium clone of sorts, your application has to handle real issues like authentication, routing, and async data loading. It has a standardized specification [...]
Or something simpler?
> So what would be a better benchmark?
It all depends on what you are trying to demonstrate. The current benchmarks would be fine if properly contextualized and presented a bit differently.
e.g. for the first one, instead of representing it in request/second, do a breakdown of average/p50/p90/p99 latency over X requests. That's both much more interesting data, and much less misleading.
Even the second one could be fine if used to demonstrate why an event loop can be the appropriate thing to use for IO heavy workloads.
But here they are just included with no explanations, implying a blanket "we're 25 times faster than Rails".
It all depends on what you are trying to demonstrate. The current benchmarks would be fine if properly contextualized and presented a bit differently.
e.g. for the first one, instead of representing it in request/second, do a breakdown of average/p50/p90/p99 latency over X requests. That's both much more interesting data, and much less misleading.
Even the second one could be fine if used to demonstrate why an event loop can be the appropriate thing to use for IO heavy workloads.
But here they are just included with no explanations, implying a blanket "we're 25 times faster than Rails".
TechEmpower has a few different classes of benchmark. https://www.techempower.com/benchmarks/
Off the top of my head:
- json serialization
- fetching random objects from an actual mysql/psql database
- cached queries
- performing mutations / data updates
writing "hello world" as a response is naturally going to do 75k per second
Off the top of my head:
- json serialization
- fetching random objects from an actual mysql/psql database
- cached queries
- performing mutations / data updates
writing "hello world" as a response is naturally going to do 75k per second
> It's benchmarking a purely IO workload with Puma caped at 5 threads vs Iodine without a concurrency cap
It appears the benchmark sets the Iodine thread count to 1 as the legend says. Do you think that’s not the case?
Facil.io uses an event loop to handle high concurrency in a single thread, results are not out if line with code that used LibUV.
It appears the benchmark sets the Iodine thread count to 1 as the legend says. Do you think that’s not the case?
Facil.io uses an event loop to handle high concurrency in a single thread, results are not out if line with code that used LibUV.
That is precisely my point. One has concurrency capped at 5, the other has no cap (because it uses an event loop).
The Puma process is likely 99% idle in that benchmark, you could crank up the thread count to 50 and get (not quite) 10x better results.
An event loop is definitely more efficient than a thread pool for such a work-load, I'm not denying that, but in this specific instance Rails+Puma is configured (granted it's just the defaults) with ball and chain.
I'm not saying the benchmark is dishonest, I'm saying it makes no sense.
The Puma process is likely 99% idle in that benchmark, you could crank up the thread count to 50 and get (not quite) 10x better results.
An event loop is definitely more efficient than a thread pool for such a work-load, I'm not denying that, but in this specific instance Rails+Puma is configured (granted it's just the defaults) with ball and chain.
I'm not saying the benchmark is dishonest, I'm saying it makes no sense.
That objection makes no sense. The fact that Puma is idle most of the time reflects a disadvantage. The event loop makes much better usage of a single thread, and that shows in the benchmark.
It's like saying comparing Node to Rhino, or Vertx vs Spring Boot is unfair. Better performance per thread / core is the whole point.
You will not achieve the same level of performance with threads except in low-volume benchmarks, and _especially_ in any kind of cloud environment where you usually only have a single core and a shared kernel.
It's like saying comparing Node to Rhino, or Vertx vs Spring Boot is unfair. Better performance per thread / core is the whole point.
You will not achieve the same level of performance with threads except in low-volume benchmarks, and _especially_ in any kind of cloud environment where you usually only have a single core and a shared kernel.
My point is that event loop are not inherently superior to thread pools.
When you have a workload that is CPU heavy enough that you won't have more than a handful of threads of concurrency, using a thread pool will allow preemption, hence give you a better tail latency, etc.
It's all tradeoff, event loops are good for some work loads, threads for others.
So to make an analogy of my own, it's like making a race between an F1 car and a semi-truck. They are both useful and efficient motor vehicule, but they're not optimized for the same thing.
When you have a workload that is CPU heavy enough that you won't have more than a handful of threads of concurrency, using a thread pool will allow preemption, hence give you a better tail latency, etc.
It's all tradeoff, event loops are good for some work loads, threads for others.
So to make an analogy of my own, it's like making a race between an F1 car and a semi-truck. They are both useful and efficient motor vehicule, but they're not optimized for the same thing.
That's true. Would you then agree that an event loop is very well suited for web server workloads, with short lived requests + reasonably light CPU usage + lots of IO, which happens to be the territory both Rage and Puma are situated?
You said the benchmark is "entirely irrelevant" because it doesn't take into account a scenario that is explicitly not the goal of either project. For those workloads Ruby is already far down the list of best choices.
You said the benchmark is "entirely irrelevant" because it doesn't take into account a scenario that is explicitly not the goal of either project. For those workloads Ruby is already far down the list of best choices.
> Would you then agree that an event loop is very well suited for web server workloads, with short lived requests + reasonably light CPU usage + lots of IO, which happens to be the territory both Rage and Puma are situated?
No, that's where I disagree. The average Ruby web application isn't as IO heavy as people claim, and often contains big chunks of CPU work (typically HTML templating or JSON generation/parsing) that run havoc in an event loop.
My measurements on dozens of Rails app showed the IO ratio tend to be in the 30-70% range. Most closer to 50%. The apps that do more IO than that either have terribly optimized DB queries, or are mostly acting as some sort of HTTP client for an API, but from my experience that's the exception, not the rule.
> For those workloads Ruby is already far down the list of best choices.
Raw speed is far from the only criteria when one chose a stack...
No, that's where I disagree. The average Ruby web application isn't as IO heavy as people claim, and often contains big chunks of CPU work (typically HTML templating or JSON generation/parsing) that run havoc in an event loop.
My measurements on dozens of Rails app showed the IO ratio tend to be in the 30-70% range. Most closer to 50%. The apps that do more IO than that either have terribly optimized DB queries, or are mostly acting as some sort of HTTP client for an API, but from my experience that's the exception, not the rule.
> For those workloads Ruby is already far down the list of best choices.
Raw speed is far from the only criteria when one chose a stack...
That's interesting.
Does that mean the typical Ruby workload would be a better match for userspace preemptive threads like BEAM?
Does that mean the typical Ruby workload would be a better match for userspace preemptive threads like BEAM?
Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
I totally see how you might find these benchmarks irrelevant or "unfair". But there are no lies - I didn't make those numbers up.
These are pretty standard benchmarks showing the overhead of a framework and how it behaves with certain types of operations.
These are pretty standard benchmarks showing the overhead of a framework and how it behaves with certain types of operations.
Slightly off topic: what is the preferred way to deploy Rails these days?
Is it to use Puma? Unicorn, etc?
Is it to use Puma? Unicorn, etc?
There are several options but Puma seems to be the most popular at the moment.
A derivative of Unicorn named Pitchfork is also in the works from Shopify - https://github.com/Shopify/pitchfork
A derivative of Unicorn named Pitchfork is also in the works from Shopify - https://github.com/Shopify/pitchfork
Puma works fine most of the time (config it accordingly of course
No idea what other options are out there though
No idea what other options are out there though
I've been using Nginx/Passenger:
https://www.phusionpassenger.com/library/deploy/nginx/deploy...
https://www.phusionpassenger.com/library/deploy/nginx/deploy...
I actually switch from Passenger (to puma
But then I got reverse proxy (caddy) in front
But then I got reverse proxy (caddy) in front
We use Puma in production.
There is certainly a lot of speculation in Techempower benchmarks and top entries can utilize questionable techniques like simply writing a byte array literal to output stream instead of constructing a response, or (in the past) DB query coalescing to work around inherent limitations of the DB in case of Fortunes or DB quries.
And yet, the fastest Ruby entry is at 274th place while Rails is at 427th.
https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
And yet, the fastest Ruby entry is at 274th place while Rails is at 427th.
https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
Except, increasing the threads increases the memory usage proportionally. From what I have seen, the memory won't be released back and it keeps increasing until the process gets OOM'ed. At least this was the case with Ruby 3.0 and 3.2.
My whole thing is that ruby and performance don't mix, choose something else.
I'm not saying don't bother optimizing something written in Ruby, I'm saying Ruby has inherent limitations in terms of performance. If performance is your goal you're using the wrong language.
I'm not saying don't bother optimizing something written in Ruby, I'm saying Ruby has inherent limitations in terms of performance. If performance is your goal you're using the wrong language.
> API-only - the only technology we should be using to create web UI is JavaScript. Using native technologies is always the most flexible, scalable, and simple solution in the long run. Check out Vite if you don't know where to start.
Thanks. I'll pass on that one. Nevertheless, both rage and iodine seem like pretty cool projects FWIW.
Thanks. I'll pass on that one. Nevertheless, both rage and iodine seem like pretty cool projects FWIW.
>> API-only - the only technology we should be using to create web UI is JavaScript.
> Thanks. I'll pass on that one.
I don't know, there's definitely some merit in separating your front end from your back end - at least that's the impression I got after struggling on JSF/PrimeFaces Java projects for a few years, because at least with a well defined API and no magic behind the scenes everything becomes more observable and easier to reason about, with fewer bugs. Some might prefer TypeScript or something else to JavaScript, but I think the point still stands.
In addition, this lets migrate or change everything piece by piece, as long as the interface isn't broken:
That said, it's also a lot of work because SPA and adjacent approaches bring a lot of complexity into the mix and something like Vue/React/Angular and its ecosystem will bring its own pain points and things you have to learn. If all you need is a bunch of forms, then pretty much anything will do fine and SSR is a good choice. If you need an "app" on the web, then HTML/JS/CSS isn't a very good choice to begin with (historically not built for that; though I don't think there are actually good choices, same as with desktop software), but those SPA solutions will see you pretty far.
> Thanks. I'll pass on that one.
I don't know, there's definitely some merit in separating your front end from your back end - at least that's the impression I got after struggling on JSF/PrimeFaces Java projects for a few years, because at least with a well defined API and no magic behind the scenes everything becomes more observable and easier to reason about, with fewer bugs. Some might prefer TypeScript or something else to JavaScript, but I think the point still stands.
In addition, this lets migrate or change everything piece by piece, as long as the interface isn't broken:
- different frameworks (let's say from Spring to Spring Boot, or from the old ASP.NET to the new variety that runs on Linux, or Rails to Rage or vice versa)
- different languages (if someone decided to take their PHP Laravel solution and migrate to Ruby with Ruby on Rails, or Python, or anything else)
- deprecated technologies can also be handled gradually (e.g. supporting an EOL AngularJS solution while developing a new front end in Vue/React/Angular/whatever)
That said, it's also a lot of work because SPA and adjacent approaches bring a lot of complexity into the mix and something like Vue/React/Angular and its ecosystem will bring its own pain points and things you have to learn. If all you need is a bunch of forms, then pretty much anything will do fine and SSR is a good choice. If you need an "app" on the web, then HTML/JS/CSS isn't a very good choice to begin with (historically not built for that; though I don't think there are actually good choices, same as with desktop software), but those SPA solutions will see you pretty far.
Use HTMX and you'll be surprised how much you don't need JS for (or to be more accurate, very little JS).
Rails especially is very good for this with partials. Use ERBs (or Haml, Slim, etc) and it's an absolute bliss with the added benefit of easy caching.
Stop duplicating state. Stop duplicating logic. Maybe in the future when your app needs 5 different clients, it makes sense to only have an API. But let's not pretend that should be the default!
I still cry every time I see a new application using GraphQL to have literally one client which is simply serving HTML with a bloated JS framework. The whole premise of it was to be flexible for multiple frontends. Come on folks, YAGNI.
Rails especially is very good for this with partials. Use ERBs (or Haml, Slim, etc) and it's an absolute bliss with the added benefit of easy caching.
Stop duplicating state. Stop duplicating logic. Maybe in the future when your app needs 5 different clients, it makes sense to only have an API. But let's not pretend that should be the default!
I still cry every time I see a new application using GraphQL to have literally one client which is simply serving HTML with a bloated JS framework. The whole premise of it was to be flexible for multiple frontends. Come on folks, YAGNI.
I used HTMX since the intercooler days [0] but the stuff you can make is rather limited. Also you still need the JS to deal with a11y things like expanded state (or hyperscript, apparently).
If you have a lot of components to implement, everything requires thinking. Example: You want to add a repeat field to a form. Easy, get the input from an endpoint, and append. Done? No, how do you remove a field? Add a line of JS, simple! Drag and drop if the order needs to change? Let's add a dependency! [1]
I really love it for simple applications though. Resist implementing a complicated menu, live notifications, an editable data-table and such non-web-native things and you can create the fastest CRUD app ever.
And you will need another client (don't YAGNI me on this one, burned too many times by people not caring about endpoint design), but that's not really an issue if your view model does not contain non-public data (it shouldn't), as you can convert it to JSON at the same endpoint (respect the accepts header) and call it an API.
[0]: https://intercoolerjs.org/
[1]: https://htmx.org/examples/sortable/
If you have a lot of components to implement, everything requires thinking. Example: You want to add a repeat field to a form. Easy, get the input from an endpoint, and append. Done? No, how do you remove a field? Add a line of JS, simple! Drag and drop if the order needs to change? Let's add a dependency! [1]
I really love it for simple applications though. Resist implementing a complicated menu, live notifications, an editable data-table and such non-web-native things and you can create the fastest CRUD app ever.
And you will need another client (don't YAGNI me on this one, burned too many times by people not caring about endpoint design), but that's not really an issue if your view model does not contain non-public data (it shouldn't), as you can convert it to JSON at the same endpoint (respect the accepts header) and call it an API.
[0]: https://intercoolerjs.org/
[1]: https://htmx.org/examples/sortable/
Rails with turbo and stimulus is amazing. Very similar to htmx and phoenix liveview. Stimulus lets you make a really minimal web framework for ui elements that are mostly defined as ruby components, and turbo lets you to use erb without whole page reloads. Whole responsive web apps with a dozen lines of js, its great.
What do you mean by UI elements defined as ruby components? Are you referring to ViewComponents or something else?
Yeah you can define viewcomponents in ruby. Have them rendered based on stimulus code. Turbo lets you do updates without full page reloads, viewcomponents make much more reusable and flexible ruby based components than pure erb, and stimulus handles front end state. I rewrote a medium size react + graphql page with this and thr code base was literally 1/10th the size
> I don't know, there's definitely some merit in separating your front end from your back end
This is 100% true and the biggest loss in web development in my opinion.
SPAs actually end up making this worse in the long run though. The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together. The original SPA approach did offer the ability to separate frontend and backend, but the frontend scaled poorly and brought in too many complex considerations like routing, caching, error handling and recovery, etc. The new approach is basically abandoning the benefits of an isolated back end in favor of tight coupling simply because the existing frameworks are too far down the wrong path.
If your goal is ever to isolate the frontend and backend you'll want to consider three environments - backend, web server, and frontend. Ironically that's exactly where we were when SPAs broke out onto the scene
This is 100% true and the biggest loss in web development in my opinion.
SPAs actually end up making this worse in the long run though. The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together. The original SPA approach did offer the ability to separate frontend and backend, but the frontend scaled poorly and brought in too many complex considerations like routing, caching, error handling and recovery, etc. The new approach is basically abandoning the benefits of an isolated back end in favor of tight coupling simply because the existing frameworks are too far down the wrong path.
If your goal is ever to isolate the frontend and backend you'll want to consider three environments - backend, web server, and frontend. Ironically that's exactly where we were when SPAs broke out onto the scene
> The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together.
I'm not familiar with this development. Do you mean that for example React has grown a backend running on a server, querying the database, etc?
I know that backend frameworks like Rails and basically all the major ones added a JS layer running inside the browser and obeying to the backend. It listens to messages from the backend with changes to the UI elements and that saves full page reloads.
I'm not familiar with this development. Do you mean that for example React has grown a backend running on a server, querying the database, etc?
I know that backend frameworks like Rails and basically all the major ones added a JS layer running inside the browser and obeying to the backend. It listens to messages from the backend with changes to the UI elements and that saves full page reloads.
I'm thinking mainly about about SPA frameworks (metaframeworks?) like NextJS, SvelteKit, Remix, and I think NuxtJS as well though I'm less familiar.
They're all adding features where code is marshalled back to the server either through useServer() hooks, pragmas, or magic $ signs and imports.
They all create RPC calls as part of the build and bundle step. Depending on the specific implementation, that usually means taking code that otherwise looks like client code, moving it to the server bundle with a unique API signature, and swapping the RPC API call into the client code.
They're all adding features where code is marshalled back to the server either through useServer() hooks, pragmas, or magic $ signs and imports.
They all create RPC calls as part of the build and bundle step. Depending on the specific implementation, that usually means taking code that otherwise looks like client code, moving it to the server bundle with a unique API signature, and swapping the RPC API call into the client code.
> backend frameworks like Rails
Rails has been a full stack framework since the start, with the JS component changing frequently over the decades, but with template helpers that generate JS being a fundamental component since the beginning.
Rails has been a full stack framework since the start, with the JS component changing frequently over the decades, but with template helpers that generate JS being a fundamental component since the beginning.
I think DHH makes a good argument in Rails World 2023 Opening Keynote; in particular "Fed Pauses Rate Hikes But Stiffens Long-Term Outlook" slide.
Check it out: https://youtu.be/iqXjGiQ_D-A?t=665
Check it out: https://youtu.be/iqXjGiQ_D-A?t=665
Came here just to say your first 2 sentences.
Yeah they lost me there. That's so silly. Absolute takes like that are why we're in this mess we are in today.
Don't make me think! Just follow the trend.
Don't make me think! Just follow the trend.
> the only technology we should be using to create web UI is JavaScript
Quite an interesting idea, but stating that JS is the true way of creating Web UIs misses the mark by miles. You would be surprised by how far you can get with HTML and CSS alone. You will ofc need JS for more dynamic interactions, but ditching the server entirely and delegating everything to JS will just take us to the SPA mess that most of have been burned with.
Quite an interesting idea, but stating that JS is the true way of creating Web UIs misses the mark by miles. You would be surprised by how far you can get with HTML and CSS alone. You will ofc need JS for more dynamic interactions, but ditching the server entirely and delegating everything to JS will just take us to the SPA mess that most of have been burned with.
Especially now that rails is shipping with turbo, hotwire and stimulus. Using no (additional) javascript you can make awesome performant reactive webpages.
I want to believe. Really I do.
Most recent app I worked on used Mantine for a base component library. Having such a large collection of drop-in components made the app come together very quickly. Performance matters but a well built react front-end for a solid MVP is performant enough.
I haven’t seen a vision like this for the stimulus/htmx world. How do you import components?
Most recent app I worked on used Mantine for a base component library. Having such a large collection of drop-in components made the app come together very quickly. Performance matters but a well built react front-end for a solid MVP is performant enough.
I haven’t seen a vision like this for the stimulus/htmx world. How do you import components?
My team is usually view components in our application. Basicslly ruby erb renders the view component in a turbo frame. Turbo allows async updates without redrawing. Then we use stimulus to call small js component that are put into the view components.
I think it's assuming a static site
> the only technology we should be using to create web UI is JavaScript
No.
No.
What do you prefer?
(I quite like ClojureScript.)
(I quite like ClojureScript.)
HTML, the language on the server
I prefer not to use JavaScript unless forced to do so. It's burdensome and almost always unnecessarily complicates the stack. With the rise of tools such as Turbo[1] and HTMX[2] the need for JS frameworks like React and Angular are greatly reduced, to the point that they are (almost?) unnecessary.
[1] https://turbo.hotwired.dev
[2] https://htmx.org
[1] https://turbo.hotwired.dev
[2] https://htmx.org
I'd always prefer React for when you have dedicated Front-end developers but for small go projects, gomponents with its htmx add-on does wonders.
We've been using the Dioxus library for Rust at my company and it's worked well. There's other Rust WASM web UI frameworks as well.
Blazor
yes, I am THAT guy...
yes, I am THAT guy...
Uhhhh, HTML?
Flutter
This was unexpected but welcome, finally something new and fresh to compete with what we currently have. Since it's Rails-compitable? Does that mean I can connect Avo, Bullettrain, Rack-attack aswell?
Can't wait for this to popup on techempower benchmarks! But I would've hoped that there was some proper benchmarks done instead of these unrealistic ones.
Can't wait for this to popup on techempower benchmarks! But I would've hoped that there was some proper benchmarks done instead of these unrealistic ones.
Most of the speed I believe is from using the server iodine https://github.com/boazsegev/iodine which is a wrapper around facil.io https://facil.io that is built using C.
Great project either way!
Great project either way!
Is facil.io maintained? Last commit was 2 years ago, which is a bit concerning for something written in C that handles a bunch of security-sensitive things including a from-scratch JSON parser.
I wonder if the name comes from how funny “RageController” is to read in the code
I was thinking the other day, what exactly is the purpose of this. It seems to simulate controllers, but activerecord is a big part of rails.
I still love the idea, but I don't foresee a migration path since activerecord is still necessary for a migration path
I still love the idea, but I don't foresee a migration path since activerecord is still necessary for a migration path
I am also a little bit confused, if you are touting Rails compatibility, how can you be that much faster? Something has to be left.
But it's sooo interesting! I would love to see it merged with Rails core like Merb on its day, one can dream!
But it's sooo interesting! I would love to see it merged with Rails core like Merb on its day, one can dream!
Great idea, wish it would be merged with Rails itself, but without the opinionated lines, like "the only technology we should be using to create web UI is JavaScript"
It's a really stupid line and whoever wrote it is embarrassing themselves.
Also, a more real/demanding benchmark would be great.
Keep it up!
It's a really stupid line and whoever wrote it is embarrassing themselves.
Also, a more real/demanding benchmark would be great.
Keep it up!
They're right and they should say it. You would think I was insane if I made a CLI tool worked by fetching and running dynamically generated pre-compiled binaries from a server for each subcommand command and yet that's what we do with erb template style apps.
The API + static versioned self-contained html/css/js asset bundle is the way for anything you would reach for erb for.
The API + static versioned self-contained html/css/js asset bundle is the way for anything you would reach for erb for.
Interesting. I'd like to see a full app's code to find where the skeletons are hidden.
I don't mind the opinionated take on JS, each to their own
I don't mind the opinionated take on JS, each to their own
This is great. I had been long looking for something like this in Ruby eco-system. I worked on a Rails app which interacted with a bunch of micro-services and I missed the async-await so much. The problem was, when the app was waiting on API requests, the throughput suffered a lot.
We couldn't increase the number of threads a lot, since it increased the memory usage a lot which eventually led to OOMs.
I tried to put something together using async-http [0], but it was not very stable.
One question would be, how does scheduling work with existing psql and myself db gems. Should the calling code wrap the database calls with `Fiber.await { Fiber.schedule { ... } }`?
A framework like this would be very useful when the tech-world is moving towards micro-services, for the good or bad. [0](https://github.com/socketry/async-http)
We couldn't increase the number of threads a lot, since it increased the memory usage a lot which eventually led to OOMs.
I tried to put something together using async-http [0], but it was not very stable.
One question would be, how does scheduling work with existing psql and myself db gems. Should the calling code wrap the database calls with `Fiber.await { Fiber.schedule { ... } }`?
A framework like this would be very useful when the tech-world is moving towards micro-services, for the good or bad. [0](https://github.com/socketry/async-http)
> Should the calling code wrap the database calls with `Fiber.await { Fiber.schedule { ... } }`?
Nope. Scheduling works seamlessly, thanks to Ruby core.
Nope. Scheduling works seamlessly, thanks to Ruby core.
Hey folks, the author of the gem is here.
Thank you for all your feedback. I value it a lot!
First off, I have changed the API-only bullet point. I wanted it to be short and clear. I didn't mean to sound arrogant. Sorry for that.
Second, I'm working on a guide explaining how to use the framework alongside an existing Rails project. So stay tuned!
Thank you for all your feedback. I value it a lot!
First off, I have changed the API-only bullet point. I wanted it to be short and clear. I didn't mean to sound arrogant. Sorry for that.
Second, I'm working on a guide explaining how to use the framework alongside an existing Rails project. So stay tuned!
Reminds me of Merb[1] - which also targeted performance and eventually got merged into Rails as part of Rails 3.
[1]: https://en.wikipedia.org/wiki/Merb
[1]: https://en.wikipedia.org/wiki/Merb
Aren't you a little short for a stormtrooper?
I mean 180+ commits, 3 month old, bold claims and already 8 releases on rubygems?
There ought to be a vetting/voting process for packages, before they are accepted into a public repo and pollute the global namespace. Like in arch repo/AUR.
I mean 180+ commits, 3 month old, bold claims and already 8 releases on rubygems?
There ought to be a vetting/voting process for packages, before they are accepted into a public repo and pollute the global namespace. Like in arch repo/AUR.
This might be useful but the moment someone asks you to build an admin UI for your API only service you end up wondering why you didn't go with Rails in the first place. And the idea that frontends should be JS only is preposterous.
These kinds of projects are good for the ecosystem. Sometimes the underlying technology (such as using fibers here) could end up being used or merged into Rails itself, after successfully demonstrating the benefits.
If you want a super fast Rest API server… why are you using Ruby?
There are at least 4 languages where it’s more appropriate if you desire a lot of speed.
There are at least 4 languages where it’s more appropriate if you desire a lot of speed.
How come Ruby frameworks don't utilize HTTP/2, Falcon seems like the only alternative but I don't know how mature it is?
Because unless you want to expose your Ruby server directly to the internet without a load balancer, there isn't much to gain in having HTTP/2 between the LB and the app server.
I'm curious though, what's your use case to and HTTP2 up to the app server?
I'm curious though, what's your use case to and HTTP2 up to the app server?
To be honest, I have no use case. I asked out of curiosity.
I think it's in the works for Puma.
Tenderlove posted this gist a while ago as proof of concept:
https://gist.github.com/tenderlove/d68d9a3c4f7941192c9b
Tenderlove posted this gist a while ago as proof of concept:
https://gist.github.com/tenderlove/d68d9a3c4f7941192c9b
Mayu uses HTTP/2. It's still experimental though. https://github.com/mayu-live/framework
> the only technology we should be using to create web UI is JavaScript
Just the tone of that statement is coming from the wrong angle.
Just the tone of that statement is coming from the wrong angle.
I wonder how they get the browser to download the script file?
I don't know but just the tone they used encourages me to try to use WebAssembly
Rockstar Advanced Game Engine
> the only technology we should be using to create web UI is JavaScript.
aight bud. do it without html and css. go on.
aight bud. do it without html and css. go on.
Seems like a cool project. I really like rails and for projects where you only want to use it as an API this seems great. Feels like DHH has been so obsessed with killing JavaScript recently that rails has lost its way a bit.
I think DHH want to keep it as a full-stack framework and not only backend-framework.
I appreciate DHHs and his teams attempt at providing an true alternative to front-end frameworks.
I appreciate DHHs and his teams attempt at providing an true alternative to front-end frameworks.
I mean that’s fair enough, it’s his framework he can do what he wants. But the last two places I’ve used rails it was being used as backend only. I suspect that’s a very standard way to use rails these days and no amount of DHH telling me it’s wrong is going to change that.
That's fine, if you don't want all the frontend bits you can run in API mode, which will skip loading them: https://guides.rubyonrails.org/api_app.html
I find Rails API-mode hard to work with, integrating the frontend towards Rails crud-like api is cumbersome because of all the endpoints you have to manully work with.
While using Rails own templating engine creates all the links and urls for you!
While using Rails own templating engine creates all the links and urls for you!
I'm not sure it's fair to say DHH wants to kill JavaScript, only that he wants to use JavaScript only where he thinks there's no better alternative. i.e. progressive enhancement.
There's still nothing stopping you from jettisoning view support and just using Rails as an API if you want to.
There's still nothing stopping you from jettisoning view support and just using Rails as an API if you want to.
Good to see Ruby isn't dead yet.
Still looks like a niche language.
Still looks like a niche language.
> the only technology we should be using to create web UI is JavaScript
I would argue the same is true for the server.
I would argue the same is true for the server.
Is Ruby still a thing in web development? It seems to me most backend use Java, C#, Node with a bit of PHP here and there.
I would say so, I am subscribed to a mailing list which sums of what's happening within the Ruby and Rails community every week, and there are constantly new startups or projects going on.
An interesting point is that Twitter started in rails and migrated to something (java?) that was faster after they got users. Ideally it would not be necessary to fully replace the application after launch but getting it out the door quickly to start iterating has its upsides.
The biggest problem Twitter had was using MySQL for data storage.They moved to Scala, and while it was not quite a disaster, it did slow progress and also had to be largely simplified. Meanwhile places like GitHub and Shopify proved you could keep on scaling with Rails.
What?
Shopify and GitHub uses MySQL heavily.
And so does Youtube and other behemoths.
Where did you get the notion that MySQL doesn't scale?
Shopify and GitHub uses MySQL heavily.
And so does Youtube and other behemoths.
Where did you get the notion that MySQL doesn't scale?
Exactly- using Twitter's problems on Rails as evidence it doesn't scale is only slightly more wrong than blaming on them on MySQL. Twitter started moving to Cassandra in 2010 to deal with scaling issues they were having with MySQL sharding (gizzard), but continued to release patches to MySQL to address their needs, then eventually created their own data store, Manhattan, optimized for their particular usage patterns. None of this means MySQL (or Rails) can't scale.
> The biggest problem Twitter had was using MySQL for data storage.
Sorry but I find this part contradictory.
And the argument that follows sounds like backpedaling.
Twitter ended up ditching Rails anyways despite "fixing" their data storage. So to me their problem was indeed Rails.
Sorry but I find this part contradictory.
And the argument that follows sounds like backpedaling.
Twitter ended up ditching Rails anyways despite "fixing" their data storage. So to me their problem was indeed Rails.
MySQL was the biggest problem they had though! They brought in Lucene (Earlybird) that massively improved performance- which makes a lot of sense.(in addition to adding Cassandra and eventually manhattan).
Then they started building a lot of things that weren't web applications, like RPC servers (where they created the finagle library) they ended up with a team where Scala and the JVM was more their area of expertise and interest and solution to every issue.
No one thinks you use MySQL to build every kind of data application, no one thinks you use Rails to build every kind of server.
Then they started building a lot of things that weren't web applications, like RPC servers (where they created the finagle library) they ended up with a team where Scala and the JVM was more their area of expertise and interest and solution to every issue.
No one thinks you use MySQL to build every kind of data application, no one thinks you use Rails to build every kind of server.
Doesn't matter what language you use when your architecture is wrong for the problem you're trying to solve.
Last two orgs (and they're large orgs) I've been in have phased it out in favour of node or python on the basis that nobody wants to hire for it. Short-sighted in my view, but that's not a battle I can win.
yes of course it is. Shopify is Rails, as are countless other companies.
There is some life in Rails, but new greenfield rails projects are rare. It is mostly legacy stuff now.
The ecosystem is slowly fading away. Big industrial libs are still good, but a lot of smaller projects are abandonware, last updated in 18-19.
The cool kids moved on to Go, Rust, TS, Elixir etc.
The ecosystem is slowly fading away. Big industrial libs are still good, but a lot of smaller projects are abandonware, last updated in 18-19.
The cool kids moved on to Go, Rust, TS, Elixir etc.
It always puzzled me why Crystal didn't catch up?
It seems like they just had to publish couple of benchmarks and articles here and there and that could have been it.
As it has good C interop story it could have a good chance riding on AI hype wave few years later in this alternative history.
It seems like they just had to publish couple of benchmarks and articles here and there and that could have been it.
As it has good C interop story it could have a good chance riding on AI hype wave few years later in this alternative history.
Crystal had a bit of a slow start. It was promising, but the deployment issues persisted longer than they should have, and by the time they were fixed, you had other toolchains that filled the same niche. Elixir did "ruby" better than crystal OR ruby did.
I really wanted to like Crystal, and used it for a few projects. But the immaturity and timing was it's kryptonite.
I really wanted to like Crystal, and used it for a few projects. But the immaturity and timing was it's kryptonite.
> It always puzzled me why Crystal didn't catch up?
M:N wasn't added until late 2019 :( -- https://github.com/crystal-lang/crystal/pull/8112
M:N wasn't added until late 2019 :( -- https://github.com/crystal-lang/crystal/pull/8112
Because there's not enough differences/advantages compared to Go.
Metaprogramming, null safety, syntax familiarity (with Ruby), algebraic types - there are quite a lot of advantages/differences, no?
I’m not sure if it changed, but Crystal was limited to a single core which I imagine made it easier to choose Go over Crystal.
That and I’ve found that folks often aren’t very receptive to Ruby like syntaxes initially.
That and I’ve found that folks often aren’t very receptive to Ruby like syntaxes initially.
This thread's context is large rails userbase around 2008'ish (people were changing computers from pcs to macs with textmate to do rails, perception of devs changed from nerds to cool kids - the whole thing was quite huge) that dissolved substantially. Crystal's syntax in this context feels like huge wasted/missed opportunity.
This claim seems to be supported by Google Trends [1]
Rails has been on a downward trend for the last 6 years.
[1] https://trends.google.co.in/trends/explore?cat=958&date=2017...
Rails has been on a downward trend for the last 6 years.
[1] https://trends.google.co.in/trends/explore?cat=958&date=2017...
More than "a bit" of PHP, lad.
The first benchmark is pretty much an empty request, so it measure each framework "overhead". That shows Rails+Puma at `0.25ms` overhead per request, and rage+iodine at `0.013ms`. That is significantly less yes, but it the overwhelming majority of case it absolutely don't matter, and this difference mostly come from Rails providing extra features.
As for the second one, it's entirely irrelevant. It's benchmarking a purely IO workload with Puma caped at 5 threads vs Iodine without a concurrency cap. You can increase "Rails" throughput about as much as you want in that benchmark by raising the number of Puma threads or switching to Falcon.
But also, not capping concurrency like this is risky. The second some CPU heavy work is mixed with this pure IO work, latency will suffer terribly. It's fine for a micro-service where you know it's really all IO though.
Disclaimer: I'm a member of Rails, but I welcome alternative frameworks, I'm just very annoyed at how terrible most benchmarks are.