I have my app hosted in firebase and using cloud functions to fetch data from a third-party API. This cloud function is HTTP triggered and runs whenever client-side requests data. I want to reduce cloud functions calls (as it is currently on Blaze plan), so thinking to add caching in my app.
What are the caching strategies I can use on the client (web browser) as well as server-side (Node.js)?
Overall I want to reduce cloud function calls to minimize costs, so that on every client request, cloud function doesn't need to be called, instead the client can fetch data from cache.
Should I use firebase real-time database for storing data from third-party API and update this in firebase over a period of time, so that data is up-to-date? Data on the third-party side doesn't change frequently.
Whether fetching data from real-time database (as mentioned in point 3 above) instead of cloud function calls would eventually reduce costs?
If you host your Cloud Function behind Firebase Hosting, you can write a cache header in every response and manage the cache behavior of Firebase Hosting that way. Allowing the content to be served from Firebase Hosting's CDN may significantly reduce the number of times your Function gets executed, and thus its cost.
Related
I am using Firebase cloud functions for a project, and some of those functions fetch data from a firebase database.
I'd like to speed up some of these queries by leveraging a LRU cache, but it's not clear whether this is possible with Firebase cloud functions.
Does anyone know if the Firebase cloud functions have access to any kind of cache / semi-persistent memory access? Any help others can offer on this question would be hugely helpful!
If you want to share any sort of persistent data between function invocations, you will have to use another product, and code your function to use that. Cloud Functions themselves only have immedaite access to the memory on the server instance that's running a particular invocation, and there could be many server instances all running functions at the same time.
If you're OK with maintaining a small local cache in memory on each instance, that's fine. But you will have problem with this if you allow the cache to get so large that a function can't do its work with more limited memory. You should also expect the cache to get reset whenever a server instances get deallocated, which happens outside of your control.
Since you're working in Google Cloud, consider using a product such as Memorystore to implement your cache.
I am working on a project that, currently, is 100% Firebase. Ideally, given I'm fully Firebase, I'd like to stay with Firebase for a next task which is updating some of the records based on external API calls once per day.
I'm currently using Firebase Functions for triggered events, not using it for API calls, everything that happens in the functions is after a user does something, and doesn't respond back to any clients (only responds back to the database for updates).
Is Firestore Cloud Functions a good place to run something like this that could call an external API and then update as necessary? I saw the scheduled functions that require the Blaze plan, have considered it but not sure if there's another approach that's better built for this task.
Cloud Functions that trigger on Firestore events probably aren't what you're looking for. Firestore triggers only fire when something in your Cloud Firestore database has changed. That means you need something that's writing to some document in the database in order to get the code to run. Which means you need a way to schedule that operation.
No matter what kind of trigger you write, you will need to be on a billing plan in order to make external requests anyway. So even if you somehow managed to put together a solution that uses Firestore triggers, your project would still need to be on a billing plan.
This approach is perfectly okay - in fact, I am using the exact same approach in my project which has 100% Firebase back-end. The overall (Firebase) Cloud Functions gives flexibility in terms of invocation i.e. they can be invoked based on trigger (e.g. storage or database event) or can be called with the HTTP end-point. So, depending on your need you can either use Firestore trigger or database trigger or call an end-point.
Switching to Blaze plan is perfectly fine since otherwise we can't call an external end-point. I switched to Blaze plan just a few months back and didn't pay anything for that as my usage is within the free limit.
So I was watching multiple tutorials about how to present data on an actual webpage using Cloud Firestore. The thing is, everyone was using an actual index.html file sitting in Public folder(instead of serving html content within node.js code) and tags which would mean that their program would use client-side JavaScript instead of node.js. But why? for what reason? According to Firebase tutorials and documentation, having an ACTUAL index.html sitting in Public folder is only for making static webpages, thus, if I'm making a complicated and dynamic webpage(which will also present Firestore data within the webpage), I should be using node.js right?
The Firebase SDKs for Cloud Firestore perform local persistence (caching) of doucments fetched from the database. The persistence is enabled by default for Android and iOS, and you can programmatically enable it for web (currently experimental). This local caching allows the client to avoid requesting documents from the server, which is obviously faster and cheaper than going through some API endpoint to request the data each time it's needed.
There is also the fact that the SDKs will push you realtime updates of data as it changes on the server, as long as you have a listener attached to some document or query of interest. You won't be able to duplicate this if you write it all in Cloud Functions. You will spend a tremendous amount of time trying to duplicate and scale this behavior using socket.io or something similar on a backend you control.
You could write the entire app to be driven through API endpoints that you create. There's nothing wrong with that, if it meets your needs. But you'll write more code, you'll sacrifice realtime updates, and it will likely be slower and more expensive than allowing the client SDKs to optimize for you.
I have a Firestore database which I want to populate with data that is delivered by a live sports event API. This API offers to push the data, so I get new values every time some event happen in a selected game - so we don't have to pull new updates all the time.
However, the delivery method is a websocket which means, that we should open a web socket to a certain endpoint, and then we'll get the data updates.
How could we do this in Firebase? If it was just a simple webhook with an HTTP call, it would be easy to make a firebase functon that could receive the posted data.
But is it possible to do something similar with a web socket? I guess that keeping a Firebase Cloud Function running 24/7 with the web socket is not a good idea at all.
What you're describing is not supported by any Firebase products, and definitely not Cloud Functions. Cloud Functions doesn't support websockets at all, nor does it support any streaming. On top of that, the max lifetime of a function is 9 minutes.
If you absolutely need websockets, consider a different backend infrastructure instead, such as App Engine.
I'm trying to build a relatively simple application that has several different views, requires authentication, collects some user data, stores it in a database, and needs backend logic to manipulate that data and spit it back out to the user in a view.
The stack I've decided on is Vue for the frontend, with Express and Node for server side logic and Firebase for some of their services (namely auth, firestore, storage).
I haven't been able to find any examples of this stack (Vue, Express, Firebase) anywhere (I have however found Vue/Express or Vue/Firebase examples). My question is whether or not Express is obsolete here in that I can use Vue router to do my routing. Is the difference that one does the rendering server-side?
You could use Cloud Functions for Firebase as your backend and then limit your stack to Vue.js and Firebase.
From the doc:
Cloud Functions for Firebase lets you automatically run backend code
in response to events triggered by Firebase features and HTTPS
requests. Your code is stored in Google's cloud and runs in a managed
environment. There's no need to manage and scale your own servers.
For your specific need: "backend logic to manipulate that data and spit it back out to the user in a view." you have several possible approaches:
You manipulate the data with Cloud Functions (in the back end), write the results of this manipulation to the Real Time Database and setup some listeners in your Vue.js frontend (with the on() method) that will refresh your front end upon changes in the database
Use some HTTPS Cloud Functions that you call, from your Vue.js front-end, as REST API endpoints. You can use Axios for example. See the doc here.
One advantage of the first solution is that you can easily, by default, rely on the database security rules, while it would need some more extra work in the second case.