5 ms·
Designing a Ruby Serverless Runtime
- sam0x17 6y agoHey 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.
- dazuma 6y agoI 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.
- crazydoggers 6y agoIs there a specific reason Procs weren’t used? I didn’t see a reason mentioned in the article.
- dazuma 6y agoProcs can be used anywhere a block can. my_proc = proc { |request| "Hello, world!" } FunctionsFramework.http("hello", &my_proc)
- crazydoggers 6y agoI’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.
- dazuma 6y agoAh 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 https://github.com/GoogleCloudPlatform/functions-framework)
- xal 6y agoThis is really well designed. Kudos. Especially good is treating the Gemfile.lock as input for the the file system image and requiring it.
- config_yml 6y agoThis 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.
- dazuma 6y agoYeah, 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.
- metaskills 6y agoGlad 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 https://lamby.custominktech.com
- reissbaker 6y agoI don't use Ruby much anymore, but I used to be an avid Rubyist. This is really nicely designed and feels very idiomatic. Kudos!
- jbverschoor 6y agoWhy the lock in and not just a rack or even a Sinatra endpoint? Also, the post is huge for the amount of information given