[deleted]
Introducing Cloud Functions for Firebase
11–20 of 129 posts
Re: Introducing Cloud Functions for Firebase
#12I plan on doing a benchmark and blog post of a simple node http function that just returns 200 and using Blitz.io to benchmark average startup latency of Google Functions. Curious to see how it scales as the number of concurrent requests increases and what the variance is.
Re: Introducing Cloud Functions for Firebase
#13[deleted]
Re: Introducing Cloud Functions for Firebase
#14So it looks like very roughly AWS Lambda in JS only for Firebase with nice user event hooks and Firebase Cloud Messaging. I'm wondering how they handle: 1 - pricing 2 - support for long-running tasks (where Lambda does not) 3 - official tooling for packaging and deployment (perhaps the biggest critique of Lambda) It sounds like one could build an entire real app in this, which is quite cool.
1 - You can see our pricing page at https://firebase.google.com/pricing/
2 - The timeout is configurable in the Google Cloud console with a maximum timeout of 9m
3 - The official tooling is what the "for Firebase" part is all about. We've designed an SDK for Firebase users and integrated it tightly with our CLI. We'll be giving an overview of these features at https://cloudnext.withgoogle.com/schedule#target=google-clou...
Re: Introducing Cloud Functions for Firebase
#15No native python, java support like aws lambda. Are AWS 128MB instances constrained to 200MHz cpus ?
Re: Introducing Cloud Functions for Firebase
#16So it looks like very roughly AWS Lambda in JS only for Firebase with nice user event hooks and Firebase Cloud Messaging. I'm wondering how they handle: 1 - pricing 2 - support for long-running tasks (where Lambda does not) 3 - official tooling for packaging and deployment (perhaps the biggest critique of Lambda) It sounds like one could build an entire real app in this, which is quite cool.
[deleted]
Re: Introducing Cloud Functions for Firebase
#17[deleted]
Cloud Functions for Firebase is not a dupe of Cloud Functions. It is an extended offering with additional features. It's also prob of more interest to HN users.
Re: Introducing Cloud Functions for Firebase
#18(Cloud Functions for Firebase PM here) We’ve been developing this product for years, and we’ve had it in private alpha testing for well over a year, so we’re incredibly excited to finally take the wrappings off and let all of you try it. Firebase has always focused on empowering you all to build extraordinary experiences for your users, without needing to worry about building common infrastructure. While we’ve made b…
From an onboarding and testing perspective, it would be nice to be able to integrate other services ("Outbound networking"?) in the free tier. Maybe limit to one connection?
Re: Introducing Cloud Functions for Firebase
#19So it looks like very roughly AWS Lambda in JS only for Firebase with nice user event hooks and Firebase Cloud Messaging. I'm wondering how they handle: 1 - pricing 2 - support for long-running tasks (where Lambda does not) 3 - official tooling for packaging and deployment (perhaps the biggest critique of Lambda) It sounds like one could build an entire real app in this, which is quite cool.
You can see pricing details here: https://firebase.google.com/pricing/ It's based on invocations, GB-seconds, CPU-seconds, and network egress. And there's a free tier, so you should be able to try with your use case and estimate your total future cost.
Based on https://cloud.google.com/functions/pricing it seems like you can't pick and choose ram and CPU speed, so I'm not sure what the reason is to split the pricing between the two. I was quite interested in this because I've just found myself having to provision ~4x the amount of ram I actually need on lambda because I need more compute power.
Edit - It's interesting to see another player in the field though, so I'll be watching how things go.
Re: Introducing Cloud Functions for Firebase
#20Earlier quoted context omitted.
You can see pricing details here: https://firebase.google.com/pricing/ It's based on invocations, GB-seconds, CPU-seconds, and network egress. And there's a free tier, so you should be able to try with your use case and estimate your total future cost.
Based on https://cloud.google.com/functions/pricing it seems like you can't pick and choose ram and CPU speed, so I'm not sure what the reason is to split the pricing between the two. I was quite interested in this because I've just found myself having to provision ~4x the amount of ram I actually need on lambda because I need more compute power. Edit - It's interesting to see another player in the field though, so I…
[deleted]