Live data from Hacker News

Moving my serverless project to Ruby on Rails

frantic.im

131–140 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#131
post #119

Earlier quoted context omitted.

Elixir (with Phoenix) really is the sweet-spot for a productive framework that's fast, scalable and easy to pick up for a Rails developer: https://medium.com/coryodaniel/from-erverless-to-elixir-4875...

Isn't normal Rails the fast, scalable and easy to pick up framework for a Rails developer? Elixir has hype factor, but it still lacks the library ecosystem of Ruby. It's entirely possible to get to github scale with just Ruby and not have to learn all the gotchas of BEAM and OTP.

I've been using Elixir in production for four years now, in a fairly complex SaaS app, and I can comfortably say I've never had to "learn all the gotchas of BEAM and OTP". IMO Elixir/Phoenix do a really good job of abstracting all of that away from you, while still making it easy enough to tap into their intricacies if needed (e.g. if you want to write a GenServer for something).

Lack of library support was a bit annoying at first. But then I realized that, back when I used to take advantage of existing libraries in Ruby/Rails, in the vast majority of situations I was just utilizing a small portion of those libraries anyway. It ended up easy enough to write my own code for those features.

Re: Moving my serverless project to Ruby on Rails

#132

Earlier quoted context omitted.

Really? Our frontend servers handle 50 rps and cost $20 each and are nowhere near peak utilization. If anything ever needs scaling its the database. What level of traffic are you talking about?

For example a newspaper with customizable content, 1 petabyte (70% video) per month and avg. 2k request per second.

Which newspaper is hitting 2k req/s ?

Re: Moving my serverless project to Ruby on Rails

#133

Earlier quoted context omitted.

I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…

This very much depends on the use case. If you are truly CPU-bound than yes, ruby is a bad choice. Similarly, if you are IO-bound or otherwise need a lot of concurrency ruby is not great. I also think it's problematic for large code bases with hundreds of developers. However, there is a huge swath of web apps and APIs that just need to pull a bit of data from a DB or two, munge it together and send it to the client.…

I definitely agree that when writing Rails at scale, it's extremely important to view ActiveRecord as just another tool in the toolbox, and not always effective for every use case. I've worked in places that had a dogmatic aversion to ever writing raw SQL, and to a one they always suffered for it in performance sensitive code.

At the places who did handle this well, the "high-performance code" that needs to be hand-tuned SQL is usually much smaller than you think (a few queries here and there), and ActiveRecord is still great for your simple queries or for smallish tables.

Re: Moving my serverless project to Ruby on Rails

#134
post #95

Earlier quoted context omitted.

Second this. I did rails for years and liked it a lot, but there were pain points, particularly as a project scaled. Elixir/Phoenix solves a lot of these pain points and is a joy to work with. If you like Ruby/Rails then you already know quite a bit of Phoenix. Schedule yourself 4 hours to follow a tutorial or book.

Do you have any recommended books or tutorials?

If screencasts are your thing, I've put a lot of tutorials on YT. They start from scratch: https://www.youtube.com/watch?v=z1nKbzZiRtY&list=PLFhQVxlaKQ...

Re: Moving my serverless project to Ruby on Rails

#135
post #107
post #37

Earlier quoted context omitted.

Thete are multiple solutions to that problem. 1. API Gateway and AppSync integrate directly with many other AWS services, no Lambdas needed, and thus no cold-starts. 2. Lambda has provisioned capacity. 3. Other cloud providers like Cloudflare offer FaaS without cold-starts.

Yes and all of them are bad

Care to elaborate?

Re: Moving my serverless project to Ruby on Rails

#136

I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec. Regarding hosting, I think this is actually a great time to host Rails apps…

Having learned web dev around five years to go, my main stack has been Node/Express or Firebase (serverless) with React front-ends.

However, I got tired of the lack in conventions in Express, and Firebase has quite a few gotchas and limitations, so I'm moving to good old Django. I'm delighted thus far, I love not having to reinvent the wheel every time I start a project or add a feature.

I'm probably keeping React/Next.js as my primary working tools for the front-end nonetheless, but that's just me because I feel highly productive with them and I've become accustomed to the decoupled client/API architecture.

I can see the merits of SSR with templating as seen in RoR or Python, and I'm happy to have that tool in my belt. But conversely I also think it's worth for pretty much everyone to learn React (or Vue, Svelte, or what have you) because they do open different possibilities in UX engineering and app architecture, and the market is quite hot for them too.

Re: Moving my serverless project to Ruby on Rails

#137

Earlier quoted context omitted.

Scaling horizontally is not cheap. A faster language needs fewer replicas.

Rails handled Black Friday and Cyber Monday traffic for an ecommerce company I used to work for just fine. If you are making money, it's worth the cost of 50 lowend VPSes autoscaled (we could have done with a lot less, too). If we were using Java it would have taken us three times the people and four times as long to build the site, and we all would have been laid off.

For rare events this concept works fine. For large sustained loads using more language/runtime could save a fortune.

Re: Moving my serverless project to Ruby on Rails

#138

I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec. Regarding hosting, I think this is actually a great time to host Rails apps…

I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…

"the simple fact that Ruby is really, really slow"... it's that slow that Shopify and Stripe don't mind building their global scale products in Ruby.

Re: Moving my serverless project to Ruby on Rails

#139
How are you finding managing infra for rails? Is disaster recovery quick for you?

I'm the author of openfaas and hear what you say about the fragmentation for using AWS Lambda. We recently made a rails-esq version of OpenFaaS for users who have a single small app like yourself. I would be interested in your impressions. It's all open source and is a bit more of a more modern stack. On the upside it uses containers and you can write in any language.

https://www.openfaas.com/blog/faasd-tls-terraform/

Re: Moving my serverless project to Ruby on Rails

#140
One thing you have to realize, is that "enterprise" architectures are as much about workforce management as they are about efficiency, or scalability, or et al.

There's a limit to how reduced data, and functions that work on data, and the transports and relationships between it all, can get. Let's call this residual mass "goo". Well, the goo has to go _somewhere_.

Post reply on HN