5 ms·

Love seeing non-rails ruby stuff. This project looks cool...In general I think most people should avoid lambdas except for very specific types of workloads, but

Love seeing non-rails ruby stuff. This project looks cool...In general I think most people should avoid lambdas except for very specific types of workloads, but I hope projects like this allow ruby/rails devs to feel a bit more comfortable building lambda functions when they do need one.

freedomben 3y ago
Likewise, non-rails ruby stuff doesn't get nearly enough love. I still use and love Sinatra for small apps quick PoCs/demos/tools. So wonderfully stable and mature, and does what it needs to do.
- manojlds 3y ago
  Not to mention Jekyll
  - freedomben 3y ago
    Oh yeah! I still have two sites powered by Jekyll, and that thing has been a rock. So refreshing compared to the other worlds of constant churn and breakage
- rubyfan 3y ago
  Same, I almost always default to Sinatra. Love me some Rails for all the powerful stuff though.
- sho 3y ago
  Check out hanami next time you're starting something new. It's a little more complex than sinatra, but really gels with how I like to architect things. It's basically "what if dry-rb had a web framework"?
  - bigtunacan 3y ago
    I've done enough with dry-rb to know I don't want to try Hanami. I think at that point it's just better to switch to something truly functional like Elixir.
    - sho 3y ago
      > I think at that point it's just better to switch to something truly functional like Elixir. Well, yes, and I did ;) but since we were talking about ruby...
jerrygenser 3y ago
What's wrong with lambda? If you write a monolithic app that serves your rest API via lambda that pattern can be very powerful. What alternative for such a use case would your recommend instead?
- dcchambers 3y ago
  There's nothing inherently wrong with lambda/serverless platforms, but I feel like most people are better suited by a regular app server running somewhere "normally". I'm not going to pretend I'm a domain expert here, but from my own experience I see several common themes: Serverless has the potential to increase complexity and potential problem points. Scaling isn't as simple. Debugging backend issues can be more complicated. Extra latency when bolting together lots of different serverless things to make one cohesive application. Increased vendor lock-in. I think they're best for certain types of workloads (simple POCs or small side projects with little load can be run virtually free on any serverless platform these days, very bursty/erratic workloads, or workloads run seldomly/ones where a cold start isn't a problem), but not for most use "regular" use-cases.

freedomben 3y ago

Likewise, non-rails ruby stuff doesn't get nearly enough love. I still use and love Sinatra for small apps quick PoCs/demos/tools. So wonderfully stable and mature, and does what it needs to do.

manojlds 3y ago
Not to mention Jekyll
- freedomben 3y ago
  Oh yeah! I still have two sites powered by Jekyll, and that thing has been a rock. So refreshing compared to the other worlds of constant churn and breakage
rubyfan 3y ago
Same, I almost always default to Sinatra. Love me some Rails for all the powerful stuff though.
sho 3y ago
Check out hanami next time you're starting something new. It's a little more complex than sinatra, but really gels with how I like to architect things. It's basically "what if dry-rb had a web framework"?
- bigtunacan 3y ago
  I've done enough with dry-rb to know I don't want to try Hanami. I think at that point it's just better to switch to something truly functional like Elixir.
  - sho 3y ago
    > I think at that point it's just better to switch to something truly functional like Elixir. Well, yes, and I did ;) but since we were talking about ruby...

jerrygenser 3y ago

What's wrong with lambda? If you write a monolithic app that serves your rest API via lambda that pattern can be very powerful. What alternative for such a use case would your recommend instead?

dcchambers 3y ago
There's nothing inherently wrong with lambda/serverless platforms, but I feel like most people are better suited by a regular app server running somewhere "normally". I'm not going to pretend I'm a domain expert here, but from my own experience I see several common themes: Serverless has the potential to increase complexity and potential problem points. Scaling isn't as simple. Debugging backend issues can be more complicated. Extra latency when bolting together lots of different serverless things to make one cohesive application. Increased vendor lock-in. I think they're best for certain types of workloads (simple POCs or small side projects with little load can be run virtually free on any serverless platform these days, very bursty/erratic workloads, or workloads run seldomly/ones where a cold start isn't a problem), but not for most use "regular" use-cases.