Designing a Ruby Serverless Runtime | Hacker News Reader

Designing a Ruby Serverless Runtime

daniel-azuma.com

51 pointskiyanwang12 comments

Hey Daniel this is super cool and I appreciate all you've done over the years to support our use of Ruby on App Engine.

This is extremely exciting -- I've always loved the idea of running Ruby in a serverless context, and I've always preferred Google Cloud Functions to Lambda for its simplicity. This is super good news in general.

I definitely recommend taking a look at Ruby on Jets for inspiration, which brings a very rails-like serverless Ruby framework to fruition in AWS Lambda.

I have Opinions about Rails or Rails-like frameworks on FaaS.

But that said, now that Google has a full-fledged Ruby runtime, it might be interesting to see if Jets can be rebased on Google Cloud Functions, maybe some adapter layer that can be swapped in for different underlying cloud vendors to help applications avoid lock-in to any vendor's product.

Glad Google is catching up with Ruby. But if you really want to learn how I am doing this with AWS and how easy it is to handle Rails on Lambda, check out the Lamby work here. https://lamby.custominktech.com

This looks really well done, congrats!

How are people managing Cloud Functions these days? Any ruby tools around this topic? I‘m excited to try this on the weekends.

edit: also huge thanks for unbundling the google-cloud ruby gems.

Yeah, splitting up google-api-client was long overdue. I was really glad to have a window to do it over the holiday.

If you have feedback on Cloud Functions, feel free to open issues on the GoogleCloudPlatform/functions-framework-ruby repo on GitHub, which is where the open source side of the runtime is housed.

I don't use Ruby much anymore, but I used to be an avid Rubyist. This is really nicely designed and feels very idiomatic. Kudos!

This is really well designed. Kudos.

Especially good is treating the Gemfile.lock as input for the the file system image and requiring it.

Why the lock in and not just a rack or even a Sinatra endpoint?

Also, the post is huge for the amount of information given

Is there a specific reason Procs weren’t used? I didn’t see a reason mentioned in the article.

Procs can be used anywhere a block can.

    my_proc = proc { |request| "Hello, world!" }
    FunctionsFramework.http("hello", &my_proc)

I’m asking though why FunctionsFramework is needed in the first place, since Procs and Lambdas are basically first class functions. What’s gained by the library. The article never goes into that aspect.

Ah yes, good point. I neglected to cover that. Well, in a nutshell:

* FunctionsFramework allows us to open-source the parts of the runtime not tied to the Google Cloud Functions hosting environment itself, meaning it should be possible to port it to other hosting, such as Kubernetes, Google Cloud Run, even FaaS products from other vendors.

* Procs work, but they're just objects. We'd still need some kind of interface to name them, load them, etc. Otherwise we'd be limited to, e.g., setting a special constant or global variable to the proc, which is messy, makes testing harder, etc.

* Speaking of which, a FunctionsFramework library gives us a place to put the unit testing library, tools to spin up a functions server locally for testing, and whatever tools developers might find useful in the future.

For reasons such as these, Google's overall Cloud Functions team decided to produce framework libraries for all supported languages. There's a contract and everything that our Ruby gem follows. (https://github.com/GoogleCloudPlatform/functions-framework)

Reply on news.ycombinator.com