Introducing Cloud Functions for Firebase(firebase.googleblog.com)
firebase.googleblog.com
Introducing Cloud Functions for Firebase
https://firebase.googleblog.com/2017/03/introducing-cloud-functions-for-firebase.html
128 comments
If you need more than 400 concurrent invocations please reach out to support (not promising whether or not we'll be able to satisfy arbitrary scale just yet). We're on day one of a Beta product and it'll keep getting better.
And just to clarify, Cloud Functions for Firebase is covered under the Firebase free support, who you can reach here: https://firebase.google.com/support/contact/troubleshooting/
"You have 5 questions remaining"
Limit is 5 per year, that's brutal
Limit is 5 per year, that's brutal
The support comes from a genii. Make sure not to ask "Is the limit really 5?" with your first question.
Just ask for an infinite number of support questions
Support: No.
4 questions remaining
4 questions remaining
What is the airspeed velocity of an unladen swallow?
5 troubleshooting, unlimited bugs and feature requests -> https://firebase.google.com/support/contact/bugs-features/ there. We're on Stack Overflow/the firebase-talk google group/slack etc. as well for general questions of course!
Can confirm. The Firebase team is monitoring StackOverflow constantly. I've had answers in as short as a few minutes.
Ooh, I like that phrase for the front line of triage. "Is this troubleshooting, a bug report, or a feature request?" I kind of wish GitHub issues separated things that way, too.
Nice, maybe the helper text could be improved then?
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.
Firebase engineer here.
Additional languages will come, but we're starting with Node.js. We'd rather take the approach of doing one language really well than a bunch of languages with a poor developer experience.
Additional languages will come, but we're starting with Node.js. We'd rather take the approach of doing one language really well than a bunch of languages with a poor developer experience.
How does Cloud Functions for Firebase handle node modules with native code add-ons?
Image magick's binaries are already installed on the image. Any native binary node module that has a preinstall script should work too. If you hit an unsupported syscall error, contact firebase support at firebase.google.com/contact/troubleshooting and we'll triage.
404. That's an error.
The requested URL was not found on this server. That's all we know.
The requested URL was not found on this server. That's all we know.
For the record, you can also write Lambda programs in C, Haskell, Rust, Ocaml, Go, or basically whatever compiled language you want, as long as you can manage to produce a binary whose dynamically linked library paths are compatible with Amazon Linux, which is quite easily done either by building on EC2 or using a Docker image with the Amazon Linux file system --- or building static binaries.
Well...there's ways to call into Go, Rust and C++ from Node with very little performance penalty. Rust and C++ can even build native Node modules with no need to even write a single line of glue code in JavaScript. If you need performance, Node gives you quite a few options.
[deleted]
Agreed. I still hate JS
BTW AWS Lambda do have concurrent execution[1] limits which by default seems to be set to 100 per region[2]
[1]https://docs.aws.amazon.com/lambda/latest/dg/concurrent-exec...
[2]https://docs.aws.amazon.com/lambda/latest/dg/limits.html#lim...
[1]https://docs.aws.amazon.com/lambda/latest/dg/concurrent-exec...
[2]https://docs.aws.amazon.com/lambda/latest/dg/limits.html#lim...
Really, which percentage of clients will need more than that?
Any service with more than 400 users that want to run a batch process for each user in constant time with respect to number of users.
Wouldn't this still require linear time to scan a database and map users to work?
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.
Firebase users don't want to run their own servers.
(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 big strides towards this vision in the past, we always had one big hole: trusted code execution. Today, we’re completing the story with Cloud Functions for Firebase so that you can easily run server-side code in response to events from your Firebase app.
We think you’re going to love it, and we can’t wait to see what you build with it!
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 big strides towards this vision in the past, we always had one big hole: trusted code execution. Today, we’re completing the story with Cloud Functions for Firebase so that you can easily run server-side code in response to events from your Firebase app.
We think you’re going to love it, and we can’t wait to see what you build with it!
Brendan, this is exciting news for lots of people! I'm developing a product on Firebase now and trusted code execution has always been my biggest concern.
Sure, it could be mitigated, but all the workarounds added unnecessary overhead and breaking points.
Want to thank you and your team for working on this. Firebase is a great product and this will make it just fantastic.
One thing if I have your ear - I'd love to give Firebase team some money by purchasing paid support - ideally as a part of the new Google Cloud support options announced yesterday. I hope this is on your roadmap as well :-)
Sure, it could be mitigated, but all the workarounds added unnecessary overhead and breaking points.
Want to thank you and your team for working on this. Firebase is a great product and this will make it just fantastic.
One thing if I have your ear - I'd love to give Firebase team some money by purchasing paid support - ideally as a part of the new Google Cloud support options announced yesterday. I hope this is on your roadmap as well :-)
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?
There's a bit of a nuance here. Even if you join the Blaze plan (pay as you go) there's still a large free quota. The quota is actually much larger than you get with Spark as well. We just can't allow arbitrary REST calls without a credit card. This helps avoid Cloud Functions being used for abuse/malware.
Any estimation when, if at all, European individuals can use the paid version of Firebase (Functions)?
Do you plan to introduce something similar to AWS step machines?
step functions
I can't tell from the docs - are server functions able to to modify or reject writes to refs in the realtime DB before they happen?
No. All events are asynchronous. This use case is best simulated by having clients post to a queue. Cloud functions then either discards or applies writes in that queue.
You should add this technique to the docs! It makes you realize that the Cloud Functions feature is a lot more powerful than you might initially think.
A lot of people use the Firebase Queue library for this:
https://github.com/firebase/firebase-queue
https://github.com/firebase/firebase-queue
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. :)
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. :)
+1 For React native support! In fact emailed tech support about just yesterday. Got a really quick response in which they essentially said -- "....We're exploring potential solutions, but I can't share any details or timelines at this time."
I'm optimistic. :)
I'm optimistic. :)
That's awesome! I might do the same thing in a bit. It's neat we can use the Web SDK with RN (in a limited capacity), but an official (or even semi-official) library would be the best.
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 MongoDB or RethinkDB.
> 3. Real offline persistence with Javascript.
> 4. Give me moar analytics.
> 5. A cache API.
> 6. Some way of adding server side code without needing to resort to a VPS.
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 MongoDB or RethinkDB.
> 3. Real offline persistence with Javascript.
> 4. Give me moar analytics.
> 5. A cache API.
> 6. Some way of adding server side code without needing to resort to a VPS.
Well, Cloud Functions for Firebase isn't the only thing we're working on... ;)
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...
[1]https://github.com/firebase/flashlight
[2]https://github.com/firebase/functions-samples/tree/master/fu...
The extremely poor JOIN functionality is what turned me away from Firebase a couple of years ago.
I come from 25+ years of SQL, and Firebase was my choice for essentially my first 'real world' NoSQL project. I was enjoying it right up to the bit where I had to extract data from 2, and 3 data tables at the same time in a single query. Couldn't believe how verbose and painful it was and it made me drop NoSQL for a while before more recently going back to it (with RethinkDB).
I come from 25+ years of SQL, and Firebase was my choice for essentially my first 'real world' NoSQL project. I was enjoying it right up to the bit where I had to extract data from 2, and 3 data tables at the same time in a single query. Couldn't believe how verbose and painful it was and it made me drop NoSQL for a while before more recently going back to it (with RethinkDB).
A lot of the join functionality can now be simulated by using functions to effectively create views or map reduce data to distilled output. We've got a lot more to come on this front. Functions was just first on the list.
Do you think there will ever be some kind of materialized views / declarative data denormalization?
Author here. That list wasn't really ordered in any way.
And btw I've removed point 6 from that list.
And btw I've removed point 6 from that list.
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!
Yeah, I remember when Parse offered these cloud functions back in 2012... It was a game-changer for "Backend-as-a-Service."
Wait till Google axes Firebase with no warning
How many times can devs be burned, are we all masochists or just not have any memory of the last project that offered all this
How many times can devs be burned, are we all masochists or just not have any memory of the last project that offered all this
I don't understand all the firebase and parse clones. They are not significantly better than firebase and they all entail vendor lock-in. The only real alternative is couchdb which unfortunately lacks document level read permissions (and filtered replication wastes storage) and still requires you to have an additional minimal server for the signup and passwort reset process.
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.
Part of the primary power of cloud functions is you can extend firebase services instead of intermediating them. This lets you still take advantage of all the great features in the firebase SDKs.
Like many of you, I'm incredibly happy about how this:
> This has been the most requested feature since Firebase launched
is finally in place. Firebase is a great option for quickly getting something together, and now that you can extend it with little compute, this really is a massive expansion of what you can achieve.
Disclosure: I work on Google Cloud (and sit near the Firebase folks!).
> This has been the most requested feature since Firebase launched
is finally in place. Firebase is a great option for quickly getting something together, and now that you can extend it with little compute, this really is a massive expansion of what you can achieve.
Disclosure: I work on Google Cloud (and sit near the Firebase folks!).
Quite exciting. I just recently used Firebase for the first time in years and I was absolutely amazed at the level of productivity. The best part is how seamless and brain-dead everything is compared to AWS. Also the client side JS library for database storage makes handling application state a dream. Auth and static hosting require almost no configuration, and the only thing I couldn't use firebase for was server side compute based tasks.
This is the final missing piece will allow me to develop an entire app on the google cloud with no more server admin. Can't wait.
This is the final missing piece will allow me to develop an entire app on the google cloud with no more server admin. Can't wait.
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.
Firebase offers a lot, but it's no longer the only game in town that offers a sorta-serverless baas. Here are some compelling alternatives (I'd love to see a complete list of the best Firebase alternatives):
- https://www.syncano.io
- https://www.graph.cool
- https://www.backand.com
I'm omitting things like feathers.js b/c the most attractive feature of Firebase-like tools is not having to manage your own server/database.
- https://www.syncano.io
- https://www.graph.cool
- https://www.backand.com
I'm omitting things like feathers.js b/c the most attractive feature of Firebase-like tools is not having to manage your own server/database.
We are moving from Firebase to Feathers js + PostgreSQL running on Heroku. Zero server/database configuration or managing needed.
Being able to have data relationships and real querying is a big plus over Firebase.
Being able to have data relationships and real querying is a big plus over Firebase.
https://www.deepstreamhub.com might be worth to take a look as well
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.
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.
This is a major coup against AWS. I might actually use Firebase now. If they keep this up, they can put pressure on AWS.
I don't really understand how to use this to build a real backend. Everything seem to be revolving around reactions (new thing happening in the DB, file uploaded etc) but isn't the more common use case that you actually want to call the function directly?
I'm building a simple React Native/Expo app where I want users to join random chat rooms so I obviously need some logic to delegate this process. Is Firebase/Cloud Functions something I can consider?
My first thought was "oh, maybe I can let my app call the function directly to add the user to a random chat room" but I don't see how that is possible.
I'm building a simple React Native/Expo app where I want users to join random chat rooms so I obviously need some logic to delegate this process. Is Firebase/Cloud Functions something I can consider?
My first thought was "oh, maybe I can let my app call the function directly to add the user to a random chat room" but I don't see how that is possible.
There are a few ways! For example when the user signs in, you could assign them a random chat room https://firebase.google.com/docs/functions/auth-events lets you trigger on initial sign in.
You can also hook up to regular HTTP triggers, and make it like an API call: https://firebase.google.com/docs/functions/http-events
You can also hook up to regular HTTP triggers, and make it like an API call: https://firebase.google.com/docs/functions/http-events
You can definitely do this! There are two ways that readily come to mind:
1. Use the Realtime Database as a communication channel to trigger a Cloud Function that then sets up the thing you need.
2. Create an HTTPS function and call it directly from your app, then do the work you need.
1. Use the Realtime Database as a communication channel to trigger a Cloud Function that then sets up the thing you need.
2. Create an HTTPS function and call it directly from your app, then do the work you need.
When it hits YouTube, check out our talk "Cloud Functions and Firebase". We have a much more complex chat room example than has been possible in the past
Oh, I completely missed that there were HTTP triggers as well. Thank you!
So 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.
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...
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...
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.
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 plan, Cloud Functions provides a perpetual free tier. The first 2,000,000 invocations, 400,000 GB-sec, 200,000 CPU-sec, and 5GB of Internet egress traffic is provided for free each month. You are only charged on usage past this free allotment. Pricing is based on total number of invocations, and compute time. Compute time is variable based on the amount of memory and CPU provisioned for a function. For more information, see Cloud Functions Pricing.
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 plan, Cloud Functions provides a perpetual free tier. The first 2,000,000 invocations, 400,000 GB-sec, 200,000 CPU-sec, and 5GB of Internet egress traffic is provided for free each month. You are only charged on usage past this free allotment. Pricing is based on total number of invocations, and compute time. Compute time is variable based on the amount of memory and CPU provisioned for a function. For more information, see Cloud Functions Pricing.
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.
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.
That should really be clarified on the pricing page because I think many people misunderstood that
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.
Sure, but many services with free tiers have already solved this problem by requiring a CC even without billing.
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.
Edit - It's interesting to see another player in the field though, so I'll be watching how things go.
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.
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.
[deleted]
[deleted]
I'm surprised by the progress and uptake of the node vm lib; it's really found a ton of cool business models. From powering the Screeps game world, enabling smart message routing for PubNub BLOCKS, to stuff like this. I'm excited to see more advances with time.
I 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.
Let us know what you find. Be keep an eye on your usage and quotas in the Google Cloud console if you hit any limits.
I have been waiting for this feature for a long time. This was the final missing piece for building an entire software product entirely on Firebase. Right now, I'm running servers on Google Cloud that use firebase-queue to handle server-side requests like payments and restricted actions. Google Cloud Functions would have been overkill because it would involve setting up a whole new workflow for the team. This is perfect because it is integrated to the CLI and easy for anyone to use.
All they need to work out now is educating their customers on the benefits of using Firebase over building a backend from scratch, especially in the trade-off between developer productivity and not owning your data.
All they need to work out now is educating their customers on the benefits of using Firebase over building a backend from scratch, especially in the trade-off between developer productivity and not owning your data.
We've been using this product in production for about 6 months now and it's been great once we've figured out best implementations (for us) like database structures.
Is there any protection for not spending fortune if your cloud function endpoint is DDoS attacked?
Finally! This was the feature that made me go with parse.com when I started making backend-less apps. For Firebase apps I have to spin-up tiny node.js bots to capture events and do some cloud code magic.
Will start testing now!
Will start testing now!
Built our app, Wander, an IRC-like chat app, 100% with Firebase. We've been using Firebase Queue to get server scripting abilities. Can't wait to migrate to using Cloud Functions instead, just waiting for the (awesome) team at Firebase to iron out any teething beta-related issues.
If only Realm made their server-side scripting available for free (or much less than the $1.5k/mo they're asking for Enterprise). That would give Firebase a run for their money.
If only Realm made their server-side scripting available for free (or much less than the $1.5k/mo they're asking for Enterprise). That would give Firebase a run for their money.
This is just great, the two things missing from Firebase that we kept hacking around were its very limited database querying abilities, and simple hooks around database events. Now one is part of Firebase and the other is more easily hackable than before, closing that little gap would make this the ultimate platform tool.
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.
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 bare VM.
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 bare VM.
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.
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.
I'd argue there's a maintenance cost to consider as well. Functions are "serverless" from the dev point of view, where the dev needs to maintain App Engine services, scaling strategies, and so on. It's basically the next step up in the abstraction chain: On prem (you build) > Compute > App Engine > Functions.
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.
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.
[deleted]
Authentication, realtime db, cloud messaging etc., which I guess are also not part of App engine offerings ?
After spending weeks getting to grip with AWS lambda I think I will try build something with firebase to see how it compares.
[deleted]
Very cool - congrats on the launch!
Is there any ability to set reoccurring functions or anything like a cron job?
Is there any ability to set reoccurring functions or anything like a cron job?
Not a built-in way per-se, but you do have a handful of options. You can use a third party scheduling service like https://cron-job.org/. You could also use something like https://cloud.google.com/solutions/reliable-task-scheduling-... which uses Google App Engine and Cloud Pub/Sub. We actually have a sample that shows just this (HTTPS function using an external cron job service): https://github.com/firebase/functions-samples/tree/master/de...
cool - thanks for the tip!
Wow! Great to see GCloud going the serverless way.
CloudFunctions vs Lambda would not be quite a clash now!
CloudFunctions vs Lambda would not be quite a clash now!
Is it possible to setup a Stripe server side .js code on this?
is the cloud notifications something I could use for push Notifications in Android and iOS app?
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.
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.
[deleted](1)
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 ExCamera) are using AWS Lambda to do massively parallel low-latency video encoding with 4,000+ concurrent threads. Our colleagues at U.C. Berkeley who built PyWren are doing machine learning on Lambda with similar numbers of threads. AWS has been encouraging to us for these kind of workloads, even if they aren't what Amazon initially envisioned.
So a hard limit of 400 (that can't be increased) would be a real bummer. I wonder if we can get around this by defining 20 identical functions and then invoking each one 400 times in parallel...