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.
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)
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.
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
12 comments
[ 3.9 ms ] story [ 35.9 ms ] threadThis 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.
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.
* 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)
Especially good is treating the Gemfile.lock as input for the the file system image and requiring it.
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.
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.
Also, the post is huge for the amount of information given