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

31–40 of 129 posts

Re: Introducing Cloud Functions for Firebase

#31

Post by inlined »

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.

App Engine is great when you want a scalable service that you use to talk directly to your backend services. Cloud Functions lets you extend an existing service with custom code. The best example is Cloud Storage and thumbnailing. If you wanted to automatically create thumbnails for images you could do that easily with an endpoint on app engine. The only problem is you'd lose out on all the other features that Cloud Storage for Firebase offers like automatic resume and 3p authorization. Instead you could write a Cloud Function that creates thumbnails as a side effect and your client app keeps talking directly to a BaaS.

Re: Introducing Cloud Functions for Firebase

#32

Post by habosa »

tedmiston wrote: post #28
habosa wrote: post #10

Earlier 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.

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…

As mentioned in some other comments, the restriction on outbound requests without a billing account is to prevent abuse. I'm sure you could imagine some bad behavior if Cloud Functions allowed anyone to spin up a few million executions per month and hit any arbitrary web services.

Re: Introducing Cloud Functions for Firebase

#33

Post by nivco »

tedmiston wrote: post #28
habosa wrote: post #10

Earlier 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.

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.

Re: Introducing Cloud Functions for Firebase

#34

Post by self »

drumttocs8 wrote: post #8

Oh man. This is great. Firebase is now a one-stop shop for the majority of app infrastructure needs, and really is the closest thing to a "serverless" infrastructure. Vendor lock-in aside, I can't think of a reason not to use it, at the MVP level at least.

I'll give you one: this won't work in China.

I'm in the process of migrating a few GAE services to AppScale on AWS (Beijing) to set up a separate backend for the China-localized version of a mobile app. AppScale supports a lot of App Engine functionality, but not other Google services. No Firebase or GCM for me.

Re: Introducing Cloud Functions for Firebase

#35

Post by nivco »

IanCal wrote: post #19
habosa wrote: post #10

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

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.

Re: Introducing Cloud Functions for Firebase

#36

Post by kiliankoe »

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?

Re: Introducing Cloud Functions for Firebase

#37

Post by metaphyze »

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 is invoked infrequently (and thus is frequently shutdown from inactivity), it would better to write it in Node.js or Python to take advantage of the snappier start up time.

Re: Introducing Cloud Functions for Firebase

#38

Post by fiatjaf »

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…

Really, which percentage of clients will need more than that?

Re: Introducing Cloud Functions for Firebase

#39

Post by skybrian »

habosa wrote: post #29
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.

It's a pretty different model, so not really an apples-to-apples comparison. Cloud Functions are bits of code that run in response to events, whether those are events from Google Cloud / Firebase or HTTP triggers. These functions scale up and down as the event load changes. App Engine is a more traditional PaaS offering where you upload and entire web app, something you might otherwise run on your own server or a bar…

Okay, but App Engine also scales up and down on demand. And an HTTP trigger is just an HTTP request; it can be stateless if you like. So that sounds an awful lot like a function in the cloud.

The part I'm not clear about is whether you can send non-HTTP events to App Engine or not? It seems like it might be useful.

Re: Introducing Cloud Functions for Firebase

#40

Post by camus2 »

habosa wrote: post #29
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.

It's a pretty different model, so not really an apples-to-apples comparison. Cloud Functions are bits of code that run in response to events, whether those are events from Google Cloud / Firebase or HTTP triggers. These functions scale up and down as the event load changes. App Engine is a more traditional PaaS offering where you upload and entire web app, something you might otherwise run on your own server or a bar…

Both can be used as a swarm of workers, that's basically what "functions as a service" are.

The difference is usually in the pricing strategy. with "FAAS", you pay only when the worker works, you're not paying when the server running them is idle, as opposed to classic server instances.

App Engine standard has a few nice ideas in the way it implements push and pull worker queues, but given its limitations it was never going to be a huge success.

But "FAAS" is obviously not suitable to serve a "user facing" website, and rely heavily on vendor locked in API that cannot be transferred to another vendor.

Containerized worker jobs make more sense than "FAAS" IMHO. SAAS like iron.io provide that.

Post reply on HN