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

111–120 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#111

Post by hodgesrm »

nitrogen wrote: post #78
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…

One of AWS's major flaws is that it provides an encouraging UI that almost begs new teams to create a special snowflake manual configuration. The AWS UI should ideally be refactored to be a frontend for an infrastructure as code service like CloudFormation. One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it.

Why wouldn't Terraform be sufficient? I use Terraform to manage real deployments, but the UI is very useful to scan the environment. This is partly because the aws-cli is so awful^h^h^h^h^h hard to use as an interactive tool.

Re: Moving my serverless project to Ruby on Rails

#112

Post by joelbluminator »

sodapopcan wrote: post #46
luxurytent wrote: post #38

Earlier quoted context omitted.

Replace Rails with Django and this comment seems to hold true for many in the Django community. Boring can be good.

Boring tech is great if your primary concern is writing business logic. Ideally, this should always be true, but of course the reality is that people's jobs often have them working on products they don't really care for. And of course, it's easy to get distracted by tech anyway. Experience also comes into play when it comes to loving "boring" tech—it took my around a decade before I was sufficiently jaded that almost…

> it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic

It's comforting to see I'm not alone. I just wanna ship clean code and contribute value to the business, while all the young bucks in my team are more interested in rewriting our REST apis in Graphql (with all kinds of rationalizations). Looks like the younger you are the more eager you are to explore new tech and the older you are the more keen you are in just delivering value in a boring old stack.

Re: Moving my serverless project to Ruby on Rails

#113

Post by jbverschoor »

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

and java devs and c++ devs and php devs and python devs etc. etc.

Re: Moving my serverless project to Ruby on Rails

#114

Post by joelbluminator »

mattmanser wrote: post #79
neurostimulant wrote: post #49

Earlier quoted context omitted.

What's the benefit of moving from Rails to Node and React productivity-wise? On the backend side, Rails comes with an ORM, authentication, templating system and many more out of the box, while on Node you'll need to mix and match a bunch of 3rd party libs or roll your own, which might be a good thing depending on your priorities but certainly kills productivity. On the frontend side, you can always use react with rai…

Even in mid-sized projects there's usually one or two pages with sufficiently complicated front-ends that it's worth having something like React in your toolbox, though it might be Vue or Svelte. You don't have to make the whole app a SPA to use these tools. You can just use it in those few pages that really need it.

Meh, put React into your build, maintain the thing, make the website download and parse React - all that just for one page? Better be a damn dynamic page. I wouldn't do it even if it's a big form with some dynamic fields.

Re: Moving my serverless project to Ruby on Rails

#115

Post by joelbluminator »

rualca wrote: post #11
jspash wrote: post #6

Every time I read that one of the “downsides” of RoR is that it “doesn’t sound cool” I know I’m in the right place! I’ll have mature teammates who understand the right tool for the right job. I won’t have to work with magpie developers with an acute case of not-invented-here syndrome. Granted Rails isn’t the answer to everything. I’ve been loving what we can accomplish with elixir/Phoenix. But I’ll leave the hipsteri…

> (...) 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…

Holy crap! you were paid to work on a Rails app and you actually had to learn Ruby/Rails to get stuff done? The horror! I would seek compensation from my employer for that, not way is that legal.

Re: Moving my serverless project to Ruby on Rails

#116

Post by joelbluminator »

rualca wrote: post #29
schnable wrote: post #22

Earlier quoted context omitted.

If you knew Ruby and not the Python, the whole scenario would have been flipped.

> If you knew Ruby and not the Python, the whole scenario would have been flipped. That's why popularity matters. The odds that any random kid already has experience with Python are far greater than him knowing Ruby.

I get the point, it's not completely invalid. And still, calling Rails "obscure" is a stretch. In web dev world it's still a pretty dominant framework. There shouldn't really be any problem to hire Ruby guys afaik.

Re: Moving my serverless project to Ruby on Rails

#117

Post by vikingcaffiene »

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…

I recently migrated part of a platform over to a distributed architecture with a heavy reliance on serverless functions. We had very specific reasons for doing it that I wont get into, but I can confirm that its an unbelievably bad experience from a development standpoint. We tried all the usual tools like localstack and SAM local and it all just suuuuucked. Something that would have been a day or twos worth of work with a tranditional api endpoint would stretch out to weeks. We ended up getting fed up and put all the calls to our serverless functions behind interfaces. Then, when running locally, we swapped out the transport layer to call a simple webserver that can call the the functions directly. We've been leveraging that approach for a few months now and its smoothed out a lot of issues for us. The downside of course is that you aren't using the same networking as whats deployed but so far it hasn't been as much of a problem as I was afraid it would be and our velocity has increased quite a bit.

I would go as far as to say the unfriendly local dev experience is almost the point. They want to lock you into having to use their platform to get anything done. They want to make this stuff as difficult to abstract as possible. They want you to use their proprietary methods for code sharing (looking at you lambda layers...). All of it is designed so that you simply can't run your logic without tying yourself inextricably to their platform. It's a spiderweb that you don't notice until you are trapped in it.

Re: Moving my serverless project to Ruby on Rails

#118

Post by joelbluminator »

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.

Re: Moving my serverless project to Ruby on Rails

#119

Post by WJW »

cpursley wrote: post #56
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…

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.

Re: Moving my serverless project to Ruby on Rails

#120

Post by jgautsch »

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…

You can add a kill/shutdown message handler and move your state somewhere else before the process dies.
Post reply on HN