Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Cloud Functions for Firebase

firebase.googleblog.com

Post reply on HN
Print view View original

61–70 of 129 posts

Re: Introducing Cloud Functions for Firebase

#61

Post by FlavorText »

nivco wrote: post #33
tedmiston wrote: post #28

Earlier quoted context omitted.

Ah, sadly no outbound networking requests on the free tier. In my opinion that is a critical use case for a tool like this. This could be a non-starter if there's really no way try it for outbound requests without paying $25 / month. Hopefully I'm misunderstanding the pricing page. Edit: The fine print for the custom plan: > 3 The Spark plan only allows outbound network requests to Google owned services. On the Blaze…

To clear things up: You Can use the Blaze plan which is pay-as-you-go and starts at 0$ and has a large free tier. External requests are disabled on projects that do not have billing enabled but you can have billing enabled and still be within the free tier of usage. The Flame plan is the "fixed cost" plan starting at 25$ and also includes external requests.

Oh, so if my app is currently under all the Free tier quotas for DB/Hosting/Storage/transfer, I could sign up for Blaze and my cost would be $0? I didn't realize that, the pricing page doesn't seem to make that clear to me.

Edit: Actually, if I'm exploring this price calculator right, it appears that there is no free tier for DB if you are on Blaze, only a free tier for Functions. Which suggests I should leave my Free tier plan as is, set up a second project that only has Functions that make external calls in it, sign that up for Blaze, and call those functions from my free tier functions... Convoluted, but hey, it'd be free.

Re: Introducing Cloud Functions for Firebase

#62

Post by chuinard »

kiliankoe wrote: post #36
chuinard wrote: post #2

As a 2+ year user of Firebase, this is long overdue. I built my own cloud function infrastructure using their Java SDK and Digital Ocean and I couldn't have built my app (ProBooks.com) without it. It's good to see Cloud Functions moving from Alpha to Beta!

Just out of curiosity, what kind of functionality were you only able to build this way?

One feature of my app is the PDF creation of invoices and estimates. I use a Java library to make these PDFs. Developing an iOS, web, and Android app that syncs in real-time is much easier (or even possible) when your PDFs are made on the backend.

Re: Introducing Cloud Functions for Firebase

#63

Post by ceejayoz »

ruleabidinguser wrote: post #59
fiatjaf wrote: post #46

Earlier quoted context omitted.

Right, how many of those do exist with an internal architecture that will fit the Lambda model?

I'm curious more generally why would somebody use Lambda at all? Surely its far more expensive than running on your own servers (or instances), no?

Lambda's billed in 100 millisecond increments. EC2 servers are billed in one hour increments. If you need short tasks that run in bursty workloads, Lambda's (potentially) a no-brainer.

Re: Introducing Cloud Functions for Firebase

#64

Post by thawab »

subpixel wrote: post #48

This was a long time coming, so congrats first. I also recently read this from an experienced Firebase developer: https://medium.freecodecamp.com/firebase-the-great-the-meh-a... Interestingly, he lists several things that he things Firebase needs in order to be awesome, and server-functions is last on the list: > 1. Real querying capabilities. Search, joins, the whole enchilada. > 2. Some sort of references likes Mon…

We use flashlight[1], an elasticsearch plugin to querying firebase. There is another implementation using cloud functions and Algolia[2].

[1]https://github.com/firebase/flashlight

[2]https://github.com/firebase/functions-samples/tree/master/fu...

Re: Introducing Cloud Functions for Firebase

#65

Post by IanCal »

nivco wrote: post #35
IanCal wrote: post #19

Earlier quoted context omitted.

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…

On the Google Cloud Console you can change the memory allocation of your Cloud Functions: https://console.cloud.google.com/functions/list?project=_ we'll be providing better integrations with Firebase tools and also looking into providing more options in the future.

Thanks.

It looks like that is tied to the processing power, is that right? I can't see a way of picking them independently in that section, unless I'm missing something.

Re: Introducing Cloud Functions for Firebase

#66

Post by marknadal »

Look, I'm going to be honest - this is exciting, and Firebase is one of the best. But Google pushing this feature spells even more vendor-lock-in doom.

My disclosure is obvious, I'm an Open Source competitor, switch to us ( https://github.com/amark/gun ) and get "cloud functions" for free which can deploy to any services ( Docker enabled, Heroku 1 click install, run on GCS, AWS, etc.).

And don't worry, we just load tested the system doing a sustained almost 2K throughput messages/second across a distributed system on low end hardware. We plan on getting this up to 10K inserts/second on a free Heroku box.

Re: Introducing Cloud Functions for Firebase

#67

Post by searchfaster »

skybrian wrote: post #25

How does this compare to App Engine? The most obvious difference I see is that App Engine lets you handle HTTP requests using a variety of languages, not just JavaScript.

Authentication, realtime db, cloud messaging etc., which I guess are also not part of App engine offerings ?

Re: Introducing Cloud Functions for Firebase

#68

Post by searchfaster »

brendanlim wrote: post #3

(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…

Thanks, this was the only thing holding me back from Firebase.

Re: Introducing Cloud Functions for Firebase

#69

Post by Andrex »

Thanks to the mods for un-duping this and linking to the blog post, which went live like 7 minutes after I hit submit, haha.

Anyways, this was the last piece of the Firebase puzzle for me. Between this, Authentication, Analytics, the DB (obviously) and Storage, Firebase has been indispensable in getting my side project app up and running -- and most importantly, feeling "real."

My only request at this point would be a bit more TLC given to how Firebase integrates with React Native. I'm sure it's coming as it's likely a "still-small-but-growing" subset of use cases. As an example, there's not an obvious way to say, get Twitter auth working in a React Native app (last I checked a few weeks ago.) There are workarounds, of course.

PS- The Firebase console and docs are some of the most slick and well-designed examples of what they do I've seen. I really enjoy the web console and the CLI tool. Just a real joy to use, and I'm not being sarcastic. :)

Re: Introducing Cloud Functions for Firebase

#70

Post by alphabettsy »

metaphyze wrote: post #37
keithwinstein wrote: post #21

This looks like a worthy competitor to AWS Lambda, but I'm disappointed by the unalterable limit of 400 concurrent invocations of a function. (The "Quotas" page says "Max concurrent functions" is 400, with "Can be increased" as "No." https://cloud.google.com/functions/quotas ) One of the cool things about AWS Lambda is that you can use it as a short-term supercomputer with thousands of threads. We (Stanford/UCSD ExCa…

Another disappointing limitation is being restricted to Node.js. AWS Lambda lets you write your code in Node.js, Python, Java, or C#. This is particularly useful for tuning your Lambdas based on their expected usage. If you have a Lambda that is being constantly invoked, it might be better to write it in Java. It has a longer start up time but has better performance after the initial startup. However, if your Lambda…

Agreed. I still hate JS
Post reply on HN