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

151–160 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#151

Post by rkangel »

bdcravens wrote: post #106
rkangel wrote: post #72

For people in a similar situation, I'd strongly suggest giving Phoenix (on Elixir) a look. It's a "boring" Rails style server side rendered web framework, but with a few extra powers: * Elixir is a great functional programming language * When your backend needs to do more complex or longer running work it's just more Elixir rather than complicated architecture involving task queues etc. (because you have the concurre…

> 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 smart guy and an excellent developer who's opinion I therefore give some weight to.

Re: Moving my serverless project to Ruby on Rails

#152

Post by ohgodplsno »

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…

That's a consequence of using ORMs. ORMs are a horrible performance mess. Just straight up write SQL. I'm sure Ruby has enough metaprogramming magic to not have to deal with cursors manually.

Re: Moving my serverless project to Ruby on Rails

#153

Post by mxz3000 »

sheeshkebab wrote: post #19
Dunedan wrote: post #7

> A lambda publishes a message to SNS, another one picks it up and writes something to DynamoDB, the third one takes that new record and sends an email… Or, you know, just do related functionality in the same AWS Lambda function. While I would probably do the sending of an e-mail asynchronously as well (as AWS Lambda function triggered by a DynamoDB stream), the indirection over SNS to write something to DynamoDB see…

If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA. There might be no “silver bullet”, but aws serverless is like rusted bucket.

Totally, cloudformation is terrible and verbose. [Cloud Development Kit](https://aws.amazon.com/cdk/) however, is superb.

Re: Moving my serverless project to Ruby on Rails

#154

Post by desireco42 »

I moved to Phoenix and it is wonderful. Except... Ecto just isn't as easy as ActiveRecord and you can't do things the way you would prototype things in IRB. So, yeah, on one hand, I have crazy performance and LiveView etc, but on other, it is huge hassle just to hack around the way I did before.

Re: Moving my serverless project to Ruby on Rails

#155

Post by bostonvaulter2 »

heipei wrote: post #110
rkangel wrote: post #72

For people in a similar situation, I'd strongly suggest giving Phoenix (on Elixir) a look. It's a "boring" Rails style server side rendered web framework, but with a few extra powers: * Elixir is a great functional programming language * When your backend needs to do more complex or longer running work it's just more Elixir rather than complicated architecture involving task queues etc. (because you have the concurre…

I'm curious, and I know this is a random thread to post this question, but how do you handle the fact that the Elixir process might be shut down with regards to necessary persistence of any message queues? Put differently: I consider both message queues and databases in my system to be part of the stateful workloads and the web app part of the stateless workloads (can-be-killed-at-any-time). How do you handle the cas…

If you want a persistent task queue in Elixir then I would use a library like oban [1] that uses postgres to manage the jobs, a nice benefit of it is that you can enqueue your jobs as part of a database transaction (and Ecto.Multi gives you a nice interface to transactions). And just because you can have a message queue directly inside your application server doesn't mean you need to or that it's a good fit for every project.

1. https://github.com/sorentwo/oban

Re: Moving my serverless project to Ruby on Rails

#156

Post by techthumb »

In OO systems, we often talk about "Simple Objects & Complex Interactions" v/s "Complex Objects & Simple Interactions".

In my experience, being at either extreme becomes counter-productive.

To me, it comes down to finding the "happy middle" for your project.

Monolith v/s Micro-services/Serverless are similar. Neither extreme is productive. There exists a happy middle depending on the situation.

Re: Moving my serverless project to Ruby on Rails

#157

Post by ledauphin »

0x445442 wrote: post #55

Having worked with AWS serverless for a couple of years, I think the architecture is not well suited for replacing a monolithic application. If horizontal scaling is an issue, I think containers are better suited. Serverless seems to be a better fit for ETL/Data Transformation workflows.

serverless (well, lambdas) would be very expensive for any truly significant ETL work. if you have long-running jobs of any kind, that's precisely the opposite of where serverless shines.

Re: Moving my serverless project to Ruby on Rails

#158

Post by earthboundkid »

rualca wrote: post #27
vp8989 wrote: post #23

Earlier quoted context omitted.

"AWS's Serverless Application Model explicitly supports local testing." It doesn't provide any additional capability that was already there. Ie, I could already run my arbitrary function from the CLI by building a simple wrapper that reads a JSON file and sends it in. Or wrap it in a simple HTTP server. The debugging story using that tool is worse than how I would already do it pre-SAM and they don't even have docume…

> It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally. Sounds like you're mixing up how a test pyramid works. AWS SAM supports running unit tests locally. Your remarks refer to integration tests. Integration tests are expected to be performed on environments that mimic either subsets of the production environment, or the whole production environment. https://docs.aws.amazon.com/whi…

It’s only an “integration” test because you split things up too much. In a monolith, it would all be unit tests against a mock DB.

Re: Moving my serverless project to Ruby on Rails

#159

Post by earthboundkid »

nickjj wrote: post #99

I've been tinkering with Serverless (on AWS) for some client work recently and my view is about the same as this post. Every complaint he listed is what I encountered too. It's one of the most unfriendly dev experiences I've seen in ~20 years of development. OP's post contains: > What started as a simple function, grew into a bunch of serverless functions, SNS topics, S3 buckets, DynamoDB tables. All bound together w…

Someone needs to rewrite the old “SOAP is simple” article to be about “serverless.”

Re: Moving my serverless project to Ruby on Rails

#160

Post by earthboundkid »

grose wrote: post #123

I like using the “serverless monolith” architecture. You use a catch-all API gateway hooked up to a single lambda. You write it the same as any standard HTTP server and let an adapter handle the lambda bits[1]. During development you run it as a regular HTTP server and connect directly to localhost. To deploy it all you need is a shell script that zips and uploads your binary to lambda. All state is stored in DynamoD…

This is what I’ve been doing with Go on Netlify (which is a wrapper around AWS Lambda). https://blog.carlmjohnson.net/post/2020/how-to-host-golang-o...
Post reply on HN