Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving my serverless project to Ruby on Rails

frantic.im

Post reply on HN
Print view View original

161–170 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#161

Post by jaredcwhite »

rkangel wrote: post #151
bdcravens wrote: post #106

Earlier quoted context omitted.

> You have options like LiveView for your frontend Worth noting Stimulus Reflex uses the same approach as LiveView (most stacks have similar options)

The Phoenix framework was created by Chris McCord. He was a long time Rails developer who tried to create a LiveView equivalent in Ruby/Rails but concluded that the concurrency capabilities just resulted in too many edge cases that didn't work well. That process led to him working more with Erlang and Elixir, then creating Phoenix. I have never used Stimulus or Stimulus Reflex, but based on his output Chris is a smar…

No doubt, but there are some pretty awesome wizards working on StimulusReflex (and CableReady which it sits atop) as well, so I think it mostly depends on if you're keen to program in Elixr or Ruby.

Re: Moving my serverless project to Ruby on Rails

#162

Post by jaredcwhite »

joelbluminator wrote: post #118
Lammy wrote: post #3

I've seen a lot more discussion of Ruby recently than in past years, and maybe I'm just finding what I'm on the lookout for, but either way it makes me happy :)

I think it's past the latest hate cycle to good all boring now, kinda like php but with a bit of a better rep. I'm not sure actually why php and ruby are so despised.

I'm a committed Rubyist but I'd jump into using PHP/Laravel in a heartbeat if I couldn't use Rails any more. It seems way more sensible and well-designed than the terrible state of affairs you find in JS backend land. (shudder!)

Re: Moving my serverless project to Ruby on Rails

#164

Post by liquidwax »

AWS Amplify[1] actually has neat tooling for serverless projects and lets to deal with just the core of your product and worry less about infra. Admittedly, it helps if you know the underlying connections but in my experience that's true with rails too. Building a blog with rails isn't the same as a more complex product.

[1] https://aws.amazon.com/amplify/

Re: Moving my serverless project to Ruby on Rails

#165

Post by treis »

joshmn wrote: post #150
ffdjjjffjj wrote: post #51

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…

Rails makes it really easy to do something 10 different ways to get the same result. Unfortunately, most of which aren't the most performant way. In my 10 years of building Rails apps of all different sizes, and seeing some very mature apps in production, this is the most common culprit I've seen. I currently work on a rather large Rails app for a site that most of us here use. A common pattern for our performance pi…

Your examples aren't really doing the same thing in two different ways. Map (and select, collect, each, and some others) iterate over an enumerable. Pluck and select are active record methods that generate SQL.

It's a good example of choosing magic/brevity over expressiveness. You don't know that Tag.all.map calls SQL because it's not something you explicitly tell it to do. That's the real issue with Ruby & Rails. The magic lets you do some powerful stuff but sometimes it's hard to tell what exactly is happening.

Re: Moving my serverless project to Ruby on Rails

#166

Post by helsinkiandrew »

I’m not sure the issues experienced are due to serverless rather than the architecture chosen. A monolithic app vs services.

Why split up the serverless functionality into separate functions connected with SNS etc? You can call the same ruby code from a single serverless lambda endpoint invoked from a http call in the same way you would from a rails process.

Rails is great, but you could run Rails on a serverless architecture (AWS) too if you really wanted to, and you could create a multi service architecture of Rails components that would be equally hard to maintain and develop.

Re: Moving my serverless project to Ruby on Rails

#167

Post by freedomben »

lawn wrote: post #104
murphm8 wrote: post #95

Earlier quoted context omitted.

Do you have any recommended books or tutorials?

Programming Phoenix is good. You might want to look at something Elixir specific too, I liked Programming Elixir although I've heard good things about Elixir in Action as well. The official online documentation is pretty good too.

I also used Programming Phoenix. Good book. I didn't find the code examples useful for "real world" stuff but they were good for learning.

Re: Moving my serverless project to Ruby on Rails

#168

Post by Fire-Dragon-DoL »

WJW wrote: post #119
cpursley wrote: post #56

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 have written Rails for 8 years and Elixir for 3. Phoenix is essentially what Rails should have been.

It has the upsides of Rails without the connected antipatterns, native technical debt.

I can also confirm that there isn't a need to learn BEAM gotchas (which i did learn). One of my ex colleagues is a junior dev who has been using elixir for 3 years now and didn't need to use those special aspects of BEAM.

As a Ruby expert, Elixir is substantially easier, learning BEAM is a joke (and very instructive) compared to learning the entirety of the Ruby object model.

I can't think of reasons to use Rails nowdays. If you are in the CRUD apps market, use Postgrest or similar products. As for the rest sure, choose any language you want, the framework is way less relevant (arguably: detrimental) at that point.

The industry has proven extensively that for non-trivial projects, Rails is damaging due to ActiveRecord.

Re: Moving my serverless project to Ruby on Rails

#169

Post by joshmn »

treis wrote: post #165
joshmn wrote: post #150

Earlier quoted context omitted.

Rails makes it really easy to do something 10 different ways to get the same result. Unfortunately, most of which aren't the most performant way. In my 10 years of building Rails apps of all different sizes, and seeing some very mature apps in production, this is the most common culprit I've seen. I currently work on a rather large Rails app for a site that most of us here use. A common pattern for our performance pi…

Your examples aren't really doing the same thing in two different ways. Map (and select, collect, each, and some others) iterate over an enumerable. Pluck and select are active record methods that generate SQL. It's a good example of choosing magic/brevity over expressiveness. You don't know that Tag.all.map calls SQL because it's not something you explicitly tell it to do. That's the real issue with Ruby & Rails. Th…

That's why I said they produce the same result instead of saying they do the same thing. If you read further in my example, I mention that they perform very differently under the hood.

Re: Moving my serverless project to Ruby on Rails

#170

Post by rangoon626 »

VWWHFSfQ wrote: post #67

I pretty much just start all of my projects, no matter how small, with Django. Working with microframeworks or serverless is great at first but as soon as you need any more of the typical features that a webapp requires then you start pulling in dependencies or re-implementing half of Django yourself anyway. First you just need a little url router to some basic views. OK that's great, anything can do that. Now you ne…

What you wrote about is something that I really struggled with wrt serverless when I first started learning it. Lambda, at this point, feels to me like doing a php project without using any framework. You are doing it all yourself, all the tedious stuff.

I have started to mix Zappa and Django to get the best of both Django and Serverless. So far, I like it. I have not hit any considerable scale yet, so I wonder if Django is too heavy, or just right. It seems fine so far. The other plus - it’s all open source tech, so it’s easy to move away from Lambda if I need to.

It’s even better, too, because you CAN break out some more isolated functionality into stand alone lambdas when they start to get clumsy inside a typical Django proj.

Post reply on HN