Hacker News Reader

Comment by burlesona | Hacker News Reader

This is interesting. It's obviously designed to look and feel just like Rails, and with "afterburner" can deploy Rails apps to lambda.

It would be interesting to see a direct comparison with what's actually different from Rails. I saw some a few notes in the docs but not a high-level rundown.

Also interesting, was this forked from Rails or written from scratch to mimic the API? It doesn't look like a fork from just reading the source, as the code is organized a bit differently, but the API is such an exact match I can't help but wonder :)

View on HN

Rails is a dependency: https://github.com/tongueroo/jets/blob/master/jets.gemspec#L...

Splitting hairs, but from the gemfile it looks more like bits of rails are dependencies.

That's not rails, that's a few of rails' core components.

I haven't played w/ Lambda, or serverless, much yet. I've always imagined it being used for quick & dirty functions that too trivial to warrant a full blown application. Is there a compelling case for deploying a full-blown Rails app in a lambda, especially when something when deploying a Rails app in a container on ECS is fairly straight forward? That sounds like a lot of code for something that sounds a lot like a simpler function call.

It's all about scalability. With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user. You can scale from minimal to maximal without any intervention whatsoever, and only for the hot parts of your code. Deployment is even more refined than with containers.

I sincerely hope to get to work with this stuff soon; no use case for me at present.

With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user.

You can do that with containers and VMs too. Potentially with fewer worries about cold start latency (at least with Lambda).

Fargate is an interesting sort of middle ground.

The biggest benefit to me has been about flexibility and the shift to a more event-driven way of writing and scaling apps. Which together seem to evolve into a more functional programming like approach to services communicating.

Write a function and deploy it. Want that function exposed via an API? Easy. Want it to be fired in response to an object being uploaded to S3? You can do that too. All it’s concerned with is inputs and outputs. How you compose them is up to you. And if the there’s zero need for a function to be running it’s not running, you’d don’t have ECS containers sitting around idle waiting for work.

The trade off atm is visibility into how & where exactly a given function is being used within a codebase(s).

Reply on news.ycombinator.com