[HN Gopher] Jets: Ruby Serverless Framework
___________________________________________________________________
Jets: Ruby Serverless Framework
Author : thunderbong
Score : 284 points
Date : 2023-12-05 22:01 UTC (3 days ago)
(HTM) web link (docs.rubyonjets.com)
(TXT) w3m dump (docs.rubyonjets.com)
| kulor wrote:
| If people aren't familiar, there's a similar project for Python
| that's fantastic: https://github.com/zappa/Zappa
| lobo_tuerto wrote:
| There is one for Elixir too, Flame:
| https://fly.io/blog/rethinking-serverless-with-flame/
| freedomben wrote:
| Is Flame actually ready for production use yet? I just saw it
| the first time a couple days ago but no idea how long it's
| been simmering.
|
| Flame seems very different to me than Jets though. Flame just
| plugs into a Phoenix app and lets you trivially async some
| application code on a different node through the existing
| erlang functionality without having to manually sync
| memory/state/etc. Definitely cool, but seems fundamentally
| different than Jets which uses traditional "serverless"
| arrowsmith wrote:
| Flame was announced two days ago - the above linked blog
| post is the announcement post. So I'm not sure anyone is
| using it in production yet except fly.io, its creator.
| bigtunacan wrote:
| That looks similar to Chalice (also for Python)
|
| https://github.com/aws/chalice
| Alifatisk wrote:
| How active is this project?
| runjake wrote:
| https://github.com/rubyonjets/jets/commits/master/
|
| Pretty active?
| sam0x17 wrote:
| It's been pretty consistently active over the last four years
| from what I've seen
| sam0x17 wrote:
| Former CTO at Arist (YC S'20) here.
|
| Jet's literally got us off the ground and to the point where we
| could handle spikes where we scale up 1000x to handle hundreds of
| thousands of messages per second and then immediately scale back
| down 1000x because of the spikey nature of our workload.
|
| Almost all of the traditional issues one encounters when running
| a Rails app in production vanish when you build on top of Jets,
| as scaling just becomes something that happens automatically
| without you worrying too much about it other than at the database
| level.
|
| One thing that was particularly impressive about Jets is its
| whole ApplicationJob system that provides an easy-to-use API for
| writing lambda fan-out routines, which we used as the crux of our
| message scheduling and processing system
| https://docs.rubyonjets.com/docs/jobs/
|
| Anyway, I mostly work in Rust now but still am and will always be
| a huge fan of the project and Tung Nguyen, its creator :)
| tongueroo wrote:
| Thanks Sam!
| davidw wrote:
| How much more do you estimate, very roughly, it costs to use
| the serverless stuff in "normal times" outside of spikes
| compared to a more traditional system?
| sam0x17 wrote:
| normal times was well within the free tier, and this was even
| with a pre-warm job turned on for our endpoints. Even the
| spikes were not very expensive. Back then 80% of our bill was
| RDS and I think we were paying under $50/mo for beyond-free-
| tier usage of lambda. It was a tiny fraction of what the cost
| was when we had EC2 clusters.
|
| If you're ok with cold-starts on less-used routes you could
| probably make any medium to low traffic app run totally free
| on jets (other than db)
| quickthrower2 wrote:
| I guess this is a serverless thing rather than Jets-specific?
| Has anyone had this experience in NextJS using serverless
| erm... servers? Maybe Vercel themselves (or Lambda etc.)
| sam0x17 wrote:
| What's really special about Jets in particular is it lets you
| have your cake and eat it too, in that locally you have what
| feels like a pretty normal monolithic Rails app, but when you
| deploy every endpoint magically becomes its own lambda...
| mcintyre1994 wrote:
| To be fair that's exactly what NextJS does too. In dev
| everything runs locally, when you deploy to Vercel or a
| similarly capable host each non-static route becomes a
| lambda.
| aitchnyu wrote:
| How is making each endpoint a lambda helpful?
| zztop44 wrote:
| He says quite clearly in the GP. It solved all their
| scaling problems and massively reduced their costs. With
| a note that their traffic was particularly bursty.
| alex_smart wrote:
| Does the "lambda per api endpoint" part help with the
| application boot part or something? Otherwise I don't
| quite see what advantage you would with that get over
| just one lambda for the entire monolith.
|
| OC also mentions that they run a job to keep the lambdas
| warm. One disadvantage with the lambda per endpoint is
| that he has to keep dozens of lambdas warm instead of
| just one.
| ElectricalUnion wrote:
| Dead code/dependency removal. "Tree shaking". If you only
| serve one route per lambda, you can be (somewhat) sure
| about what you need and compile the minimal optimized
| code path for that.
|
| Less "stuff" in each route, less boot/warmup time for
| each lambda.
| sam0x17 wrote:
| I tend to agree that in a lot of cases just sticking the
| whole monolith in a single lambda is fine, and that's
| probably how I would do it if I had to do things
| manually. But as things grow, it becomes much better to
| tree-shake unused routes, though dead code detection in
| Ruby might as well be a pseudo-science with all that Ruby
| can do lol
| solatic wrote:
| https://open-next.js.org/
| PH95VuimJjqBqy wrote:
| isn't that just cloud?
| tongueroo wrote:
| Jets 5 was just released also
| https://blog.boltops.com/2023/12/05/jets-5-improvements-galo...
| dcchambers wrote:
| 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 wrote:
| 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 wrote:
| Not to mention Jekyll
| freedomben wrote:
| 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 wrote:
| Same, I almost always default to Sinatra. Love me some Rails
| for all the powerful stuff though.
| sho wrote:
| 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 wrote:
| 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.
| jerrygenser wrote:
| 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 wrote:
| 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.
| jmarchello wrote:
| Anything that gets more Ruby out in the world is positive in my
| book. Great looking project!
| nazka wrote:
| Ya I miss the time when Rails was used 2 out 3 times in
| startups. It has it flows but dang the DX and the features it
| has. And the speed you ship things. Even Java with its massive
| ecosystem and devs doesn't have an all packed solution like
| Rails but it gets closer with Spring Boot but not equal or
| better. Maybe Phoenix? We are getting there with TS but you
| have to use 30 different packages and glue and config the whole
| thing before even beginning to code anything.
| arrowsmith wrote:
| > Maybe Phoenix?
|
| Yes
| blondin wrote:
| can't recall the last time i was on a project's page and
| everything just clicked. no fluff. kudos to the team!
| xutopia wrote:
| Is there an example of this to run a web socket?
| kondro wrote:
| Lambda doesn't allow websockets in the way you might expect.
| However, you can use the WS feature of API Gateway[1] to
| implement WS serverlessly in AWS.
|
| [1]
| https://docs.aws.amazon.com/apigateway/latest/developerguide...
| xutopia wrote:
| Oh thank you for this!
| dang wrote:
| Related:
|
| _Ruby on Jets: Like Rails but serverless_ -
| https://news.ycombinator.com/item?id=34474049 - Jan 2023 (84
| comments)
|
| _Jets: Ruby Serverless Framework_ -
| https://news.ycombinator.com/item?id=19893796 - May 2019 (39
| comments)
| askonomm wrote:
| I've learned and previously also professionally worked with:
| JavaScript, TypeScript, PHP, Clojure, ClojureScript.
|
| I really like the ergonomics of Ruby. Should I learn it? How's
| the job market (decreasing|stable|increasing)? Is Ruby also good
| for non-web things?
| promiseofbeans wrote:
| I've been seeing a lot of job postings mentioning rails
| recently
| caseyohara wrote:
| Ruby is absolutely worth learning. It's a nice combination of
| OO and functional programming, and I find it nice to both read
| and write. It's very expressive; I find it easier to model my
| ideas in Ruby than many other languages.
|
| The job market seems healthy and stable, but I'm not a reliable
| source on that.
|
| Outside of web development, Ruby is an excellent scripting
| language, that's perhaps where it excels best.
| uticus wrote:
| Agreed, Ruby the language is fantastic for ease of use
| starting, then more complex concepts ready to go (functional
| programming, WASM, C interopt, etc) when you're ready to dive
| into them.
|
| IMO the jury is still out on its recent changes to make
| things faster and statically typed. With so many other
| options in the script-language space (Python and Javascript
| being biggest by market share) it's difficult to grab a
| bigger piece of the pie, even if the newer features would be
| 100% perfect with no downsides.
|
| As far as jobs, most will be tied to Ruby on Rails - the
| Rails framework of course being built on top of Ruby the
| language. And I'll mention Rails is also worth at least
| trying out, to see for yourself what it does and how it
| works.
|
| [edit: added reference to JavaScript]
| siliconwrath wrote:
| The rails community is working on building out a job listing
| site, worth checking out: https://jobs.rubyonrails.org/
| pelagicAustral wrote:
| I was totally unaware of this. Thanks for sharing the link,
| time to go find a new job!
| itake wrote:
| I've coded in rails for 7+ years. imho, its a dying language.
|
| Better to learn Python, b/c if you want to do anything with ML,
| you have to use Python.
| _hbm wrote:
| People have been saying its dying for years, yet here we are.
| Your reasoning doesn't quite make sense, not everyone wants
| or needs to do ML - choose the right tool for the job.
| norman784 wrote:
| It might be not dying but, for example, our company banned
| new apps to be build with Ruby and Javascript, instead new
| apps needs to be build with Go or Rust, existing apps will
| continue to be written in Ruby and no plans to migrate to
| other languages, but at some point I think it would be
| migrated and/or deprecated.
| nik736 wrote:
| How did it work out for you? Are developers
| faster/slower/same as working with Ruby?
| itake wrote:
| The benefits to go or rust isn't hands-on-the-keyboard
| developer velocity. Servers in Golang or rust will run
| faster (lower cloud costs). It also has lower risk of
| bugs and side effects.
|
| Coding in go is slower than ruby, but debugging go code
| is 100x easier than debugging ruby or python code.
|
| Once companies hit a certain size, the zoom-meeting time
| or system design time is an order of magnitude greater
| than coding time.
| itake wrote:
| Something can be dying for years and not be dead. Other
| languages (python, golang, rust, ts) left ruby behind. Even
| big tech companies founded on rails have diversified their
| tech (Airbnb, Github, Stripe, etc.).
|
| Most companies will have an DS/ML team. "ruby" doesn't
| scale (in that you can't write efficient ruby code that can
| process data at the same level as python/c++ can without
| writing c-extensions to the underyling cpp libraries).
|
| checkout how ruby has fallen off a cliff on github:
| https://madnight.github.io/githut/#/pull_requests/2023/3
| pelagicAustral wrote:
| You come off as an extremely bitter person. Why so much
| anger directed at a programming language (of all things)?
|
| Companies you mention HAD to scale up, then their stacks
| diversified... hell, Facebook was built on PHP, and when
| he time came for a chat functionality to be implemented
| they used Erlang, not because PHP is shit, but because
| concurrency and resiliency was better handled by a
| different programming language...
|
| Realistically, most applications will never need to scale
| up. So what's wrong with a nice framework that allows
| people to just get stuff done?
| rufugee wrote:
| Umm...pointing to facts based on real data isn't bitter.
| Did you see even look at the graph that was shared? It's
| pretty clear ruby is trending downward and I say this as
| a past long-time ruby advocate and fan.
| ElectricalUnion wrote:
| I think that you're conflating correlation with
| causation. I think it's more plausible to assume it was
| the early numbers that are skewed and non-representative.
|
| The fact that GitHub itself was is a killer app of the
| Ruby on Rails, and that the Rails project itself changed
| to being hosted on GitHub somewhat very early on it's
| history [1] had a disproportionate effect on the early
| community that gathered there.
|
| Now GitHub attracts a much more diverse portfolio of
| projects, so the numbers you see there are less
| statistically biased towards early Ruby on Rails
| adopters.
|
| [1] Commit history on the main branch of rails/rails via
| github goes as far as Apr 10, 2008 https://github.com/rai
| ls/rails/commit/c67e985994362290308073...
| itake wrote:
| > Realistically, most applications will never need to
| scale up. So what's wrong with a nice framework that
| allows people to just get stuff done?
|
| I've coded with Rails since Rails 3.
|
| There are a few issues with rails:
|
| 1/ DHH never gets JS right. CoffeeScript, Asset pipeline,
| and now the new Turbo. Migrating your FE every 3-5 years
| to a new language stack is the opposite of "get stuff
| done"
|
| 2/ Rails is built for b2b apps (Basecamp). If your
| business looks like basecamp, then the conventions will
| work for you, but if it doesn't (think b2c apps), it
| won't. Examples: ActiveStorage was a mess with no CDN
| support (it is better now though), Action Cable only
| supports a handful of connections compared to nodejs.
|
| 3/ No ML support.
|
| If you want a framework that "allows people to just get
| stuff done" then use Django. It is similar to rails and
| has all the bells and whistles of the ML community.
| speleding wrote:
| That graph is a bit deceptive, it shows Ruby dropping
| from 19% of commits to 5% of commits. However, since
| inception GitHub grew by far more than a factor of 4 with
| GitHub leaving the initial Rails bubble and the rest of
| the world getting on board.
|
| So in absolute terms the number of Ruby commits grew over
| that time span, it's not declining, and certainly not
| dying.
| ElectricalUnion wrote:
| > "ruby" doesn't scale (in that you can't write efficient
| ruby code that can process data at the same level as
| python/c++ can without writing c-extensions to the
| underyling cpp libraries).
|
| Wait, excuse me, I thought people did not use "python"
| for high performance code either.
|
| They use a module of compiled fortran/C/C++ or a FFI
| interface, that happens to be in python. Calling this
| mass of external modules "python" is extremely naive to
| me.
|
| Using this naive definition that "X solution is in Y
| language if it is started in Y language" almost all high
| performance code in existence is in bash and systemd
| units.
| itake wrote:
| Great! I understand that ruby has similar access to this
| "mass of external modules", but where are they? If I need
| to support face recognition, nudity detection, or
| recommendation engine, how do I `gem install` them into a
| sidekiq worker?
|
| Most LLM client code uses LangChain (or that MS one, I
| forget the name). Where is the ruby equivalent?
| berkes wrote:
| In absolute numbers it may be doing fine. Steadily growing
| even (I don't think it is).
|
| But in relative numbers, that means a significant decline.
| In many niches and usecase, that practically means
| obsolence. Keep in mind that the amount of new people in
| software development have been almost doubling each year,
| for decades.
|
| I'm in Ruby and Rails fulltime for over 12 years now.
| Almost all the work I come across is either legacy,
| maintenance, upgrading or untangling spaghetti.
|
| One reason for that may be that Rails is optimized for "one
| man shops", which by nature aren't jobs people have
| vacancies or hires for. But the more logical reason is that
| people just don't start new projects in Rails anymore. Not
| on a practically significant scale, anyway. For every new
| rails project, there's probably hundreds of python,
| typescript, rust, Java and PHP projects. In web alone.
| dcchambers wrote:
| Ruby is a super nice scripting language. I much prefer it to
| python when I need something with a little more "ooomph" than
| bash. It's just...nice...to write in. Ruby performance has come
| a long way in the last decade as well. There's libraries for
| pretty much everything.
|
| My modern programming toolkit is basically golang + ruby + bash
| and I am never left wanting.
|
| I do find Crystal (https://crystal-lang.org/) really
| interesting and am hoping it has its own "ruby on rails" moment
| that helps the language reach a tipping point in popularity.
| All the beauty of ruby with all of the speed of Go (and then
| some, it often compares favorably to languages like rust in
| benchmarks).
| Alifatisk wrote:
| I actually compile my Ruby scripts with Crystal when I want a
| portable binary!
| pelasaco wrote:
| The Crystal comment that we were missing
|
| > I actually compile my Ruby scripts with Crystal when I
| want a portable binary!
|
| Na, you probably don't do it, but you think you could do
| it. Until you really have to do it and then you see that
| Crystal isn't a drop-in replacement for ruby. Anyway.. if
| every single "Dude use Crystal" person commenting on HN
| would be actually using Crystal, what huge community we
| would have ;)
| Alifatisk wrote:
| > Na, you probably don't do it, but you think you could
| do it.
|
| That's a weird response.
|
| I actually do it, there is no reason for me to lie. Keep
| in mind that I don't use any gems. That is why it works.
|
| Crystal is not an drop-in replacement because some
| features Ruby has does not work in Crystal, but you can
| just write it in another way that Crystal supports.
| vinceguidry wrote:
| If you're being serious, then you're sticking very
| intentionally to the very small subset of Ruby that
| compiles to Crystal and missing out, unnecessarily, on
| the very amazing features that both languages offer to no
| great advantage.
|
| I tried this very thing, and very quickly started looking
| for other options, landing on mruby. Compiled mruby is
| almost as fast as just writing bare C. I just compile an
| mruby interpreter and use that to run .rb files when I
| want speed. It's fast enough for me.
|
| Much, much better than trying to shoehorn Crystal into
| this role.
| Alifatisk wrote:
| You're right, Crystal might not be the best choice but it
| does the job so far. Shipping compiled binaries is so
| sweet, having to force every user to install the Ruby
| runtime isn't fun.
|
| Thanks for the tip, looks like mruby is even a better way
| to provide portable ruby scripts. I'll check it out.
|
| > Compiled mruby is almost as fast as just writing bare
| C. That's interesting!
|
| Just tried mruby and it seems to work very well, the
| packages seems enough for me aswell.
| https://mruby.org/libraries
|
| But how did you manage to compile the .mrb to a binary?
| The boilerplate on the website does not seem to work for
| me. https://mruby.org/docs/articles/executing-ruby-code-
| with-mru...
| cpursley wrote:
| Based on your FP background, you might want look into Elixir.
| Ergonomics of Ruby, FP ideas from lisp and
| scalability/concurrency of Erlang.
| vidarh wrote:
| The job market for Ruby is doing just fine (though, I presume
| you mean _Rails_ - not many of us work mostly on non-Rails Ruby
| stuff, though for me that 's what I prefer), but generally
| getting too stuck into a specific language is not great for job
| advancement for most people. I'm not currently in a Ruby
| focused job, but my last one was, and I had several offers for
| Ruby jobs before I landed where I am now - in the end it came
| down to details of the offers. If you want to maximise your
| pay, Ruby is not where the highest paid jobs are right now -
| salaries are fine, but not the very top (the offers I turned
| down were within 10%-20% of the one I ended up taking; other
| factors weighed more).
|
| I use Ruby _mostly_ for non-web things. Some things non-web I
| 've used Ruby for:
|
| * Orchestrator for a hybrid cloud (1000+ vm's so not huge but
| also not trivial; spread across on-prem, colo, several managed
| providers and a few VMs)
|
| * Queuing system (think Sidekiq, but sadly not opensourced)
|
| * Financial modelling and analysis at a VC fund. Processing
| round data and doing simulations of different allocation
| strategies.
|
| * Lots of devops scripting
|
| * Distributed map tile rendering, and PDF generation of maps.
|
| * Personal projects: * My personal X11 tiling
| window manager (that I'm able to post means it's now somewhat
| stable ;) - Chrome does *not* like window manager quirks ) -
| this one was started a couple of weeks ago and is now my only
| window manager (though my requirements of a window manager are
| basic and specific; I replaced bspwm and used only a small
| portion of bspwm's features) * My personal text
| editor * My personal terminal (this uses pure-Ruby
| X11 bindings, and a pure-Ruby font-renderer) * File
| manager (very basic; replaced Caja for me, but only because I
| hardly do any file management via GUI - it's mostly a launcher)
| (only some of the lower level parts of these projects are open-
| source so far, mostly due to me being to lazy to tidy them up
| for release, but will get there eventually. Other than Chrome
| and a PDF viewer pretty much everything else "visible" I use
| day to day on my own machine is Ruby)
| vinceguidry wrote:
| Did you try out using I3's scripting capabilities before
| setting out to reinvent that wheel? That's the route I'm
| current on right now, but we seem to be kindred spirits.
| Discovering IPC has mostly quelled my urge to reinvent
| wheels. Emacs can easily be communicated with and controlled
| from Ruby, and I'm still figuring out the right approach to
| interop with Firefox. I think eventually I'll just use a
| terminal from inside of Emacs.
| RangerScience wrote:
| Totes should learn Ruby :) One of the most important things to
| learn in Ruby is a sense of "this should be easy" - if you're
| doing something, and it's hard, often times that's because
| there's a different approach that's not only easy, but once
| you're doing it that way you realize it was the Right Way All
| Along.
|
| Job market - At Rubyconf, the part of the literal job board
| looking for seniors was full, but the junior/mid were crickets.
| I think that's the case pretty much everywhere tho, so.
| trevor-e wrote:
| Nice, looks like the Ruby equivalent of sst.dev for folks that
| prefer Typescript.
| ryukoposting wrote:
| I tried Jets a couple years back. I wanted the ease of Rails, but
| with (ostensibly) a cheaper AWS bill.
|
| Actually writing your app and testing it is just as easy as it is
| with Rails. That's good. The hellish cryptic errors when it borks
| a CloudFormation config? Not so good. Ultimately I gave up and
| went back to Rails.
|
| With Jets, you still have to keep in mind that the infrastructure
| is _way_ more complex than Rails. Jets tries to hide away that
| complexity, and it does a good job... until it doesn 't. If
| you're an AWS expert (I'm not) then this is a great tool and you
| should try it. If you aren't, just stick with Rails.
| ajmurmann wrote:
| I've had great success running Rails apps with Google Run. If
| you can live with the initial request sometimes taking 1-2s
| it's great. All my usage is within the free tier and once it's
| set up with Google Build, it's fire and forget
| andrelaszlo wrote:
| Cloud Run? Did you do any work to get cold boots faster?
| giovannibonetti wrote:
| You can have your cake and eat it, too. Have a minimum of 1
| instance "on", with the CPU in low-power mode until a
| request comes. This way, you get low cost in idle times
| without cold starts.
|
| https://cloud.google.com/blog/products/serverless/cloud-
| run-...
| iamflimflam1 wrote:
| But you get charged for that 1 instance running all the
| time which kind of defeats the whole point of it being
| serverless?
| dkobia wrote:
| Tung Nguyen who runs this project has done a stellar job managing
| it. He is super responsive and it is amazing how much time and
| effort he's put into it. I've been pretty active with Jets for
| the last 4 years.
| tongueroo wrote:
| Thanks!
| teaearlgraycold wrote:
| I was a Rails dev for 4 years. After the switch to TypeScript I
| could never go back.
| usernamed7 wrote:
| if you view typescript as equivalent to what rails can provide
| in development... best of luck to you!
| film42 wrote:
| This is pretty cool. For folks on GCP, does it make more sense to
| use vanilla rails with cloud run? I wish lambda had the ability
| to share processes like cloud run with a max concurrency setting.
| fareesh wrote:
| r-r-r-ruby and the jets
| devKnight wrote:
| Missed opportunity to call it Ruby on Rockets XD
___________________________________________________________________
(page generated 2023-12-08 23:02 UTC)