Re:Introducing Cloud Functions for Firebase
by inlined on Thursday March 09, 2017 @02:00PM
(#13831973)
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.
Re:Introducing Cloud Functions for Firebase
by phpencil on Thursday March 09, 2017 @02:05PM
(#13832042)
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/
Re:Introducing Cloud Functions for Firebase
by dorianm on Thursday March 09, 2017 @03:27PM
(#13833195)
"You have 5 questions remaining"
Limit is 5 per year, that's brutal
Re:Introducing Cloud Functions for Firebase
by ealexhudson on Thursday March 09, 2017 @04:22PM
(#13833814)
The support comes from a genii. Make sure not to ask "Is the limit really 5?" with your first question.
Re:Introducing Cloud Functions for Firebase
by joshschreuder on Thursday March 09, 2017 @05:27PM
(#13834418)
Just ask for an infinite number of support questions
Re:Introducing Cloud Functions for Firebase
by CamelCaseName on Thursday March 09, 2017 @07:12PM
(#13835126)
Support: No.
4 questions remaining
Re:Introducing Cloud Functions for Firebase
by brillyfresh on Thursday March 16, 2017 @12:58AM
(#13882641)
What is the airspeed velocity of an unladen swallow?
Re:Introducing Cloud Functions for Firebase
by phpencil on Thursday March 09, 2017 @04:35PM
(#13833948)
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!
Re:Introducing Cloud Functions for Firebase
by pier25 on Thursday March 09, 2017 @05:05PM
(#13834225)
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.
Re:Introducing Cloud Functions for Firebase
by dorianm on Thursday March 09, 2017 @04:53PM
(#13834103)
Nice, maybe the helper text could be improved then?
Re:Introducing Cloud Functions for Firebase
by metaphyze on Thursday March 09, 2017 @02:34PM
(#13832502)
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
by mbleigh on Thursday March 09, 2017 @02:46PM
(#13832677)
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.
Re:Introducing Cloud Functions for Firebase
by rationalthug on Thursday March 09, 2017 @02:50PM
(#13832754)
How does Cloud Functions for Firebase handle node modules with native code add-ons?
Re:Introducing Cloud Functions for Firebase
by inlined on Thursday March 09, 2017 @03:03PM
(#13832915)
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.
Re:Introducing Cloud Functions for Firebase
by tokenizerrr on Friday March 10, 2017 @06:21AM
(#13837793)
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
by mbrock on Thursday March 09, 2017 @03:58PM
(#13833557)
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.
Re:Introducing Cloud Functions for Firebase
by curun1r on Thursday March 09, 2017 @07:04PM
(#13835076)
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.
Re:Introducing Cloud Functions for Firebase
by alphabettsy on Thursday March 09, 2017 @03:57PM
(#13833541)
Agreed. I still hate JS
Re:Introducing Cloud Functions for Firebase
by brutuscat on Friday March 10, 2017 @10:47AM
(#13839446)
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...
Re:Introducing Cloud Functions for Firebase
by fiatjaf on Thursday March 09, 2017 @02:35PM
(#13832517)
Really, which percentage of clients will need more than that?
Re:Introducing Cloud Functions for Firebase
by lotyrin on Thursday March 09, 2017 @02:44PM
(#13832661)
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.
Re:Introducing Cloud Functions for Firebase
by inlined on Friday March 10, 2017 @02:51PM
(#13841514)
Wouldn't this still require linear time to scan a database and map users to work?
Re:Introducing Cloud Functions for Firebase
by fiatjaf on Thursday March 09, 2017 @02:52PM
(#13832783)
Right, how many of those do exist with an internal architecture that will fit the Lambda model?
Re:Introducing Cloud Functions for Firebase
by ruleabidinguser on Thursday March 09, 2017 @03:21PM
(#13833124)
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?
Re:Introducing Cloud Functions for Firebase
by ceejayoz on Thursday March 09, 2017 @03:36PM
(#13833301)
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
by imtringued on Friday March 10, 2017 @07:55AM
(#13838214)
Firebase users don't want to run their own servers.
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...