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

101–110 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#101

Post by cambalache »

erikrothoff wrote: post #80
tutfbhuf wrote: post #74

Earlier quoted context omitted.

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

I don’t want to second guess technical decisions I know nothing about but: no, Rails shouldn’t be streaming video. But 2k requests per second with mostly text content being shuffled around sounds absolutely doable with Rails. The cost benefit of easier development should definitely not be understated as well. But that being said, the primary driver for tools should be what the developers know and ease of access findi…

> I don’t want to second guess technical decisions I know nothing about but: no, Rails shouldn’t be streaming video.

Yeah, if you are serving video at that rate, there are plenty of CDNs to work with, why would you submit your app engine to that.

Re: Moving my serverless project to Ruby on Rails

#102

Post by forgingahead »

jes5199 wrote: post #92
prh8 wrote: post #89

Earlier quoted context omitted.

CPU load being the ceiling in Rails is typically the sign of sloppy development. Most well done apps it will be the database.

it seems like a lot of my career has been optimizing SQL queries in Rails apps... which is often just adding the correct indexes. Kind of a lot of Rails devs just don’t know to do that

Sounds like a great and valuable blog post to help teach them the right heuristics!

Re: Moving my serverless project to Ruby on Rails

#103

Post by rualca »

nitrogen wrote: post #73
awestroke wrote: post #57

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.

> Rails handled Black Friday and Cyber Monday traffic for an ecommerce company I used to work for just fine.

That says nothing about the added cost of running inefficient services, which require additional nodes to serve the same requests and thus increase operational cost and also risk to perform the same service.

Re: Moving my serverless project to Ruby on Rails

#104

Post by lawn »

murphm8 wrote: post #95
freedomben wrote: post #85

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?

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.

Re: Moving my serverless project to Ruby on Rails

#105

Post by helsontaveras18 »

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…

Whenever I see Medium articles of insane serverless architectures used at the startup stage, my stomach drops. Serverless computing isn’t about fast iteration (for CRUD app development) or even “pay for what you use” (for CRUD app development).

Serverless is typically hard to setup and hard to iterate upon. You want to have a pretty clear understanding of the specific use case you’re addressing beforehand so you can architect the system well, which isn’t easy for a solo developer / small team who just wants to setup a little function in the cloud.

Actually, the best use case for serverless is: - subscription to AWS specific events. It’s all built in and easy to plug into. - elastic ETL pipelines. This is a very enterprise focused use case which involves processing GBs/TBs of data with complex transformations. The variability in data throughput makes serverless an elegant solution. Also, your ETL pipeline isn’t going to change in the same way that a product focused use case of serverless will change.

Re: Moving my serverless project to Ruby on Rails

#106

Post by bdcravens »

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)

Re: Moving my serverless project to Ruby on Rails

#107

Post by knodi »

k__ wrote: post #37
knodi wrote: post #25

Serverless for web apps have one big issues. The cold starts of lambda(s) can be over .5-1 seconds at peek times (us-east-1) any way.

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

Re: Moving my serverless project to Ruby on Rails

#108

Post by tomerbd »

thismodernlife wrote: post #32

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…

Spring + Thymeleaf is also great it's practically Ruby on Rails for Java developers.

Re: Moving my serverless project to Ruby on Rails

#109

Post by rualca »

ysavir wrote: post #15
rualca wrote: post #11

Earlier quoted context omitted.

> (...) I’ll have mature teammates who understand the right tool for the right job. I Honest question: what leads you to believe that Ruby on Rails, or even Ruby, is the right tool for the right job? You didn't even mentioned the job, so why do you automatically assume Ruby is the right tool? Additionally, by ignoring popularity you're also ignoring availability of documentation and examples and mindshare. You're als…

Sounds like this is less about whether RoR was the right tool for the job and more that no one other the implementer was familiar with Ruby/Rails (and maybe not even them). This might mean that this wasn't the right tool _for your team_, but it's not a comment on what jobs are a good fit with RoR.

> Sounds like this is less about whether RoR was the right tool for the job and more that no one other the implementer was familiar with Ruby/Rails (and maybe not even them).

Isn't that already an operational problem? I mean, consider the mental burden alone of being forced to onboard to a completely different and relatively obscure tech stack, including the quirky programming language that serves as it's base, and all just to keep a web service up and running.

Re: Moving my serverless project to Ruby on Rails

#110

Post by heipei »

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 case where your stateful workload (queueing) now lives within your Elixir process which might be killed at any instance?
Post reply on HN