Wow! Great to see GCloud going the serverless way.
CloudFunctions vs Lambda would not be quite a clash now!
Introducing Cloud Functions for Firebase
111–120 of 129 posts
Re: Introducing Cloud Functions for Firebase
#112This 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…
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 whil…
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.
Re: Introducing Cloud Functions for Firebase
#113Earlier quoted context omitted.
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 neve…
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.
Re: Introducing Cloud Functions for Firebase
#114Earlier quoted context omitted.
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 whil…
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?
Re: Introducing Cloud Functions for Firebase
#115Earlier quoted context omitted.
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.
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
Re: Introducing Cloud Functions for Firebase
#116Earlier quoted context omitted.
"You have 5 questions remaining" Limit is 5 per year, that's brutal
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!
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.
Re: Introducing Cloud Functions for Firebase
#117This 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.
Re: Introducing Cloud Functions for Firebase
#118(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.
same
Re: Introducing Cloud Functions for Firebase
#119Earlier quoted context omitted.
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.
Re: Introducing Cloud Functions for Firebase
#120After spending weeks getting to grip with AWS lambda I think I will try build something with firebase to see how it compares.