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...
Limit is 5 per year, that's brutal
4 questions remaining
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.
The requested URL was not found on this server.
That's all we know.
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!
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 :-)
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. :)
I'm optimistic. :)
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.
> 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 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).
And btw I've removed point 6 from that list.
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
> 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 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.
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.
Being able to have data relationships and real querying is a big plus over Firebase.
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 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.
You can also hook up to regular HTTP triggers, and make it like an API call: https://firebase.google.com/docs/functions/http-events
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.
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.
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...
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.
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.
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 - It's interesting to see another player in the field though, so I'll be watching how things go.
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.
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.
Will start testing now!
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.
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.
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 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.
Is there any ability to set reoccurring functions or anything like a cron job?
CloudFunctions vs Lambda would not be quite a clash now!
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.